Vulnerability Management

Threat Modeling

脅威モデリング

Category: Vulnerability Management / Updated: 2026-05-26

📖

Overview

脅威モデリング(Threat Modeling)とは、システムやアプリケーションに対する潜在的なセキュリティ脅威を体系的に特定・分析・評価し、適切な対策を計画するためのプロアクティブなセキュリティ手法です。設計段階から脅威を洗い出すことで、開発ライフサイクルの早い段階でセキュリティリスクを軽減し、修正コストを大幅に削減することができます。

脅威モデリングでは、まずシステムのアーキテクチャを可視化し、データの流れ(データフローダイアグラム)や信頼境界(Trust Boundary)を明確にします。その上で、STRIDEPASTAなどのフレームワークを用いて、各コンポーネントや通信経路に対する脅威を体系的に洗い出します。特定された脅威に対しては、リスクの大きさを評価し、優先順位をつけて対策を実施します。

脅威モデリングは一度実施すれば終わりではなく、システムの変更やアーキテクチャの進化に合わせて継続的に更新する必要があります。アジャイル開発やDevSecOpsの環境では、スプリントごとに新機能や変更箇所に対する脅威モデリングを実施し、セキュリティを開発プロセスに組み込むことが推奨されています。

🔬

Details

STRIDEモデル

STRIDEはMicrosoftが開発した脅威分類フレームワークで、6つの脅威カテゴリーの頭文字から名付けられています。

  • Spoofing(なりすまし):正規ユーザーやシステムになりすまして不正アクセスを行う脅威
  • Tampering(改ざん):データや設定を不正に改変する脅威
  • Repudiation(否認):行為の痕跡を消去し、実行を否定する脅威
  • Information Disclosure(情報漏洩):機密情報が不正に開示される脅威
  • Denial of Service(サービス拒否):システムの可用性を損なう脅威
  • Elevation of Privilege(権限昇格):低権限から高権限への不正な昇格を行う脅威

PASTA(Process for Attack Simulation and Threat Analysis)

PASTAはリスクベースの脅威モデリング手法で、7つのステージで構成されています。ビジネス目標の定義から始まり、技術的なスコープの定義、アプリケーションの分解、脅威分析、脆弱性分析、攻撃モデリング、そしてリスクと影響の分析へと進みます。

PASTAの特徴は、攻撃者の視点からシミュレーションを行い、ビジネスインパクトと技術的な脅威を結びつけて優先順位を決定する点にあります。経営層とセキュリティチーム間のコミュニケーションを促進し、投資対効果の高いセキュリティ対策の実施を支援します。

データフローダイアグラム(DFD)

脅威モデリングの基盤となるのがデータフローダイアグラム(DFD)です。DFDでは、外部エンティティ(ユーザー、外部システム)、プロセス(処理ロジック)、データストア(データベース、ファイル)、データフロー(通信経路)を図式化します。

特に重要なのが信頼境界(Trust Boundary)の設定です。信頼レベルが変わるポイント(例:インターネットと内部ネットワークの境界、フロントエンドとバックエンドの間)を明確にし、境界を越えるデータフローに対して重点的に脅威を分析します。

DREAD(リスク評価モデル)

DREADは特定された脅威の深刻度をスコアリングするモデルです。Damage(被害の大きさ)、Reproducibility(再現性)、Exploitability(悪用の容易さ)、Affected Users(影響を受けるユーザー数)、Discoverability(発見の容易さ)の5つの観点で評価します。

各項目を1~10で評価し、合計スコアにより脅威の優先順位を決定します。ただし、主観的な評価になりがちという批判もあり、近年はCVSSスコアやカスタムのリスク評価マトリクスを併用する組織が増えています。

アジャイル開発における脅威モデリング

従来の脅威モデリングはウォーターフォール型の設計フェーズで実施されていましたが、アジャイル開発では短いスプリントサイクルに適応した手法が求められます。各スプリントで追加・変更される機能に対してインクリメンタルな脅威モデリングを実施し、既存の脅威モデルを段階的に更新していくアプローチが推奨されます。

