【AWS re:Invent 2025】ThreatForestを使用した脅威モデリング概要編

こんにちはセキュリティエンジニアリングの西川（@nishikawaakira）です。今回は ThreatForest を使用した脅威モデリングについてセッションに参加してきたので概要編と実践編に分けて紹介したいと思います。

脅威モデリングの4つの質問のフレームワーク

ThreatForest の話に入る前にまずは脅威モデリングのお話から。脅威モデリングには4つの質問のフレームワークがあるらしいです。私はそんな基礎的なことすら知らなかったのですが、このフレームワークは古くから脅威モデリングのプロセスを進める際のメンタルモデルとして使われてきたそうです。

要点は下記の 4 つの質問です。

1. 何を作っているのか？（What are we working on?）
   • スコープの分解（scope decomposition）
     • より小さく管理しやすい単位にまとめる
   • データフローダイアグラムを描く
2. 何がうまくいかなくなり得るか？（What can go wrong?）
   • 脅威インテリジェンスを活用（現在の脅威・過去の攻撃事例を知る）
   • APT や他の攻撃者グループが、類似のワークロードに対してどんな TTPs（戦術・技術・手順）を使ってきたかを調べる
   • それが自分たちのシステムに影響しうるかを考える
   • 脅威ステートメントを作る（後述します）
3. それに対して何をするのか？（What are we going to do about it?）
   • それぞれの脅威に対してリスクを評価
     • 影響度は高いか？
     • 発生確率は高いか？
   • なぜそれが高リスクなのかをビジネスの観点から考える
     • 機密性（Confidentiality）
     • 完全性（Integrity）
     • 可用性（Availability）
   • アプリケーションによって優先度は異なる
     • 公開情報を出すだけの Web サイトなら機密性は低くてもよいかもしれないが、可用性は重要かもしれない
     • ヘルスケアなら、機密性が最重要かもしれない
4. 十分にできたか？（Did we do a good enough job?）
   • 適切なコントロールを特定したら、それが本当に有効か検証する
   • ペネトレーションテスト、SAST、DAST などを用いて、「このコントロールはリスクを十分に下げられているか」を確認する

アプリケーションや自分たちが取り組んでいるものに対して、これらの質問を一つずつ進めていくことでリスクやコントロールを定義し、アプリケーションに対する潜在的な脅威を理解するのに役立つということです。

なぜ脅威モデリングを行うのか、いつ行うのか

ソフトウェアデベロップメントライフサイクル（SDLC）を考えると、脅威モデリングは一般的に「設計フェーズ」で行われますが、設計段階で実施できれば、

• 脅威を早期に特定できる
• 初期の設計に対して素早く反復できる
• 適切なコントロールを定義し、後半フェーズに進む前にリスクを下げられる

といったメリットがあります。

ただし、必ずしも設計フェーズだけで行われるわけではなく、これはパイプラインのもっと後ろのフェーズでも実施されることもあります。なぜデプロイ段階や運用・保守フェーズでも行うかというと、環境は変化するからです。

例えば、脅威の状況は日々変わります。新たな脆弱性が見つかるかもしれませんし、新しい攻撃者グループが出てくるかもしれません。そういった新しい情報を得たときに「当初定義した脅威は、今のコンテキストでも有効なのか？」を改めて見直す必要があります。こういった見直しは必要と思いつつも、脅威モデリングを自分たちで実施した際に本当に見直す運用ができるのかというところに脅威モデリングの難しさを感じているのですが、必要性でいうとそうですよね。

できるだけ早い段階で脅威モデリングをやりたい理由は、欠陥の修正のコストは、後ろに行くほど指数関数的に増加するからです。これが「早くやる」最大の利点です。いわゆるシフトレフトですね。 もちろん、脅威の状況が変わるので、頻繁に行うべきというのが理想ですが、現実そこにコストを払うのは難しいですよね。ただまあ早くやればやるほど対策を入れるコストは安く済むということです。

誰もいざ本番リリース直前になってから、セキュリティチームに待ったを掛けられたくないですよね。という話がありました。それはそうです。私も言いたくない。

