脅威モデリング

付録A. 実例

システムモデルの構築、システムに関する情報の引き出し、潜在的な脆弱性や脅威の抽象化分析に至るまで、脅威モデリングのプロセスを深く理解していただけたと思う。ここでは、理解をより確かなものにするために、例を挙げて説明する。

注

この文書は静的な文書であり、脅威モデリングに通常必要とされるレベルの双方向性を欠いているため、以下のプロセスステップは「舞台を設定」し、「結末を明らかにする」ために凝縮されている（ここではネタバレはしない！）。このアプローチから、どのような方法論を選択するにせよ、あなた自身が脅威モデリングにどのように取り組めばよいかがわかるはずである。

ハイレベルのプロセス・ステップ

第2章を思い出しながら、このサンプルで行うハイレベルな脅威 モデリングの手順を以下に示す：

1. 対象システムのオブジェクトを特定する。

2. これらのオブジェクト間のフローを特定する。

3. 関心のある資産を特定する。

4. 資産への影響の可能性を判断する。

5. 脅威を特定する。

6. 悪用可能性を判断する。

脅威の特定に続いて、不具合の報告、緩和策の検討、システム開発チームとの座標調整などが行われる。このサンプルでは、これらのステップについては触れない。

初めてのシステムモデルにアプローチする

モデリングの基本的なプロセスは、 システムの主要な構成要素を特定することから始まる。これらは、アプリケーション、サーバ、データベース、データストア、またはその他のものである。次に、各主要構成要素への接続を特定する：

• アプリケーションはAPIやユーザインタフェースをサポートしているか？

• サーバは何らかのポートをリッスンしているか？もしそうなら、どのプロトコルでリッスンしているか？

• 何がデータベースと通信するのか、それはデータを読み取るだけなのか、それともデータも書き込むのか？

• データベースはどのようにアクセスを制御しているのか？

会話のスレッドをたどり続け、必要な接続、インタフェース、プロトコル、データストリームがすべて完了するまで、システムモデルのこのコンテキストレイヤーにあるすべてのエンティティを反復する。

次に、エンティティ（通常はアプリケーションやサーバの要素）の中から、 懸念事項を特定するために明らかにする必要がある追加的な詳細を含む可能性のあるものを 1 つ選択し、それをさらに分解する。アプリケーションへの／からのエントリ点と出口点、及び、着目しているコンポー ネントと他のコンポーネントやエンティティとの間でデータや他のメッセージを伝達する通信チャネルに着目し てください。

チップ

チームとのエンゲージメント中に確認した情報に基づいて、システムモデルを注釈で更新する。

脅威モデリング演習では、脆弱性と脅威の特定を支援する情報を収集するために、自分の判断力とセキュ リティの原則と技術に関する知識を活用する必要がある。

作業を開始する前に、脅威モデリング手法を選択し、選択した手法がグラフィカルモデ ルを想定している場合は、使用するシンボルセット（ ）を定義する。このサンプルでは、データフロー図（DFD）を主なモデリング手法として使用し、オプションのイニシエータマークを含める。

脅威モデリング演習を指導する

モデリング演習のリーダーとして、適切な利害関係者を必ず参加させる。リードアーキテクトがいる場合は、他の設計者や開発リードと同様に、セッションに招待する。QAリードの招待も検討すべきである。プロジェクトチームの全メンバーに、モデルの構築に意見を提供するよう奨励する。ただし、現実的な問題として、出席者の時間と関心を最大化するために、出席者リストは管理可能な範囲にとどめることを推奨する。 ...