ツールとしては、Microsoft Threat Modeling Tool、OWASP Threat Dragon、IriusRiskなどが広く利用されています。これらのツールはDFDの作成からSTRIDEに基づく脅威の自動生成、対策の推奨までを支援します。

🛡️

Security Measures

  • 01
    設計フェーズでの脅威モデリング必須化:新規システムや大規模な機能追加の設計レビュー時に、脅威モデリングの実施を必須プロセスとして組み込んでください。セキュリティチームと開発チームが協力してDFDを作成し、STRIDEに基づく脅威分析を行いましょう。
  • 02
    信頼境界の明確な定義と管理:アーキテクチャ図において信頼境界を明確に定義し、各境界を越えるデータフローに対する認証・認可・暗号化の要件を文書化してください。マイクロサービスアーキテクチャではサービス間の信頼境界も忘れずに定義しましょう。
  • 03
    脅威モデルの定期的な更新とレビュー:システムのアーキテクチャ変更、新しい脅威情報の入手、インシデント発生時に脅威モデルを更新してください。少なくとも年1回の定期レビューを実施し、脅威モデルが最新の状態を反映しているか確認しましょう。
  • 04
    攻撃ツリーによる脅威の深掘り分析:STRIDEで特定された脅威に対して、攻撃ツリー(Attack Tree)を作成し、攻撃者がどのような手順で脅威を実現するかを詳細に分析してください。これにより、対策の抜け漏れを防ぎ、より効果的な防御策を設計できます。
  • 05
    脅威モデリング結果のテストケースへの反映:脅威モデリングで特定された脅威を、セキュリティテストケースとして自動テストに組み込んでください。各脅威に対する対策が正しく実装されていることを継続的に検証し、回帰テストにも含めましょう。
  • 06
    全開発者への脅威モデリングトレーニング:セキュリティ専門家だけでなく、すべての開発者が基本的な脅威モデリングの手法を理解できるよう、定期的なトレーニングとワークショップを開催してください。脅威を意識した設計・実装が組織文化として定着することを目指しましょう。
⚠️

Incidents

📋 Capital One大規模情報漏洩と脅威モデリングの不備(2019年)

2019年、Capital Oneで約1億人の顧客情報が漏洩する事件が発生しました。AWS上のWAF(Web Application Firewall)の設定不備を悪用したSSRF(Server-Side Request Forgery)攻撃により、IAMロールの一時的な認証情報が取得され、S3バケットのデータが流出しました。

この事件は、クラウド環境における信頼境界の定義が不十分だったことが一因です。WAFからメタデータサービスへのアクセスという脅威パスが脅威モデルで十分に分析されていれば、IMDSv2の強制やネットワークセグメンテーションにより防止できた可能性があります。

📋 SolarWinds Orion サプライチェーン攻撃(2020年)

2020年に発覚したSolarWinds Orionのサプライチェーン攻撃は、ビルドパイプラインへの侵入により正規ソフトウェアにバックドアが埋め込まれたものです。約18,000の組織がマルウェアを含むアップデートを適用し、米国政府機関を含む多数の組織が侵害されました。

この事件は、ソフトウェアサプライチェーンを信頼境界の外として適切にモデリングすることの重要性を示しました。ビルドプロセスやサードパーティソフトウェアに対する脅威モデリングが不十分だったことが、攻撃の成功を許した要因の一つです。

📋 Uber社内システムへの侵入と権限昇格(2022年)

2022年、攻撃者がソーシャルエンジニアリングによりUber従業員のVPN認証を突破し、社内ネットワークに侵入しました。侵入後、内部のネットワーク共有ドライブに保存されていた特権認証情報を発見し、AWS、Google Cloud、各種SaaSツールの管理者権限を取得しました。

この事件は、内部ネットワークにおける水平移動(ラテラルムーブメント)と権限昇格の脅威パスが脅威モデルで十分に考慮されていなかったことを示しています。ゼロトラストアーキテクチャの採用と、認証情報の安全な管理が脅威モデリングの結果として導入されていれば、被害を最小限に抑えられた可能性があります。

🔗

Related Terms