LLMを活用した脅威ハンティング入門：SIEM連携・プロンプト設計・実践プレイブック

はじめに — なぜ今、LLMを脅威ハンティングに使うのか

大規模言語モデル（LLM）は、ログ要約、アラート類推、インシデント報告ドラフト、プレイブック生成などSOC業務の生産性を大きく向上させます。一方で、LLM特有の脆弱性（プロンプト注入やシステムプロンプトの露出など）は新たなリスクを生みます。MITREはAI向けのATLASフレームワークで、LLMを含むAIシステムへの攻撃経路と防御手法を整理しており、運用における注意点を提示しています。

さらに、英国家サイバー機関（NCSC）はプロンプト注入の根本的な難しさを指摘しており、完全な封じ込みが難しい領域であるため“影響を最小化”する設計が重要だと警告しています。運用チームはLLMを単なる自動化ツールと扱うのではなく、潜在的な『混同代理（confused deputy）』問題として評価する必要があります。

実例としては、研究コミュニティで報告された“プロンプト露出（prompt leaking）”の手法があり、モデルアプリケーションからシステムプロンプトを抽出する攻撃が実証されています。これらの事実は、LLMを内部プロセスに組み込む際のログ管理、秘匿管理、アクセス制御の重要性を改めて示しています。

SIEM／EDR／XDRとの連携アーキテクチャ

LLMをSOCのデータパイプラインへ組み込む際の基本パターンは次のとおりです：

1. イベント収集（SIEM）→ 正規化・保存（データレイク）
2. 検索・分析（クエリ／UEBA／ルール）
3. コンテキスト照合（ホスト情報、ユーザーベースライン、脅威インテリジェンス）
4. LLMによる要約・優先度付け・プレイブック候補の生成
5. SOAR経由で自動化（必要時はヒューマンインザループ）

例えば、Microsoft Sentinelのデータレイク機能はセキュリティデータの統合と機械学習・LLMベースの分析ワークフローを支援し、分析と深掘りを同一プラットフォームで行いやすくします（データの一元化によりRAGや分析用コーパスの整備が簡単になります）。SOC運用でのLLM活用は、まずこの“データの一元化”を前提に設計するのが現実的です。

また、SplunkなどベンダーはLLMをセキュリティ文脈で導く手法（RAG、few-shot、カスタム分類器の併用）を提示しており、単純なプロンプト投げ込みよりも、コンテキスト埋め込み＋検証ループを持つ実装が推奨されています。これにより誤導や誤検知を減らせます。

プロンプト設計と安全対策（RAG／ガードレール／検出）

運用で重要なのは「LLMを信頼しすぎない」ワークフロー設計です。実務で効果的なパターンは以下です：

• Retrieval‑Augmented Generation（RAG）で最新の社内コンテキストを都度参照させる（固定知識だけに頼らない）
• プロンプト前処理：ユーザー入力や外部ドキュメントはサニタイズし、明確に"data"領域として分離する
• 検出層の導入：プロンプト注入や異常入力を確率的分類器やルールで検知し、危険度に応じてブロック／隔離／ヒューマンレビューへ回す

Microsoftは外部コンテンツ経由の間接的なプロンプト注入を検知するための取り組み（Prompt Shields 等）を公開しており、検出→遮断→SOC通知という流れで実運用へ組み込む設計が紹介されています。運用側はこの種の検出ログをSIEMへ流し、追跡・相関検索を行うべきです。

研究側でもプロンプト注入検出フレームワーク（例：多層フィルタリングや埋め込みドリフト検出）が提案されており、これらを応用して"入力検疫レイヤ"をSOCアーキテクチャに追加することで、攻撃リスクを低減できます。

実践プレイブック例：検出→調査→対応（テンプレート）

以下は、LLM支援の脅威ハンティングで即使える簡易プレイブック例です。重要なのは各ステップで“誰が意思決定するか”を明確にすることです。

プレイブック（概要）

1. トリガー：SIEMのレアプロセス検知アラート（例：異常な親子プロセス組合せ）
2. 初動自動化：SOARでホストの簡易情報収集（プロセス一覧、ネットワーク接続、ログ抜粋）
3. LLM要約：収集データをRAGで与え、簡潔な調査サマリと優先度/推奨アクション候補を生成（ただし『推奨は提案』として扱う）
4. ヒューマンレビュー：アナリストが要約と推奨を確認し、隔離実行や更なるフォレンジックを指示
5. 対応と学習：対応結果と検出ロジックの修正（SIEMルールや検疫リスト）を自動でレポート化し、将来のRAGコーパスへ追加

注意点（実務的ガイド）

• LLMの出力は"説明責任"を持たせ、必ず出力元となるログIDやクエリ文を付与させる。
• 自動化で実行するアクションは『破壊度の低い手順』から段階的に適用する（例：スナップショット取得→ネットワーク隔離→完全隔離）
• ルールやクエリ生成をLLMに委ねる場合は、生成前後でSigma/KQL/SPLの静的解析やサンドボックス実行を通す。研究ではLLMを用いてプラットフォーム間で実行可能なクエリを生成する試みが進んでおり、実運用では生成クエリの検証が必須です。

実用プロンプト（テンプレート）

You are a SOC assistant. Given: 1) SIEM alert id: {ALERT_ID} 2) host telemetry (processes, network, logs) and 3) threat intel tags.  Output: concise summary (3 sentences), 5 prioritized hypotheses, required next forensic commands (with exact SIEM queries) and recommended containment actions. Always include source log IDs for each claim.

上のテンプレートをRAGで拡張し、社内のホストベースラインや過去のインシデント要約をベクトル検索で与えると、より現場に即した候補を出せます。ただし、生成された"次のコマンド"や"クエリ"は、必ず自動的に静的検証／承認フローを通すことを運用ポリシーに組み込んでください。

まとめと運用上の推奨事項

LLMは脅威ハンティングの有力な補助ツールですが、プロンプト注入やモデル抽出といった新しい攻撃軸を生む点を忘れてはいけません。MITREや各ベンダーの公開情報を踏まえ、以下を運用方針に組み込みましょう：

• データ統合（データレイク）を最優先にしてRAGの品質を担保する。
• プロンプト注入検知と入力検疫レイヤをSIEMで監視・アラート化する。
• LLMの出力は"推奨"に留め、重要な封じ込めアクションは必ず人が承認するフェーズを残す
• 生成される検出ルールやクエリは静的解析・テストを自動化して誤動作を防ぐ（研究ではルール最適化やクロスSIEMクエリ生成の有用性が示されている）。

最後に、LLM導入は“技術”だけでなく、監査・責任・トレーニングを含む組織的な取り組みが成功の鍵です。まずはパイロットで小さく始め、ログ／検出／対応の各ループで学習を重ねる体制を整えてください。