AttackGen を導入前に読む: MITRE ATT&CK と LLM で机上演習シナリオを組み立てる仕組みと制約

AttackGen が埋めようとしている穴は「シナリオ執筆」であって「検知」ではない

インシデント対応の机上演習は、脅威アクターを一つ選び、そのアクターが自組織に対してどう動くかを時系列のインジェクトとして書き下す作業である。ATT&CK の技術リストを眺めながら「このアクターは T1566 を使うので、初期侵入はフィッシングで、次に…」と組み立てるのは、担当者が数時間から数日かけてやる作業で、しかも毎回似た調査を繰り返す。AttackGen はこの執筆部分を LLM に任せる。README の Features には、選択した脅威アクターグループまたは ATLAS ケーススタディに基づくシナリオ生成、組織の規模と業種の指定、ATT&CK Enterprise / ICS / ATLAS の三フレームワーク対応が挙げられている。対象読者は、SOC アナリストというより、机上演習を設計してファシリテートする側である。シナリオ本文に加えて、ファシリテーターが進行に使うインジェクト、成功基準、メトリクス、成果物、交戦規定へのショートカットを用意する点が README に明記されており、生成物は読み物ではなく進行台本として設計されている。

生成の実体は LiteLLM の単一ラッパーとプロバイダ選択

モデル呼び出しは LiteLLM 経由で行われ、README によれば OpenAI API、Anthropic API、Google AI API、Mistral API、Groq API、および任意の OpenAI 互換エンドポイント（Ollama、LM Studio、Azure OpenAI、OpenRouter など）を選択できる。すべてのプロバイダが単一の内部ラッパーを通るため、新モデルの追加は「one-line change」だと README は説明している。ここは設計上の利点であると同時に、抽象化のコストでもある。LiteLLM が吸収しきれないプロバイダ固有のパラメータ（たとえば特定モデルだけが持つ推論設定）を使いたい場合、このラッパーを迂回する必要が出てくる。データの流れは、サイドバーで選んだプロバイダとモデル、フレームワーク、業種、企業規模、そして脅威グループまたはケーススタディの選択がプロンプトに組み立てられ、モデルに送られ、返ってきた Markdown が画面に表示される、という単純な往復である。ローカル推論を選べばデータが外部に出ない構成も技術的には可能だが、それはプロバイダ選択の話であって、AttackGen 自体が何かをローカルで計算しているわけではない。

v0.16 の段階的生成が変えた待ち時間の性質

v0.16 のリリースノートで最も実務に効くのは Base-Scenario-First Generation である。生成が段階に分かれ、まずベースシナリオが描画され、その時点で Download Scenario と Download ATT&CK Navigator Layer のボタンが有効になる。purple-team のナラティブはその後にストリーミングで追加される。つまり二度目のモデル呼び出しが遅かろうと、不要であろうと、シナリオ自体はすぐ使える。同じリリースでは、Generate を押した瞬間の入力がスナップショットされ、実行中にサイドバーをいじっても生成中のシナリオが中途半端に書き換わらないようになったと説明されている。経過時間ラベルと、preparing inputs、generating the base scenario、building the deterministic exports、generating the purple-team narrative という名前付きフェーズも追加された。ここで注目したいのは「deterministic exports」という表現である。Navigator レイヤーや Detection & Response レポートの類はモデルの出力ではなく、選択内容から機械的に組み立てられる部分だという前提が読み取れる。生成物のうちどこが確率的でどこが決定的かの線引きが、UI の段階名として現れている。

セットアップは .env と data/ ディレクトリ、そして LangSmith は任意

README の構成に従うと、インストール後に API キーとシークレットを .env ファイルで管理し、Data Setup の手順で data/ ディレクトリに ATT&CK 関連データを配置してから起動する流れになる。起動は Streamlit アプリとして行い、Docker コンテナイメージも提供されていると README は述べている。LangSmith 連携は任意で、モデル性能のデバッグ、テスト、監視に使う位置づけである。ここで注意したいのは、.env にプロバイダの API キーを置く設計と、組織の業種・規模をプロンプトに含める設計が組み合わさっている点だ。認証情報はローカルファイルに留まるが、組織プロファイルと脅威グループの選択はモデルプロバイダに送信される。README の Security Best Practices の章が存在することは目次から確認できるが、本文は提供された範囲では読めないため、具体的に何を求めているかはここでは判断できない。MCP Server と Agent Skills の章も同様に目次にはあるが中身は不明である。

AI Insider Threat シナリオという ATLAS 側の使い方