言いたくないし、言われたくないからこそ、できるだけ早く実施することで下記のそれぞれを低減させることができるということです。

• エンジニアリングの工数
• 努力度
• リスク

また、脅威モデリングを行う理由は、リスクの変化に追随するためでもあり、本番に近づくほど、あるいは本番運用中・保守中のほうが一般にリスクは高まります。

例として Staging 環境（Pre Production と言っていたけれど）であれば、まだ外部公開されていなかったり、ユーザーに露出していない場合もあるためリスクは相対的に低いですが、Production として一度インターネット上に公開されると、アプリケーションは数秒以内にスキャン（スクレイピング等）され始めます。そういった状況を理解し、どのような脅威があるのかを常に意識し、それに対応する適切な対策を入れてリスクを下げる必要があります。

脅威モデリングの主なメリット

登壇者の方々は脅威モデリングのワークショップを行うとき、必ず以下のメンバーを同じ部屋に集めるそうです。

• ビジネス側の担当者
• 開発者
• セキュリティ担当者

開発者はセキュリティ担当者が参加するのは一般的にありそうですが、ビジネス側の担当者まで参加することは珍しいというか少なくとも私の発想にはありませんでした。

目的としては、これらのメンバーを参加させることによって強い関係性を築いたり、ビジネス側はリスクを理解していて、「何を受け入れられるか」「何を持って本番リリースとするか」という判断基準を持っていますし、開発者はアプリケーションとコードを深く理解していて、ワークロードの細かい挙動を把握していますし、セキュリティ担当者はリスクと脅威を理解しています。

こうした異なる視点・専門性を組み合わせることが重要であるという話でした。個人的には納得している一方、その枠組みの難しさもあるなーというのは思うところです。

さらに、脅威モデリングを進めていくと、似たような脅威・リスクが多数見つかることが多くあり、それらに共通して効くコントロールがある場合があり、その例として、多要素認証（MFA）は、多くの認証系の脅威に対するリスク低減に役立ち、もし脅威一覧を見たときに「90% の脅威に MFA が関係している」とわかれば、「まずはそこからやろう。投資対効果が高い」と判断できるという話がありました。

また、新しい技術を採用したいとき、たとえば社内で生成 AI のチャットボットを使いたいとします。ビジネス側や開発者はすぐにでも使いたい、ということが多いでしょう。

そこでセキュリティ組織としては、

• どんな脅威が考えられるか
• 何がうまくいかなくなり得るか
• どうすれば素早く、かつ安全に導入できるか

を考える必要があります。脅威モデリングは、こうした「新技術の安全な導入」を素早く進めるためにとても良い手段であるという話がありました。これも非常に良い話です。

Threat Statement（脅威ステートメント）

脅威ステートメントは、要するに「構造化された文章」です。脅威を処方箋のように書き、反復可能かつ分析しやすくするための型だという説明がありました。

代表的な構文として以下のようなことが例示されていました。

ある脅威ソースが、ある前提条件を満たした上で、ある脅威行動を行い、それによってある影響が生じ、その結果として特定の資産に対する必要な性質（またはゴール）が損なわれる。

• 脅威ソース（Threat Source）
  • 外部の攻撃者でも内部の人物でもよい
• 前提条件（Prerequisites）
  • その行動を実行するために必要な条件
  • たとえば「アクセス権がないこと」すら前提条件になり得る
  • あるいは「管理者権限を持っている」「ネットワークへのアクセスがある」など
• 脅威行動（Threat Action）
  • 実際に行われる攻撃行動
• 影響（Impact）
  • 何がどう悪くなるか
• 必要な性質 / ゴール（Goal）
  • 機密性が高い必要がある
  • 可用性が高い必要がある
  • 完全性が高い必要がある
• 資産（Asset）
  • DB、EKS クラスター、ストレージなど、守りたい対象

このような構造があることで、次のような分析がしやすくなるとのことです。

• 全脅威のうち、内部脅威がどれくらいか？ 外部脅威がどれくらいか？
• 機密性に影響する脅威はいくつあるか？
• どの資産に対する脅威が多いか？

