脅威モデリング

脅威モデリングは、アプリケーションまたはコンピュータ・システムに害を及ぼす可能性がある脅威エージェントの種類を特定することによって機能します。悪意のあるハッカーの観点を導入して、どの程度の被害が起こり得るかを確認します。脅威モデリングを行う場合、組織はソフトウェア・アーキテクチャ、事業の状況、その他の成果物（機能仕様書やユーザー・ドキュメントなど）の徹底した分析を行います。このプロセスにより、システムの重要な側面をより深く理解し、発見することができます。通常、組織は新しいアプリケーションの設計段階で脅威モデリングを実施し（ただし、他の段階で発生する可能性があります）、開発者が脆弱性を見つけて、設計、コード、および構成の決定によるセキュリティへの影響を認識できるようにします。通常、開発者は次の4つのステップで脅威モデリングを行います。

• 図を作成する。何を構築するのか？
• 脅威を特定する。何が脅威となる可能性があるか？
• 低減する。脅威から防御するために何を行うか？
• バリデーションを行う。以前の各ステップに対して措置を講じたか？

脅威モデリングを正しく実行すると、ソフトウェア・プロジェクト全体にわたって明確な見通しが得られ、セキュリティの取り組みを正当化するのに役立ちます。脅威モデリング・プロセスは、組織がアプリケーションに対して知り得るセキュリティ脅威を文書化し、それに対処する方法について合理的な決定を下す際に役立ちます。正しく実行しないと、意思決定者は、乏しい証拠または裏付けがない証拠に基づいて、性急に行動する可能性があります。

全体として、十分に文書化された脅威モデルは、アプリケーションまたはコンピュータ・システムのセキュリティ態勢を説明および防御するうえで役立つ保証を提供します。また、開発組織がセキュリティに真剣に取り組むのであれば、脅威モデリングは次のことを行う場合の非常に効果的な方法です。

• コーディングを開始する前にソフトウェア開発ライフサイクル（SDLC）の初期段階で問題を検出する。
• 従来のテスト方法やコード・レビューでは見落としがちな設計上の欠陥を発見する。
• その他の手法では考慮しない可能性のある新たな形態の攻撃を評価する。
• テストとコード・レビューをターゲットにすることで、テスト予算を最大限に活用できる。
• セキュリティ要件を特定する。
• ソフトウェア・リリースの前に問題を修正し、導入後のコストのかかる再コーディングを防ぐ。
• アプリケーションに固有のセキュリティ問題に対する標準的な攻撃の範疇を超えた脅威を考察する。
• アプリケーション関連の内外の攻撃者から常にフレームワークを保護する。
• 資産、脅威エージェント、およびコントロールに照準を絞り、攻撃者がターゲットとするコンポーネントを推測する。
• 脅威エージェントの場所、意図、スキル、および能力のモデリングを行い、システムのアーキテクチャに関して、潜在的な攻撃者の場所を特定する。

セキュリティ・プロセスとして、脅威モデリングにはいくつかの誤解があります。脅威モデリングは設計段階のアクティビティにすぎないと考える人もいれば、ペネトレーション・テストまたはコード・レビューで代替できる任意の作業と考える人や、プロセスが単に複雑すぎると考える人もいます。以下は、このような誤解の一部を払拭するのに役立つはずです。

ペネトレーション・テストおよびコード・レビューは脅威モデリングの代わりとなることはできません。ペネトレーション・テストとセキュア・コード・レビューの2つは、コードのバグを見つけるのに効果的なアクティビティです。ただし、セキュリティ評価（脅威モデリングなど）は設計上の欠陥を特定するのに優れています。

デプロイメント後に脅威モデルを実施するのには十分な理由があります。現行のデプロイメントの問題を理解することは、将来のセキュリティ・アーキテクチャ戦略に影響を与え、弱点を監視することで、より迅速で効果的な修正が可能になります。アプリケーションが直面する潜在的な脅威を理解せずして、すべてのリスクに対処していると保証することはできません。

脅威モデリングはそれほど複雑ではありません。多くの開発者は、脅威モデリングという考えに及び腰になっています。一見、気が遠くなる作業のように思えるかもしれません。しかし、タスクを実行可能なステップに分割すると、単純なWebアプリケーションで（または複雑なアーキテクチャでも）脅威モデルの実行が体系的になります。重要なのは、基本的なベストプラクティスから始めることです。

