MITRE ATLAS

定義

MITRE ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems）は、AI搭載システムに対して観測された攻撃者の戦術、手法、およびケーススタディをまとめた、一般に公開されているナレッジベースです。MITRE ATT&CKの構成を踏襲しているため、AI特有の攻撃を、組織の他の脅威インテリジェンスと同じ用語で記述することができます。

スコープ

AI搭載システムを構築、展開、または防御するすべての組織、およびすでにATT&CKを共通言語としているすべてのセキュリティチームが対象です。これはナレッジベースであり、標準規格ではありません。これに対する認証制度はなく、管理策を規定するものでもありません。防御側が何を検知し防止すべきかを決定できるように、攻撃者の行動を記述したものです。

主な要件

• 戦術（攻撃者の目標）と手法（それがどのように達成されるか）として構成されており、意図的にMITRE ATT&CKを反映させているため、AIへの攻撃を既存の脅威モデルから切り離すことなく、その中に組み込むことができます。
• 偵察、モデルへのアクセス、実行、永続化、防御回避、検出、収集、持ち出し、影響といった侵入プロセス全体をカバーしており、モデルに対する攻撃の準備など、AI特有のステージも含まれています。
• エビデンス主導です。各項目は文書化されたインシデントやレッドチームの演習に基づいているため、理論上起こり得る問題の単なるリストとは一線を画しています。
• OWASPと競合するのではなく、補完し合う関係にあります。OWASPが設計上の弱点を分類するのに対し、ATLASはそれらを悪用する攻撃者の行動を記述します。
• その実用的な価値は、検知とレッドチーム演習にあります。手法（テクニック）とは、自社システムに対して試行できるものであり、ログから探し出すことができるものです。
• マトリクスは新しい攻撃が文書化されるたびに維持・拡張されるため、固定されたチェックリストではなく、生きたリファレンスとして機能します。

コントロール

エージェントスタックをマトリクスにマッピングする

自社のアーキテクチャに照らし合わせて戦術を検証し、どの手法が到達可能（reachable）であるかをマークします。防御する価値がある手法かどうかを決めるのは、もっともらしさ（plausibility）ではなく、到達可能性（reachability）です。

到達可能な手法を検知ルールに変換する

それぞれの手法について、テレメトリ上でそれを特定できるシグナルを定義します。対応するシグナルがない手法は、「気づかないことに決めた」手法と同義です。

レッドチームのバックログとして活用する

手法はその構造上、テスト可能です。自社システムに対して実行し、「再現できなかった」という結果も、成果なしとするのではなく、記録に値する結果として扱ってください。

組織がすでにATT&CKを使用している場合は、それに合わせる

AIに関する検出事項をATLASの用語で報告することで、他のすべての脅威と同じインテリジェンス、トリアージ、対応プロセスに組み込むことができます。独自の新しい語彙を使ってしまうと、AIリスクの責任の所在が曖昧になる原因になります。

マトリクスだけでなく、ケーススタディも読む

ケーススタディには、どのようにアクセスが取得されたか、攻撃者が次に何を行ったかといった運用の詳細が含まれており、これこそが自社の環境に応用できる部分です。

脅威モデルにフィードバックする

ATLAS is the external input to an agentic threat model; the threat model is where its techniques become surfaces you own, with controls and owners attached.

チェックリスト

• 01自社のアーキテクチャにおいて、どのATLAS戦術がそもそも到達可能であるかを特定する。
• 02到達可能な各手法について、それを制限する管理策と、それを検知するシグナルを記録する。
• 03検知手段がない場合は、行を空白にするのではなく、明示的にその旨を記載する。
• 04マトリクスから抽出したレッドチーム演習を計画し、カバレッジを主張する前に、各試行が成功したか失敗したかを確認する。
• 05検出事項をATLASの識別子（ID）を使用して報告し、組織の既存のインテリジェンスフローに統合する。
• 06新しい手法は観測され次第文書化されるため、マトリクスを定期的に見直す。
• 07OWASP LLM Top 10と相互参照し、弱点と攻撃者の行動を別々に追跡するのではなく、相互にマッピングする。

一般的な落とし穴

• コンプライアンスのチェックリストとして扱うこと。ATLASに対する認証制度はなく、「マトリクスを確認した」ことは管理策にはなりません。
• 到達可能性を考慮せずにすべての手法をマッピングすること。これは膨大な文書を生み出すだけで、優先順位が定まらなくなります。
• AI脅威インテリジェンスを組織の既存のプロセスから切り離して管理すること。これこそが、ATT&CKとの整合性を図ることで防ごうとしている事態です。
• マトリクスだけを読み、応用可能な運用の詳細が記載されているケーススタディをスキップすること。
• テストをせずにカバレッジを想定すること。自社システムに対して一度も試したことがない手法は、単なる主観的な意見にすぎません。

例

• あるチームが自社の検索エージェントをATLASにマッピングしたところ、モデルへのアクセスが容易（エンドポイントが公開されている）、準備が容易（Wikiの編集者なら誰でもコンテンツを仕込める）、持ち出しに対する管理策がない（送信制限がない）ことが判明しました。これら3つの手法のうち、1つはすでに懸念していたものでした。
• すでにATT&CKベースの検知エンジニアリングを運用しているセキュリティ組織が、ATLASの手法を同じバックログに追加します。これにより、AI特有の検知ルールが、その業務を担当するチームによって構築、レビュー、およびオンコール対応されるようになります。
• レッドチームがマトリクスをエージェント評価のターゲットリストとして使用し、ATLASの識別子で報告します。これにより、エージェントを扱ったことがない担当者でも、その検出事項をトリアージできるようになります。

FAQ

ATLASはATT&CKの代わりになるものですか？

いいえ、補完し合う関係です。ATT&CKは従来の攻撃者の行動をカバーし、ATLASはAI特有のステージをカバーします。意図的に同じ構造に設計されているため、フィッシングメールから始まりモデルで終わるような攻撃を、終始一貫して記述することができます。

すでにOWASP LLM Top 10に従っている場合でも、ATLASは必要ですか？

これらは異なる目的を持っており、組み合わせて使用することに意味があります。OWASPはどのような脆弱性のクラスが存在するかを示し、ATLASは攻撃者がそれをどのように悪用するかを示します。これこそが、検知やレッドチーム演習で実際に必要とされる情報です。

小規模なチームでは、どのように活用できますか？

まずはレッドチームのバックログとして活用するのが最適です。検知プログラムがなくても、マトリクスは自社システムに対して試行すべき攻撃の優先順位付きリストを提供します。実際に試行することは、どの管理策が机上の空論にすぎないかを明らかにする最も低コストな方法です。

参考文献

• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• OWASP — Top 10 for LLM Applications
• NIST — AI Risk Management Framework (AI RMF 1.0)

関連するガバナンス