AIによって脅威モデリングはますます複雑になっており、CISOはセキュリティの基本を見失うことなく新たなリスクを特定できる、より迅速で実践的な手法を必要としています。
数週間前の慌ただしい一日、脅威モデリングの専門家であるAdam Shostack氏は、あるクライアントからのメールを開きました。その組織では誰かがバイブコーディングでアプリを作成し、顧客データを扱う業務に投入していたのです。クライアントは、そのツールがどのようなリスクをもたらすのか、そしてどう対処すべきかを知りたがっていました。
迅速な回答が求められていたため、Shostack氏はシステムの分析に15分間だけ時間を割くことにしました。
すぐに彼は「意味のある脅威のリスト」を作成しました。そこにはハルシネーションやバイアスといった、広く使われているアプリケーションセキュリティの脅威モデリングフレームワークであるSTRIDEでは洗い出せなかった問題が含まれていました。
「取りかかった当初には見えていなかった、興味深い発見がいくつもありました」とShostack氏は語ります。
この15分間で彼が用いたのは、自身が開発した脅威モデリングフレームワーク「PHANTOM-B」です。これは「何が問題になり得るか」という標準的な問いから出発しつつ、それをシステムのLLMコンポーネントに特化して適用するものです。
名称の各文字は、それぞれ特定の脅威を表しています。プロンプトインジェクション（Prompt injection）、ハルシネーション（Hallucination）、擬人化（Anthropomorphization）、説明不能性（Non-explainability）、訓練にまつわる問題（Training issues）、過度の依存（Overreliance、データ品質や「毒」を含む）、セキュリティエンジニアリングの欠如（Missing security engineering）、バイアス（Bias）です。
この新しいフレームワークは、STRIDEを置き換えるものではなく、補完することを目的としています。STRIDEがアプリケーション全体に適用されるのに対し、PHANTOM-BはLLMと相互作用するコンポーネントに絞って使用できます。
このフレームワークは迅速に有用な結果を導き出せるよう設計されており、脅威モデリングの負担とコストを軽減します。それによって、実際に取り組まれる可能性が高まるのです。
「この作業を安価に行えるようにする、というのが私の信条です」と、Black Hat USA 2026でPHANTOM-Bを発表したShostack氏は述べています。
Shostack氏はさらに、CISOとその組織は二つの課題の板挟みになっていると指摘します。AIを迅速に保護しなければならないというプレッシャーと、既存のセキュリティツールをAIに適用することの難しさです。
「企業には取っ掛かりが必要です。1時間の会議や、経営幹部との10分間の会話に収まるようなものが求められています」と同氏は言います。
企業がAIへの依存を強めるにつれ、PHANTOM-Bのようなツールを活用する必要性はますます高まっています。「AIは本当に新しいアプリケーションアーキテクチャと未知のリスクをもたらしているため、脅威モデリングはかつてないほど重要になっています」と、OWASPの創設者であり、Contrast Securityの創業者兼CTOでもあるJeff Williams氏は語ります。
従来の脅威モデリングが不十分な理由
脅威モデリングは、これまでも常に苦労の種でした。あらゆる規模の組織が一貫して実施することに苦労しています。時間がかかる上に、開発・更新されるアプリケーションの数に追いつけないことが多いためです。その結果、多くの企業は最重要システムに限って脅威モデリングを実施し、それ以外の多くのソフトウェアは同じレベルの精査を受けずに済まされています。
「AIが脅威モデリングを壊したわけではありません。もともと存在していた弱点をあらわにしただけです」とWilliams氏は言います。同氏によれば、不都合な現実は、脅威モデリングがこれまで一度も、規模に見合うほど標準化・自動化されてこなかったという点にあります。
最も難しいのは脅威に名前を付けることではなく、どのアプリケーションが実際に機能しているのかを把握することです。「従来、私たちはこれをアンケートや質問票、インタビュー、古びたVisio図、スプレッドシートで試みてきました」とWilliams氏は言います。「そうして作られたモデルは、演習が始まる前から不完全であることが多く、アプリケーションが変更された瞬間に陳腐化してしまいます」。
生成AIやエージェント型AIは、その挙動を予測しにくいため、こうした弱点をさらに増幅させます。従来のソフトウェアは、エンジニアが入力から出力まで追跡できるルールに従って動作します。一方でAIシステムは自然言語の指示を解釈し、確率的な応答を生成するため、同じリクエストでも異なる結果が生じることがあります。さらにエージェントがデータにアクセスしたりツールを呼び出したりできる場合、その結果が別の場所で何らかのアクションを引き起こすこともあります。
「従来の脅威モデリングは、概ね決定論的なシステムに対して適用されてきました。現代の生成AIやエージェント型AIシステムは非決定論的であるため、リスクプロファイルの捉え方を見直す必要があります」と、CODIFICのコンサルティングサービス担当バイスプレジデントであり、OWASP Top 10のプロジェクトリーダーの一人でもあるBrian Glas氏は述べています。
この違いはMicrosoftのAI脅威モデリングガイダンスでも取り上げられており、データとコマンドの境界があいまいになることで新たな攻撃対象領域が生まれ、ツールやメモリ、エージェントをまたいで障害が波及しかねないと指摘されています。
Shostack氏によれば、短時間のセッションは網羅的である必要はありません。それでも、次の判断を導くのに十分な、意味のあるリスクを特定できるべきだと言います。そのリスクは許容できるのか、システムを変更する必要があるのか、あるいはより踏み込んだレビューが必要なのか、という判断です。
「アジャイルの世界から学んだことの一つは、作業の期間を小さく区切ると、より速く、より多くの反復ができるようになるということです」と同氏は言います。最初のセッションで的を外しても、チームはホワイトボードを消してやり直せば良く、数日から数週間分の作業を失うことはありません。「実験のコストを安く抑えることで、何度でも繰り返し実行できるようになるのです」。
その結果として得られるべきなのは、システムがどのように破綻し得るかを描いた、具体的なストーリーの集合です。こうしたシナリオは、CISOが自分たちの受け入れているリスクを理解する助けとなり、技術チームが適切な制御策を選ぶ助けにもなります。それはデータアクセスの制限、ツール権限の絞り込み、人による承認ポイントの追加、あるいはそもそもLLMが必要かどうかの再検討を意味することもあります。
PHANTOM-Bは、他のフレームワークが見落としている部分を埋めることを目指しています。擬人化のような、関連性はあるものの、やや馴染みの薄い概念にも踏み込んでいます。これは、ユーザーや開発者が、モデルがあたかも意図を理解しているかのように、あるいは人間のように推論するかのように、あるいは「Xをしてはならない」といった指示に確実に従うかのように扱っていないかを問うものです。こうした見当違いの信頼は、システムの設計のされ方や、それに与えられる権限の大きさを左右しかねません。
説明不能性は、また別の問題を提起します。LLMが履歴書を選別したり、医療画像を評価したり、ビジネス上の意思決定を行ったりする場合、組織はその出力結果を正当化する必要が生じることがあります。しかし、モデル自身に説明を求めても、返ってくるのはもっともらしく聞こえる答えであって、実際にどのようにして元の結果に至ったかを正確に記録したものではないかもしれません。LLMは確率的に動作するため、同じリクエストを再実行しても同じ出力が再現されるとは限らず、調査やデバッグを一段と難しくしています。
「セキュリティエンジニアリングの欠如」という項目は、LLMを追加したからといって従来型のソフトウェアリスクがなくなるわけではないことを思い起こさせます。Shostack氏のホワイトペーパーによれば、特に誰も全容を理解していないバイブコーディング製のソフトウェアを急いで導入する場合、むしろそうしたリスクは増幅されかねません。
このツールは、OWASPやNIST、CISAをはじめとする各団体の取り組みと合わせて、チームが新たに生まれつつあるリスクの全体像を理解する助けとなります。「脅威モデリングは創造的なプロセスです」とWilliams氏は言います。
AIシステムの脅威モデリングで避けるべき誤り
LLMを活用したツールは比較的新しいものかもしれませんが、それでも本質はアプリケーションです。サードパーティ製のライブラリを使用し、信頼できない入力を処理し、機密データを扱い、APIを公開し、アイデンティティや認可の制御に依存しています。
新しいAI特有の脅威にばかり注力し、基本をおろそかにしてしまうと、組織は本来防げたはずの脆弱性にさらされることになります。「最大の過ちは、既存のリスクがすべてそのまま当てはまり続けるという事実を忘れてしまうことです」とWilliams氏は言います。
同氏はCISOに対し、基本をおろそかにしたままプロンプトインジェクションやモデル操作にいきなり飛びつかないよう助言しています。「それは順序が逆です」とWilliams氏は言います。「従来のアプリケーションセキュリティが土台でなければなりません。AI特有の新たなリスクは、その土台の上に積み重なる追加のレイヤーであって、土台に取って代わるものではないのです」。
Glas氏もこれに同意しています。「細部は変わっても、リスクの根本原理は変わりません」と同氏は言います。「スピードを追い求めるあまり、過去25年間で学んだセキュリティの教訓を捨て去ってはなりません」。
Glas氏はさらに、もう一つよくある問題としてコンテキストの欠如を挙げています。チームは、LLMがアクセス制御や信頼境界、入力、データフローを含め、アプリケーション全体の中でどのように組み込まれているかを十分に理解していない場合があります。その全体像がなければ、重要なリスクが容易に見落とされてしまいます。
考えられるあらゆる攻撃を一つ残らずカタログ化しようとすることも、正しい答えではありません。「すべてを追跡することなど到底できません」とGlas氏は言います。「起こり得る攻撃の数はほぼ無限にあります」。その代わりに同氏が勧めるのは、保護すべき資産と、既に導入されている予防的・検知的な制御策から出発することです。そこから、チームはさまざまな種類の攻撃をモデル化し、弱い、あるいは欠落している制御策を洗い出し、リスクを許容可能な水準まで下げるために何が必要かを見極めることができます。
