threat-modelling

脅威モデリング（STRIDE / SDL）

脅威モデリングは、Microsoft Security Development Lifecycle（SDL）における、脅威を設計の早い段階で特定し、共有し、軽減するための体系的な手法です。コードを書く前に実施し、設計に実質的な変更があった場合は毎回再実施します。

使用する場面

新しいシステムを設計するとき、既存システムに大幅な変更を加えるとき、セキュリティの観点からアーキテクチャを評価するとき、または正式なセキュリティ設計レビューを実施するときに使用します。

このスキルは次の場合には使用しないでください：

• 組織全体のセキュリティアーキテクチャやロードマップ（security-architecture を使用）
• ランタイムの検知やインシデント対応（sentinel / defender-xdr を使用）
• コードレベルの脆弱性スキャン（SAST/DAST ツールを使用）

STRIDE - 6 つのカテゴリの概要

文字	脅威	侵害されるセキュリティ特性	代表的な軽減策
S	なりすまし	認証	MFA、相互 TLS、署名付きトークン
T	改ざん	完全性	署名、ハッシュ化、書き込み保護されたストア
R	否認	否認防止	監査ログ、署名付きトランザクション
I	情報漏えい	機密性	暗号化（保存時・転送時）、認可
D	サービス拒否	可用性	レート制限、クォータ、自動スケーリング、WAF
E	権限昇格	認可	最小権限、入力検証、サンドボックス化

経験則： データフロー図の各要素を、STRIDE の6 つすべてのカテゴリに照らして確認します。「ここには当てはまらない」とカテゴリを飛ばすことが、実際の脅威を見落とす最も一般的な原因です。

アプローチ

1. スコープと前提条件を定義する - 対象範囲と対象外の範囲、信頼モデル（誰が何を行うと信頼するか）、保護対象のアセットを明記します。スコープのない脅威モデルは単なる意見です。 確認項目：1 ページのスコープ文書に、アセット、アクター、対象コンポーネント、明示的な対象外項目が記載されていること。
2. データフロー図（DFD）を作成する - 外部エンティティ、プロセス、データストア、データフロー、信頼境界を図示します。信頼境界とは、権限やデータが主体間を移動する箇所です。多くの脅威はここに存在します。 確認項目：信頼境界を越えるすべてのデータフローが強調表示され、境界を越えるフローに漏れがないこと。
3. 要素ごとに STRIDE で脅威を列挙する - 各要素やフローについて、STRIDE の 6 つすべてのカテゴリを確認します。該当する脅威ごとに、1 行で説明を記載します。 確認項目：すべての要素について 6 つすべての文字を使って評価し、カバレッジマトリクスを提示できること。
4. リスクに基づいて脅威をランク付けする - DREAD、または可能性と影響に基づく単純な高・中・低の評価を使用します。チームが最上位の脅威から取り組めるよう、優先順位を付けます。 確認項目：上位 10 件の脅威が、発見した順ではなくリスク順に並んでいること。
5. 各脅威を具体的な軽減策に結び付ける - 軽減策とは、担当者と目標日を定めた具体的な制御策（MFA、入力検証、署名、暗号化、レート制限、最小権限）です。「セキュリティを強化すべき」のような抽象的な表現は軽減策ではありません。 確認項目：最上位の脅威すべてに、明確な軽減策、担当者、実装目標が割り当てられていること。
6. 軽減策が実装されていることを検証する - ビルド中に、各軽減策がコード、構成、またはプロセスに反映されていることを確認します。レビュー時には、軽減策が実際に脅威を防ぐことをテストします（否定テスト）。 確認項目：テストスイートまたはセキュリティレビューチェックリストに、軽減策のテストが含まれていること。
7. 重大な変更があった場合に再モデリングする - 脅威モデリングは反復的なものとして扱います。新たな信頼境界、外部連携、新たなデータ分類、大規模なリファクタリングが発生した場合は、影響を受ける範囲を再モデリングするきっかけとします。 確認項目：チームがトリガーの一覧を文書化し、直近のトリガー発生後にモデルを更新していること。
8. 役立つ場面ではツールを使う - Microsoft Threat Modeling Tool は、DFD の各要素に対する STRIDE の脅威を自動生成します。ワークショップでは、脅威モデリング用のカードやテンプレートも、ツールを使わずに効果的に活用できます。

ガードレール

• 脅威モデリングは反復的に行います。プロジェクト開始時に一度だけ行うのではなく、主要な設計変更のたびに見直してください。設計時に凍結されたモデルは、リリースされたシステムとは無関係です。
• 前提条件とスコープ外の項目を明示的に記録してください。文書化されていない前提条件は、翌年のセキュリティインシデントの原因になります。
• 脅威には、抽象的なリスクではなく、担当者と期限を定めた実行可能な緩和策を結び付けてください。
• 各要素について、STRIDEの6文字すべてを一つずつ検討してください。カテゴリを省略することが、最もよくある見落としです。
• 脅威モデリングは、コードレビュー、依存関係スキャン、ペネトレーションテストの代わりにはなりません。何をテストすべきかを定めることで、これらを補完します。
• 成果物は文書ではなく、共通認識です。開発チームが主要な脅威を口頭で説明できなければ、モデルは浸透していません。

よくあるアンチパターン

• **「プロジェクト開始時に脅威モデルを作成した」**ものの、その後一度も更新しない。脅威モデリングの対象となったシステムは、もう存在していません。
• **優先順位付けされていない、脅威が200件も並ぶスプレッドシート。**すべてが同じように見えるため、何も修正されません。優先順位付けこそが成果物です。
• **「当てはまらない」という理由でSTRIDEの文字を省略する。**必ず一つずつ検討してください。カテゴリが本当に当てはまらない場合は、黙って省略せず、その理由を記録してください。
• **緩和策＝「TLSを使う」。**これは緩和策ではありません。緩和策とは、ゲートウェイでTLS 1.2以上を暗号スイートXで強制し、テストYで検証し、担当者Zが責任を持つことです。
• **エンジニアリングチームが読まない、セキュリティチームだけの成果物としての脅威モデル。**モデルの責任を持つのは開発チームであり、セキュリティチームは支援役です。

プロンプトの例

• Run a STRIDE threat model with a data flow diagram and trust boundaries.
• Use the Microsoft Threat Modeling Tool for a design review.
• How do I identify threats and map mitigations for a new system?
• Conduct an SDL threat modelling session.
• What does the E in STRIDE cover and how is it mitigated?

Microsoft Learn

• Microsoft Threat Modeling Tool： https://learn.microsoft.com/azure/security/develop/threat-modeling-tool
• Threat Modeling Tool threats reference： https://learn.microsoft.com/azure/security/develop/threat-modeling-tool-threats
• Threat Modeling Tool mitigations： https://learn.microsoft.com/azure/security/develop/threat-modeling-tool-mitigations
• Microsoft SDL： https://www.microsoft.com/securityengineering/sdl
• SDL practices： https://www.microsoft.com/securityengineering/sdl/practices