> [!abstract] 概要 > インシデント対応は、セキュリティアナリストがセキュリティイベントを検知し対応する、手作業が多いプロセスである。本研究では、大規模言語モデル(LLM)がインシデント対応調査の最終段階――利害関係者、監査人、法務専門家向けに調査結果を要約する作業――を完全に自動化できるか、あるいは何らかの形で支援できるかを検討する。我々は18名のセキュリティアナリストと50件の実インシデントを用いた一連の実験を実施し、(1) LLMが自律的にセキュリティイベントについて推論し高品質な要約を生成できるか、(2) LLMがセキュリティアナリストの要約作成を協働的に支援できるか、(3) LLMをインシデント要約に組み込むことについてセキュリティアナリストがどのような利点とリスクを見込んでいるかを明らかにする。現行のLLMは自律的に動作するために必要なセキュリティ推論能力を欠いている可能性があり、35%のケースで重要な詳細を省略し、42%のケースで事実誤認を注入した要約を生成することが分かった。一方、協働的に利用した場合、LLMはアナリストが要約を作成するのに要する労力を削減しつつ、要約の可読性と一貫性を改善した。我々はLLMのセキュリティ推論を改善する機会、およびインシデント対応における他の応用可能性についても論じる。 ## 論文情報 - タイトル: Integrating Large Language Models into Security Incident Response - 著者・所属: Diana Kramer(Google)、Lambert Rosique(DataPhant)、Ajay Narotam(Google)、Elie Bursztein(Google)、Patrick Gage Kelley(Google)、Kurt Thomas(Google)、Allison Woodruff(Google) - 媒体: USENIX Symposium on Usable Privacy and Security(SOUPS)2025(第21回)、2025年8月11–12日、Seattle, WA, USA - ページ: pp. 133–148、ISBN 978-1-939133-51-9 - URL: https://www.usenix.org/conference/soups2025/presentation/kramer - PDF: https://www.usenix.org/system/files/soups2025-kramer.pdf ## 概要 Google の detection and response チームに所属する18名のセキュリティアナリストと、クラウド侵入・コインマイニング・認証情報漏洩・マルウェア・フィッシングの5種類・計50件の実インシデントを対象に、LLM(Gemini 1.5 Flash)によるインシデント要約の自動化と支援を4段階の実験で評価した論文。人間単独の要約とLLM単独の要約を比較すると人間が優勢(61%対39%)だが、人間がLLM出力を編集する「AI支援要約」は人間単独の要約より77%のケースで好まれた。完全自動化は時期尚早だが、協働的な活用は近い将来のインシデント対応に有望であることを実証的に示す。 ## 問題設定 インシデント対応(digital forensics and incident response, DFIR とも呼ばれる)は、自動アラート(エンドポイント検知・ネットワーク・ログ監視システム由来)または従業員からの報告を起点に、セキュリティアナリストが脅威指標・調査対応の履歴・影響範囲を記録しながら進める調査活動である。調査の終盤で、これらの詳細を利害関係者・他のアナリスト・監査人向けの最終要約にまとめる作業が発生する。この要約は事業上・法務上のリスクを伴うため、正確性と一貫性が特に重要となる。 本研究は、この要約作業に絞って以下の3つのリサーチクエスチョンを検討する。 - **RQ1**: LLMは自律的にセキュリティイベントについて推論し、包括的かつ事実に忠実なインシデント要約を生成できるか。 - **RQ2**: LLMによる支援は、セキュリティアナリストが作成する要約の品質や速度を改善するか。 - **RQ3**: セキュリティアナリストは、LLMをインシデント要約に組み込むことについてどのような利点・リスクを見込むか。 (Source: 論文 Introduction、§1) ## 提案手法(実験設計) **インシデント対応ワークフロー**: 調査は脅威指標・対応履歴・影響範囲の3種の詳細を蓄積しながら進み、最終的にセキュリティアナリストが要約を作成する。この流れを示したのが Figure 1 である。 ![[_attachments/soups2025-kramer/fig01-incident-response-workflow.png]] (Figure 1. インシデント対応ワークフローの図。セキュリティログから得られた脅威指標・調査履歴・影響範囲の情報がインシデントの詳細としてまとまり、そこから人間単独の要約・AI支援要約・AI単独要約の3種の要約が生成される構図を示す。Source: soups2025-kramer.pdf Figure 1) **データセット**: 2022–2023年にGoogleのセキュリティアナリストが実際に調査しクローズした50件のインシデントチケットを、5カテゴリ(クラウド侵入・コインマイニング・認証情報漏洩・マルウェア・フィッシング)から層別無作為抽出で各10件選定した(Table 1)。2022–2023年という過去の時期を選んだのは、LLMが当時の調査に関与していないことによる汚染リスクの排除と、参加者が当該インシデントを直接記憶している可能性(recency bias)の低減を狙ったものである。 | インシデント種別 | セキュリティイベントのトリガー | |---|---| | クラウド侵入 | 脆弱な認証情報・脆弱性によるGoogle Cloudインスタンスの侵害アラート | | コインマイニング | クラウドインスタンス・デバイスによる仮想通貨マイニングのアラート | | 認証情報漏洩 | 従業員が平文で認証情報を露出したという報告・アラート | | マルウェア | 従業員デバイスのマルウェア感染アラート | | フィッシング | 従業員によるフィッシング標的化の報告 | (Table 1. 本研究に含まれる5種類のインシデント。各種10件、計50件を2022–2023年の実インシデントから選定。Source: 論文 Table 1) **AI要約の生成**: 50件それぞれについて(最終要約を除く)調査詳細一式をXML形式で構造化し、Gemini 1.5 Flashに与えて要約させた(Figure 2)。プロンプトはGoogleのdetection and responseチームが実験的に洗練させたもので、初級アナリストや法務・非セキュリティ系の利害関係者にも分かる言葉遣いを求める内容だった(Appendix A に全文掲載)。ログは実験環境外に保存されないよう無効化した。 **4段階の実験(Part I–IV)**: - **Part I(自律要約 vs 人間要約)**: 15名の参加者が14〜15件ずつ、人間要約とAI単独要約のどちらが優れているかを比較・理由付けした(計211件の比較)。 - **Part II(AI支援要約の生成)**: 15名の参加者が10件ずつ(白紙5件・AI初期要約あり5件)要約を作成・編集し、AI支援要約(人間の監修付き)142件を生成した。 - **Part III(AI支援に対する態度)**: Part II完了直後に13名がアンケートに回答した。 - **Part IV(AI支援要約 vs 人間要約の最終評価)**: Part I・IIに参加していない2名のセキュリティアナリストが、人間要約とAI支援要約のどちらが優れているかを150件比較した。 分析には二項回帰(binomial regression、インシデント種別をカテゴリ変数として使用)と独立t検定(要約の長さ・作成時間の比較)を用い、統計的検定に加えて、open-ended回答へのthematic analysis(帰納的コードブック構築)を実施した。倫理面ではGoogle社内の倫理・法務・セキュリティ・プライバシー各部門のレビューを受け、研究者は生のインシデント詳細にはアクセスせず要約のみを扱った。 ## 新規性 先行研究の多くはインシデント対応の「検知」段階――アラートの精度向上やログ解析の効率化――に焦点を当ててきた(ログ異常検知のTransformerモデル、インサイダーリスク検知等)。また、LLMのセキュリティ・プライバシー知識のベンチマーク(CTIBench・SecQA・CyberMetric等)は既に90%超の精度を報告しているが、これらは知識の正誤を問う設問にとどまる。本研究は、大きなコンテキストウィンドウの中から一貫した要約を導けるかという、より複雑な推論タスクを検証する点で新しい。また、要約品質の評価はROUGE・BLEURT・BERTScoreのような自動指標に頼る先行研究が多いが、本研究はセキュリティドメインの専門家による質的な横並び比較を採用し、より繊細な評価を実現している。(Source: 論文 §2 Related Work) ## 実験結果 ### RQ1: 自律的なLLM要約の評価(Part I) 211件の比較のうち、参加者は人間要約を128件(61%)、AI要約を83件(39%)で好んだ。特にマルウェアインシデントでAIの成績が悪く、79%(33件)で人間要約が好まれた(p=0.005)。コインマイニングとフィッシングでは人間・AIの選好がほぼ拮抗した(Table 2)。 | インシデント種別 | 人間要約選好 | AI要約選好 | p値 | |---|---|---|---| | クラウド侵入 | 29 (67%) | 14 (33%) | 0.082 | | コインマイニング | 21 (49%) | 22 (51%) | – | | 認証情報漏洩 | 25 (60%) | 17 (40%) | 0.324 | | マルウェア | 33 (79%) | 9 (21%) | 0.005 | | フィッシング | 20 (49%) | 21 (51%) | 0.996 | | **合計** | **128 (61%)** | **83 (39%)** | – | (Table 2. 人間要約とAI要約の選好。Source: 論文 Table 2) 選好理由は4つの要因(completeness・factuality・concision・readability)に分類された。 - **完全性(completeness)**: AI要約が重要な詳細(修復手順・影響範囲等)を欠くという指摘が73件(35%)、特にマルウェアで顕著(p<0.001)。逆にAI要約が人間要約より詳細な情報を持つと評価された例も87件(41%)あった。 - **事実性(factuality)**: AI要約が不正確または完全な作り話(「幻覚」)を含むという指摘が89件(42%)。クラウド侵入で最も多く、フィッシングで最も少なかったが統計的有意差はない(全てp>0.05)。マルウェアが「実行される前にブロックされた」という誤った記述や、インシデントのコードネームをマルウェア名と誤認するなど、技術的な取り違えが典型例として挙げられている。一方、人間要約の事実性への指摘はわずか9件(4%)にとどまった。 - **簡潔性(concision)**: AI要約が冗長("fluff")だという指摘が33件(16%)。コインマイニング(p=0.007)・認証情報漏洩(p=0.018)・クラウド侵入(p=0.039)で特に問題視された。 - **可読性(readability)**: AI要約の読みにくさへの指摘はわずか5件(2%)で、逆にAI要約の方が読みやすいという指摘が29件(14%)あった。 ### RQ2: AI支援要約の評価(Part II) 75件のAI初期要約に対する編集を分析した結果、43%(32/75)が「そこそこ」以上の追加詳細を要し、59%の要約(Table 5の「Not at all」36%以外の合算、および本文記述)で何らかの事実修正を要した。編集で変更された文字量は中央値でLevenshtein距離換算27%(85文字)、うち1/4の要約は1%未満の変更で済んだ(Figure 4)。 ![[_attachments/soups2025-kramer/fig04-cdf-edit-changes.png]] (Figure 4. AI初期要約に対して参加者が加えた変更量(Levenshtein距離、要約の元の長さに対する相対値)の累積分布。Source: soups2025-kramer.pdf Figure 4) AI支援要約の長さは編集前後でほぼ変化しなかった(編集前中央値349文字、編集後345文字、p>0.05)が、人間単独の要約(控え、中央値264文字)より有意に長かった(p=0.002)。これはAI支援によって導入された構造や詳細の多くが編集後もそのまま残ったことを示唆する。 ![[_attachments/soups2025-kramer/fig05-cdf-summary-length.png]] (Figure 5. AI支援要約の長さの累積分布(編集前・編集後・人間単独の控え群)。編集前後で中央値はほぼ変わらないが、AI支援を経た要約は人間単独の要約より一貫して長い。Source: soups2025-kramer.pdf Figure 5) 編集の労力については、75件中36件(48%)で「一から書くよりやや楽〜非常に楽」と回答され、「一から書く方が楽」という回答は13件(17%)にとどまった。所要時間は平均で編集250秒・一から作成310秒だったが、サンプルサイズの制約で統計的有意差はなかった(p=0.208、参加者がインシデントに不慣れだったための familiarization コストが主要因と推測される)。 ### RQ3: AI支援への態度(Part III) 13名の参加者へのアンケートでは、AI編集の方が高品質と回答した者5名、一から書く方が高品質と回答した者5名、差がないとした者3名と意見が分かれた。一方、一から書く方が精神的に負担が大きいと回答した者は7名、AI編集の方が負担が大きいと回答した者は4名で、AIによる負荷軽減を示唆する弱い指標が得られた。全体として、7名がAI支援での作業を好み、5名が単独作業を好んだ。 ![[_attachments/soups2025-kramer/fig06-attitudes-toward-ai.png]] (Figure 6. AI支援に対する参加者の態度。品質面では意見が分かれたが、AI編集を好む参加者の方が多い。Source: soups2025-kramer.pdf Figure 6) ### RQ2続き: 最終評価(Part IV) Part I・IIに参加していない2名のセキュリティアナリストによる150件の比較では、AI支援要約が77%(116件)で好まれ、11%(17件)で同等、11%(17件)で人間単独の要約が好まれた。インシデント種別による有意差はなかった(全てp>0.05、Table 7)。 ## 考察 **自律動作より協働の方が近い将来有望**: LLM(Gemini 1.5 Flash と当該プロンプト)は現時点で自律的な運用に必要なセキュリティ推論能力を欠いており、詳細の省略と事実誤認が主要因となって人間要約に劣後する。他方、人間が編集を加える協働モデルでは、労力削減と可読性・一貫性の向上という明確な便益がある。著者らはFACTSのようなgrounding手法、LoRAによるfine-tuning、RAGによるセキュリティドメイン知識の拡張(Sec-Geminiのアプローチと同様)を今後の改善余地として挙げている。 **態度の分岐は事実性への懸念に起因する**: Part IIIで参加者の意見が分かれた背景には、LLM出力から事実誤認を洗い出す精神的負荷がある。58〜59%の要約が何らかの事実修正を要した一方、完全性の問題への懸念は相対的に小さかった。これはAI支援要約の改善において事実性の担保が最優先課題であることを示す。 **要約作成中の作成者自身の評価と第三者評価に乖離がある**: 要約を作成した参加者自身はAI支援の品質向上について意見が割れたが(Part III)、独立した評価者(Part IV)はAI支援要約を77%のケースで高品質と判定した。著者らは、要約作成者が実際よりも事実誤認のリスクを過大視している可能性を指摘し、更なる検証が必要だとしている。 **品質管理という設計パターン**: 人間要約にも4%程度は誤りが指摘されており、LLM由来の誤りだけが特別なリスクというわけではない。ただし、AI支援に対する疲労から見落としが生じるリスクがあるため、AI支援・非支援を問わずサンプルを継続的にレビューする品質管理の仕組みが緩和策として提案されている。 ## 強み・限界 **強み**: - Googleの実運用環境における実データ(50件・18名の実務アナリスト)を用いた実証研究であり、生成的AIの実務適用可能性を具体的な数値(完全性35%、事実性42%等)で示している。 - 自律要約と協働要約という2つのシナリオを区別して評価することで、「LLMは使えない」という単純な結論ではなく、活用形態次第で価値が変わることを明示した。 **限界(論文が明示するもの)**: - データセットは5カテゴリの実インシデントに限定されており、他のセキュリティ・プライバシー事象や他組織の対応チームには一般化できない可能性がある。 - 要約に使用したプロンプトとモデル(Gemini 1.5 Flash)はGoogleのdetection and responseチームが選定したものであり、他のプロンプト・ツールチェーン・fine-tuning・より新しいLLMでは異なる結果になりうる。 - 実験設計上、参加者は調査担当者本人ではなくインシデントの詳細に事後的に精通する必要があった。これは、調査に実際に関わったアナリストが要約を書く実運用状況とは異なる可能性がある。 - 参加者は日常業務でLLMと接する機会がある可能性があり、LLMの価値に対する評価にバイアスが生じている可能性がある。 - サンプルサイズによる統計的検出力の制約があり、定量的知見は定性的知見で補完している。