AttackGen の特徴的な機能の一つが AI Insider Threat Scenarios である。これは、組織内に配備された frontier AI エージェントがインサイダー脅威として振る舞うという想定の演習で、README によれば Actions Speak Louder Than Tokens: An Insider Threat Model for Frontier AI Agents の脅威モデルに基づく。シナリオはエージェントの配備アーキタイプ（自律性のレベル）、脅威カテゴリ、STRIDE の脅威、そして任意の自由記述のシナリオシードによって形作られる。従来の ATT&CK Enterprise ベースの演習が「外部の攻撃者がどう侵入するか」を扱うのに対し、こちらは「自分たちが配備したエージェントがどう逸脱するか」を扱う。演習の設計としては別物で、検知側の問いも変わってくる。AI エージェントを本番に置いている組織でなければ意味を持たない機能であり、そうでない組織にとっては単に選択肢が増えるだけである。

弱点はデータ鮮度とモデル依存、そして GPL-3.0 の伝播

第一の制約は ATT&CK データの更新が利用者の運用に委ねられている点である。README は Data Setup の章を設けているが、データをどこから取得し、どの頻度で更新すべきかについての運用設計は提供された範囲では見えない。ATT&CK は改訂され、技術 ID が非推奨になり、グループの帰属も変わる。データが古ければ、生成されるシナリオは古い技術体系に沿ったものになる。第二に、生成品質は選択したモデルに強く依存する。LiteLLM のおかげでモデル差し替えは容易だが、それは品質差を吸収する仕組みではなく、品質差を試す仕組みである。同じ脅威グループと同じ組織プロファイルでも、モデルを変えればシナリオの粒度は変わる。第三に、シナリオ本文が事実として正確である保証はない。LLM が生成する以上、存在しない技術の組み合わせや、そのアクターが実際には使わない手順が混ざり得る。机上演習の題材としては許容できても、そのまま検知ルールの設計根拠にはできない。第四にライセンスである。GPL-3.0 はコピーレフトであり、AttackGen を改変して配布する場合や、社内ツールに組み込んで頒布する場合、ソース開示の条件が及ぶ可能性がある。ここは法的助言ではないので、社内利用の形態が配布に当たるかどうかは法務に確認する領域である。

代替としての Atomic Red Team と CALDERA、発想の違い

同じく ATT&CK を使うツールとして Atomic Red Team がある。こちらは技術ごとに実行可能なテスト（アトミックテスト）を提供し、実際にエンドポイントでコマンドを走らせて検知が発火するかを確かめる。AttackGen は何も実行しない。テキストのシナリオを生成するだけである。この差は決定的で、検知ルールの検証が目的なら Atomic Red Team のほうが直接的であり、AttackGen はその前段の「何を検証すべきか」を議論する場に向く。もう一つの比較対象は MITRE CALDERA で、こちらはエージェントを使った自動 adversary emulation を行う。実行系と文書生成系という違いであり、どちらか一方が上位という関係ではない。AttackGen を選ぶ理由があるとすれば、実行環境を用意せずに、経営層や他部門を交えた机上演習の素材を短時間で用意できる点である。逆に、実行を伴わないシナリオ生成だけでは、検知の実効性は何も証明されない。

採用判断の分かれ目

向いているのは、ATT&CK の技術リストを毎回手で読み込む作業を減らしたいインシデント対応担当者、複数の脅威アクターを想定した演習を定期的に回したい purple team、そして AI エージェントを本番運用していて ATLAS 側のインサイダー脅威演習を設計したい組織である。向かないのは、ATT&CK データの更新を自前で管理したくない組織、生成物の事実確認に人手を割けない組織、そして組織プロファイルや脅威モデルを外部 API に送信できない制約がある組織である。後者でも Ollama や LM Studio のような OpenAI 互換のローカルエンドポイントを選べば送信は避けられるが、その場合はモデル品質と引き換えになる。導入前に確認すべきは二点に絞られる。data/ に置く ATT&CK エンタープライズ、ICS、ATLAS の各データがどのリリース時点のものかを確認すること。そして、選択したプロバイダの API 利用規約と社内のデータ取り扱い基準の両方に照らして、業種と企業規模を含むプロンプトを送信してよいかを決めること。この二点がクリアにならない限り、生成されたシナリオを演習台本として配る判断はできない。

編集部の結論

自組織の脅威アクター像が固まっていて、ATT&CK の技術リストを読み込む作業を短縮したいインシデント対応担当者や purple team には向く。逆に、ATT&CK のデータ更新を自前で管理したい場合や、生成物を外部モデルに送れない環境では選ぶ理由が薄い。導入前に確認すべきは、data/ 配下に配置する ATT&CK エンタープライズ、ICS、ATLAS の各データがどのリリース時点のものか、そして利用するプロバイダの API に組織プロファイルを送信してよいかの二点である。

公式情報源

1. Issues
2. License: GPL-3.0
3. mrwadams/attackgen on GitHub
4. README
5. Releases