脅威モデリングのキラー・アプリケーションは、チーム全体でのセキュリティの理解を促進します。セキュリティを全員の責任にすることへの第一歩です。概念的には、脅威モデリングはシンプルなプロセスです。脅威モデルを作成または更新するときは、次の5つの基本的なベストプラクティスを検討します。

1. 分析の範囲と深度を定義する。利害関係者と範囲を決定してから、個々の開発チームの分析の深度を細分化することで、ソフトウェアを脅威モデル化できるようにします。

2. 採用する脅威モデリングを視覚的に理解する。主要なシステム・コンポーネント（アプリケーション・サーバー、データ・ウェアハウス、シック・クライアント、データベースなど）およびコンポーネント間の相互作用の図を作成します。

3. 攻撃の可能性をモデリングする。ソフトウェア資産、セキュリティ管理策、脅威エージェントを特定し、その場所を図解して、システムのセキュリティ・モデルを作成します（図1を参照）。システムをモデル化したら、STRIDEのような方法を使用して、何が問題となる可能性があるか（つまり脅威）を特定できます。

4. 脅威を特定する。潜在的な攻撃のリストを作成するには、次のような質問事項を検討します。

                    脅威エージェントが管理策を通過せずに資産に到達できる経路はあるか？

                    脅威エージェントはこのセキュリティ管理策を打破することができるか？

                    この管理策を打破するには、脅威エージェントは何をする必要があるか？

5. 管理されていない、または管理が弱いセキュリティ管理策のトレーサビリティ・マトリックスを作成する。脅威エージェントを考慮し、管理策の経路に従います。セキュリティ管理策を通過せずにソフトウェア資産に到達できる場合、それは潜在的な攻撃です。管理策を通過した場合は、脅威エージェントを止めるかどうか、またはエージェントにそれをバイパスする方法があるかどうかを検討します。

図1：システムのセキュリティ・モデル。

Black Duckのソフトウェア・セキュリティ・サービスには脅威モデリングが含まれており、セキュア設計の違反、セキュリティ管理策の欠落、管理策の構成ミス、弱点、誤用など、システムの攻撃に対する感度を高める可能性のある潜在的な弱点を特定することができます。

Black Duckの高レベルなアプローチ

図2に示すように、脅威モデリングに対するシノプシスの高レベルなアプローチは、次の手順に従います。

• システムのモデリング。
• 脅威分析の実施。
• 脅威の優先順位付け。

図2: シノプシスの脅威モデリング・アプローチ。

システムのモデリングは次の2つの部分で構成されます。

1. 制御フロー・グラフを使用したコンポーネント図の作成（プログラムで可能なすべての実行パスを示します）
2. 資産、セキュリティ管理策、信頼ゾーン、脅威エージェントの特定

おそらく、脅威モデリングで最も重要なアクティビティは脅威を特定することです。ほとんどのアプローチは次の2つのカテゴリに分類されます。

• チェックリスト・ベースのアプローチ。多くの脅威モデリング・アプローチには、チェックリストまたはテンプレートが含まれます。たとえば、STRIDEでは、信頼境界を越えるすべてのデータ・フローについて、なりすまし、改ざん、否認、情報開示、サービス拒否、権限昇格の6種類の脅威を検討することを勧めています。
• 非チェックリスト・ベースのアプローチ。このアプローチは通常、攻撃を特定するためにクリエイティブな方法（ブレーンストーミングなど）を使用します。

シノプシスの脅威分析では、準チェックリスト・アプローチを使用します。テンプレートを使用してコア分析を推進しますが、依然としてクリエイティブな分析の機会を残します。シノプシスは、OAuth、SAML、OIDC、Kerberos、パスワード・ベースの認証など、一般的に使用されるアプリケーション・レベルのプロトコルに対して、事前に作成されたアプリケーション・プロトコル脅威分析を使用します。このリストは網羅的ではありませんが、 分析する関心領域について検討し始めることができます。

システムをモデリングして脅威分析を実行すると、脅威のリストが生成されます。この時点で、脅威の優先順位付けを行います。Black Duckでは、各脅威が重大となる可能性と影響を定量化するためのガイドラインを使用する、NISTアプローチを使用して脅威に優先順位を付けます。