正式には、脅威モデリングとは、潜在的な脅威を特定し、深刻度を評価し、可能な緩和策を検討するプロセスです。別の言い方をすると、脅威モデリングは、あなたが構築しているシステムがどのように壊れる可能性があるかを考え、それを防ぐためにあなたのチームができることを検討することです。

脅威モデリングはツールではなくプロセスであることを強調することが重要です。ツールはプロセスをより効率的にするのに役立つが（例えば、視覚化を提供したり、時系列の変化を追跡したり、脅威モデルに影響を与える可能性の高いソフトウェアの変更を特定したりする）、現在のところ、ツール自体は、他の人間がシステムをどのように攻撃するかを推論する人間の代わりにはなることは難しいとされています。

脅威モデリングは、複数のステークホルダー（開発者、アーキテクト、サービスエンジニ ア、設計者、エンドユーザー、セキュリティ専門家など）が一緒になって、システムをさまざまな角度から見るときに最も効果的になります。ディスカッションは、システムがどのように使用され、どのように機能すると想定され、実際にどのように機能するかについて説明するようなシンプルなものにすることができます。セキュリティ・スペシャリストは、実施されているセキュリティ管理についてよりよく理解するために質問し、多くの場合、全員がシステムに影響を与えるリスクについて深く理解して帰ります。

評価の実施にはいくつかのアプローチを用いることができます、 例えば、設計中心の脅威モデリングであれば、信頼できる要素と信頼できない要素を分離する仮想境界をデータが通過する領域に主に焦点を当てるアプローチが取られます。

メリット

脅威モデリングは、発見された脅威とその適切な緩和策を論述することによって、システムに組み込まれたセキュリティへの対応を改善し、その姿勢に対するユーザの信頼を高めることができます。正しく実行されれば、ソフトウエアプロジェクト全体に明確な見通しをもたらし、セキュリティ対策の正当化に役立ちます。

脅威モデリングには、主に次のようなメリットがあります:

• より安全なシステム： 早期に適切な脅威モデリングを行うことで、セキュアな設計に基づくセキュアなシステム構築の基盤が確立されます。プロセス全体を通じてセキュリティを念頭に置いてシステムを設計することで、脆弱性を発見する可能性が低くなり、チームは自信を持って提供する機能に集中できるようになります。

• リリース前に設計上の欠陥を早期に発見することによりコストを削減： 脅威モデリングは通常、システム設計段階で行われ、セキュリティリスクを早期に特定することができます。脆弱性を早期に発見することで、緩和策が必要になったときの貴重な時間と金銭的リソースの節約につながります。セキュリティリスクを解消するためのコストは、システムのリリースが近づくにつれて劇的に増加し、公開後は指数関数的に増加します。発見されなかった脆弱性がブランドにもたらすコストは、計り知れないものになる可能性さえあります。

• 他の手法では発見できないような弱点に触れる可能性を減らす： 設計・開発チームは、システムを開発するためにさまざまな方法を用います。コードレビューやテストプランレビューは、エンジニアがシステムの有効性を評価するのに役立ちますが、入力検証や暗号化の必要性といったセキュリティ上の懸念事項は明らかにされないかもしれません。脅威モデリングは、コンポーネントの要素間に存在する関係を調べ、要素間のデータの流れを分析し、潜在的に悪用可能な弱点を明らかにすることが出来ます。

脅威モデリングプロセスのゴールは、以下のような効果的な手段を提供するし、エンジニアリングチームがアプリケーションに対する既知のセキュリティ脅威を文書化し、その対処方法について合理的な決定を下せるようになることです：

• ソフトウェア開発ライフサイクルの早い段階（コーディングが始まる前であっても）で問題を検出する。
• リリースの前に、特定された弱点に対する現実的な緩和策を提案し、コストのかかるデプロイ後の再コーディングを防ぐ。
• 従来のテスト手法やコードレビューでは見落とされがちな設計上の欠陥を発見する。
• そのサービス特有の脅威やセキュリティ問題を考える。
• グループでブレインストーミングを行い、新しい攻撃形態を評価する。
• ターゲットテストとコードレビューを支援する。
• コンプライアンスとセキュリティ基準のギャップを特定する。 *攻撃者が標的とするコンポーネントを推測するするための資産、脅威エージェント、コントロールを特定する。

基本的に、脅威モデラーは、システムに内蔵されたセキュリティ態勢を、以下によって改善するよう検討します:

• システム・アーキテクチャを単一コンポーネント・レベルで理解する。
• エンジニアリングチームが何に対してセキュリティを確保するのかを理解できるようにすることで、安全な設計と実装の基礎を提供する。
• アーキテクチャの設計と構成を業界標準と比較することにより、弱点を発見する。
• システムとそのコンポーネントの脅威プロファイルを理解し、攻撃者が目的を達成するための潜在的な弱点を列挙する。
• アプリケーションセキュリティライフサイクルへのフィードバックを提供する（侵入テストのフレームワークや弱点の分析など）

スコープ: 1つの脅威モデルか、多くの脅威モデルか？?

特定のサービスの規模に応じて、1つの脅威モデルを完成させることもできるし、システムを機能別、コンポーネント別、エンジニアリングチーム別に分解して、システムごとに複数の脅威モデルを完成させることもできます。

ワークロード全体に対して単一の脅威モデルを作成するのではなく、個々の機能やコンポーネントごとに脅威モデルを作成することには、多くの利点があります:

• 仕事のサイズを小さくすることで、進捗をより細かく追跡できる、これは、アジャイルスタイルのデリバリーに従うエンジニアリングチームとうまく調和し、リーダーシップが常に進捗状況を把握できます。
• その結果、脅威モデルはより詳細になる傾向があり、より多くの発見が特定されることになります。
• 脅威モデルは、同じコンポーネントを使用する他のワークロード機能の依存関係として再利用できる可能性があります。
• コンポーネントレベルで脅威の緩和を考慮するということは、1 つの脅威がワークロード全体 のレベルで複数の緩和策を持つ可能性があるということであり、その結果、これらの脅威に対する回復力が 向上することにつながります。
• 単一の脅威モデルに関する問題（例えば、まだ緩和されていない重大な脅威）は、ワークロード全体の起動ブロッカーにはならず、むしろ個々の機能だけの起動ブロッカーになり影響が局所化します。
• エンジニアリングチームは、社内の他のチームが構築したコンポーネントを、防御すべき「外部システム」と見なすかもしれません、つまり、チーム間の自然なコミュニケーションの難しさも、脅威モデルによって十分に検証されます。