Threat Statement の例

セッション中は下記のような具体例を挙げて解説が行われました。

「オープンポートをスキャンできる能力を持つ未認証ユーザーが、アプリケーションインスタンスに不正侵入し、そこで暗号通貨マイニングを実行することで、アプリケーションの可用性が低下する。」

ここで「何がうまく行かなくなり得るか」は「アプリケーションインスタンスへの不正侵入」で、「影響部分」は「暗号通貨マイニングが行われる」「可用性が低下する」となるということです。

Attack Steps（攻撃手順）と Attack Tree（攻撃木）

脅威ステートメントは「何が起こり得るか」を構造化して表現するのに役立ちますが、それだけでは不十分で、さらに「どうやってそれが起こるのか」という「攻撃手順（Attack Steps）」を定義する必要があるということです。それがイメージできなければ、発生可能性がわからないですからね、大事なことです。

先ほどの脅威ステートメントに対応する攻撃手順の例としては、次のようなステップを解説していました。

1. SSH / RDP の総当たり攻撃を行う
2. インスタンスにマルウェアを配置し、ローカル権限昇格を行う
3. 認証情報（credentials）を DNS 経由で外部へ送信する
4. 入手した認証情報を使って API を探索・悪用する
5. EC2 インスタンスを作成・起動する
6. マイニングソフトウェアをインストールする

これはあくまでも例ではありますがこのような複数のステップが組み合わさって、最初の「脅威ステートメント」が実現されます。この「さまざまな攻撃経路の組み合わせ」が、最終的に Attack Tree となります。

ThreatForest というツール

ただし、開発者は必ずしもセキュリティの専門知識を持っているとは限りませんし、ある脅威ステートメントが実際にどのような経路で起こり得るか、すべてのパターンを考えるのは難しいと登壇者らは考えたそうです。わかりみが深いですね。

そこで彼らは ThreatForest というツールを開発しました。次の記事では実際に ThreatForest の使い方や結果について共有しますが、簡単に ThreatForest について触れておくと、開発者が CLI や IDE で対象ディレクトリを指定して実行すると、そのリポジトリの情報を元に Threat Statement や Attack Tree を自動生成してくれるというものです。先ほども申し上げた通り Threat Statement を自分で考える、特に開発者がそれを考えるのは大変ですのでこういう取り組みには効果があると考えられます。

もちろん Threat Statement を自分で作成することも可能で、その場合は CLI で既存の Threat Statement を選択する形になっています。形式は PDF や markdown、 AWS が開発した脅威モデリングのための CLI ツールの Threat Composer などがあるようです。

フェーズ構成の概要

ThreatForest には大きく 2 つのフェーズがあります。

1. Attack Tree Generation（攻撃木の生成）フェーズ
   • 情報収集
   • コンテキスト抽出
   • Attack Tree の生成
2. Threat Intelligence Alignment（脅威インテリジェンスとの整合）フェーズ
   • 生成された攻撃木の各ステップを既存の TTP にマッピング
   • 最初のリリースでは MITRE ATT&CK Enterprise Matrix を利用
   • それぞれの攻撃ステップに対して、
     • どの攻撃テクニックと似ているか
     • どの攻撃者グループが使ってきたか
     • どんな緩和策・コントロールが知られているか
       などを紐付ける

これによって「過去に実際に観測された攻撃手法」に基づいた現実的な攻撃シナリオとして、1で作成した Attack Tree を強化していきます。

というのが ThreatForest の概要となっています。

最後に

本記事では脅威モデリングがほとんどになってしまいましたが私にとっては非常に学ぶことが多く、脅威モデリングを普段からされている方だけでなく、これから始めてみようかなと思ってもらえたら嬉しく思います。ThreatForest については本記事ではまだ軽くしか触れられていませんが、これも非常に良いツールになり得る期待感があります。それこそ AWS Security Agent と組み合わさってペネトレーションテストができるようになったら嬉しいな〜という想いがあったりするので、色々と試して AWS の方にフィードバックしたいと思います。次の記事もぜひ読んでいただけれたらありがたいです。