脅威モデリングとは

この記事は約 2 分で読めます

脅威モデリングとは、システムやアプリケーションに対する潜在的な脅威を設計段階で体系的に洗い出し、優先順位を付けて対策を講じるセキュリティ設計手法です。「何を守るのか」「誰が攻撃するのか」「どこが弱いのか」を構造的に分析することで、開発の後工程で発覚するセキュリティ欠陥を大幅に削減できます。脆弱性が本番環境で発見されてから修正するコストは、設計段階の 30〜100 倍とされており、脅威モデリングは費用対効果の高い予防策です。

歴史的背景

脅威モデリングの概念は 1990 年代後半に Microsoft が社内のセキュリティ開発プロセス (SDL: Security Development Lifecycle) の一環として体系化したことに始まります。 2002 年の「Trustworthy Computing」宣言以降、 Microsoft は Windows や Office の開発に脅威モデリングを必須工程として組み込み、その成果を STRIDE モデルとして公開しました。以降、 OWASP や NIST もそれぞれのフレームワークに脅威モデリングを取り入れ、業界標準の設計手法として定着しています。

STRIDE モデル

STRIDE は Microsoft が開発した脅威分類フレームワークで、 6 種類の脅威カテゴリの頭文字を取ったものです。

DREAD スコアリング

STRIDE で脅威を分類した後、各脅威の深刻度を定量的に評価するのが DREAD です。 Damage (被害の大きさ)、 Reproducibility (再現性)、 Exploitability (攻撃の容易さ)、 Affected Users (影響を受けるユーザー数)、 Discoverability (発見の容易さ) の 5 項目をそれぞれ 1〜10 で採点し、合計スコアで優先順位を決定します。ただし、 DREAD は主観的な評価に偏りやすいという批判もあり、 Microsoft 自身も現在は CVSS (Common Vulnerability Scoring System) との併用を推奨しています。

PASTA フレームワーク

PASTA (Process for Attack Simulation and Threat Analysis) は、ビジネスリスクと技術的脅威を統合的に分析する 7 段階のフレームワークです。ビジネス目標の定義から始まり、技術スコープの特定、アプリケーション分解、脅威分析、脆弱性分析、攻撃シミュレーション、リスク・影響分析へと進みます。 STRIDE が技術者向けの分類ツールであるのに対し、 PASTA は経営層とエンジニアの共通言語として機能する点が特徴です。

データフロー図と信頼境界

脅威モデリングの核となるのがデータフロー図 (DFD) です。システム内のデータの流れを可視化し、信頼境界 (Trust Boundary) を明示します。信頼境界とは、セキュリティレベルが異なる領域の境目のことで、インターネットと社内ネットワークの境界、アプリケーション層とデータベース層の境界などが該当します。攻撃対象領域はこの信頼境界上に集中するため、境界を越えるすべてのデータフローに対して STRIDE の各脅威を検討します。

開発ライフサイクルへの組み込み

脅威モデリングは設計フェーズだけの作業ではありません。アジャイル開発ではスプリントごとに新機能の脅威を評価し、既存の脅威モデルを更新します。 CI/CD パイプラインに SAST (静的解析) や DAST (動的解析) を組み込み、脅威モデルで特定したリスクが実装レベルで対処されているかを自動検証するアプローチも広がっています。多層防御の設計を脅威モデリングの段階で計画し、レッドチーム演習でその有効性を検証するサイクルが理想的です。

洗い出した後に残す記録

脅威を並べる作業そのものよりも、その結果を後から使えるかどうかが実務上の差になる。ひとつは、対処しないと決めたものの扱いである。洗い出した項目のうち実際に手を入れるのは一部で、残りは影響が小さい、起こる条件が揃わない、費用に見合わないといった理由で見送られる。この見送りの判断が記録されないと、次に同じ箇所を検討するとき、判断があったこと自体が分からない。結果として同じ議論を繰り返すか、逆に検討済みという記憶だけが残り、根拠を確かめられない状態になる。残すべきは項目の一覧ではなく、見送った理由と、そのとき前提にした条件である。もうひとつは、その前提そのものである。この種の分析は必ず何かを信頼できるものとして扱う。ある区間の通信は保護されている、ある処理は内部からしか呼ばれない、ある値は手前で検査済みである、といった仮定を置いて初めて、検討すべき範囲が有限になる。仮定が変わると、それに支えられていた結論も同時に変わる。構成の一部を外部の仕組みに置き換えたときや、呼び出し元が増えたときに影響を受けるのはこの部分だが、仮定が書かれていなければ、どの結論を見直すべきかを特定できない。三つめは、図と実装の間に生じるずれである。図は作成した時点の設計を写したもので、実装が先に進めば図だけが古くなる。古いという事実は図を見ても現れないため、更新の契機を作業の側に置いておかないと、正しく見える図をもとに検討が進む。

組織のセキュリティ体制構築はスタートアップのセキュリティチェックリストで、パスワードポリシーの設計は企業パスワードポリシーの記事で、ランサムウェア対策はランサムウェア対策の記事で詳しく解説しています。