脅威モデリングとは
脅威モデリングとは、システムやプロセスに対する潜在的な脅威を体系的に特定し、リスクを評価し、対策の優先順位を決定するセキュリティ分析手法です。「何を守るべきか」「誰が攻撃してくるか」「どのように攻撃されるか」「どう対策すべきか」を明確にします。
脅威モデリングには、主に3つのアプローチがあります。
- 資産中心アプローチ
- 守るべき資産（データ、システム、知的財産等）を特定し、それらに対する脅威を分析する。「何が重要か」から考える。
- 攻撃者中心アプローチ
- 想定される攻撃者（ハッカー、競合他社、内部犯行者等）を特定し、その動機と能力から脅威を分析する。「誰が攻撃するか」から考える。
- ソフトウェア中心アプローチ
- システムのアーキテクチャ、データフロー、信頼境界を分析し、各コンポーネントへの脅威を特定する。「どのように動くか」から考える。
| アプローチ | 開始点 | 適している場面 |
|---|---|---|
| 資産中心 | 守るべき資産 | データ保護、知的財産保護 |
| 攻撃者中心 | 想定攻撃者 | APT対策、競合分析 |
| ソフトウェア中心 | システム設計 | 開発段階、アーキテクチャ見直し |
サプライチェーン攻撃対策としての脅威モデリングでは、これらのアプローチを組み合わせ、自組織だけでなく外部の依存先まで含めた広い視野で分析することが重要です。
サプライチェーン攻撃への脅威モデリング適用
サプライチェーン攻撃に対する脅威モデリングは、通常の脅威モデリングとは異なる点があります。
通常の脅威モデリングとの違い
通常の脅威モデリングは、自組織のシステム境界内を分析対象とします。しかし、サプライチェーン攻撃では、外部の依存先が攻撃経路となるため、分析範囲を拡大する必要があります。
- 分析範囲の広さ
- 自組織のシステムだけでなく、ソフトウェアの依存関係（OSS、ライブラリ）、外部サービス（クラウド、SaaS、MSP）、取引先・委託先まで含める必要がある。
- 信頼境界の複雑さ
- 「信頼できる」と見なしていた外部コンポーネントが侵害される可能性を考慮。SolarWinds事件では、信頼されたソフトウェアベンダーが侵害された。
- 可視性の限界
- 外部の依存先の内部状況は直接把握できない。契約、監査、認証などで間接的に評価する必要がある。
サプライチェーン特有の考慮点
| 考慮点 | 説明 | 例 |
|---|---|---|
| 推移的リスク | 依存先の依存先（n次委託）のリスクも波及 | OSSの間接依存、再委託先 |
| 信頼の連鎖 | 信頼が連鎖的に破綻する可能性 | 認証局の侵害、署名鍵の漏洩 |
| 集中リスク | 多くの組織が同じサプライヤーに依存 | クラウドプロバイダー、人気OSS |
| 可視性の欠如 | 依存関係の全容を把握困難 | 間接依存、シャドーIT |
標的型攻撃（APT）グループは、直接標的を攻撃するよりも、サプライチェーンを経由する方が効率的であることを認識しています。脅威モデリングでは、このような高度な攻撃者も想定する必要があります。
攻撃面（アタックサーフェス）の特定
サプライチェーン攻撃への脅威モデリングの第一歩は、攻撃面（アタックサーフェス）を特定することです。攻撃面とは、攻撃者がシステムに侵入または影響を与えることができるすべてのポイントです。
外部依存の洗い出し
まず、自組織が依存している外部のコンポーネント、サービス、組織を洗い出します。
- ソフトウェア依存
- OSS、商用ライブラリ、フレームワーク、ランタイム、OS、ミドルウェアなど。SBOMを活用して依存関係を可視化。直接依存だけでなく、推移的依存（間接依存）も含める。
- サービス依存
- クラウドサービス（IaaS、PaaS、SaaS）、CDN、DNS、認証サービス（IdP）、決済サービス、MSP（マネージドサービスプロバイダー）など。
- 組織依存
- 取引先、委託先、再委託先、ビジネスパートナー、監査法人など。サードパーティリスク管理（TPRM）の対象。
| 依存の種類 | 把握方法 | 管理ツール・手法 |
|---|---|---|
| ソフトウェア | SBOM、依存関係ツリー | Syft、Trivy、Dependency-Track |
| サービス | 契約一覧、IT資産管理 | CMDB、サービスカタログ |
| 組織 | 取引先一覧、契約管理 | VRM（Vendor Risk Management）ツール |
接続ポイントの特定
外部との接点、特にデータや制御が行き来するポイントを特定します。
- API接続：REST API、GraphQL、SOAP等による外部サービスとの連携
- EDI接続：電子データ交換による取引先との連携
- VPN接続：取引先、リモートオフィス、委託先との接続
- リモートアクセス：保守ベンダー、クラウドサポート等のアクセス
- ファイル転送：SFTP、クラウドストレージ経由のデータ交換
データフローの分析
データがどのように流れるかを可視化し、信頼境界を特定します。
- 信頼境界とは
- 異なる信頼レベルを持つコンポーネント間の境界。信頼境界を越えるデータは、検証や暗号化が必要。
- 機密データの経路
- 個人情報、認証情報、機密ビジネスデータがどの経路を通るかを特定。外部サービスに送信されるデータ、外部から受信するデータに注目。
データフロー図（DFD：Data Flow Diagram）を作成し、外部プロセス、データストア、データフローを可視化することが有効です。
依存関係の分析
攻撃面を特定したら、次は依存関係を詳細に分析します。
ソフトウェア依存の分析
SBOMを活用して、ソフトウェアの依存関係を分析します。
- 依存関係ツリーの把握
- 直接依存するパッケージと、推移的依存（間接依存）の全体像を把握。Log4Shell脆弱性のように、間接依存に深刻な脆弱性が潜んでいる可能性がある。
- リスクの高い依存の特定
- メンテナンスが放棄されたパッケージ、単一メンテナーのパッケージ、脆弱性履歴が多いパッケージ、ライセンスが不明確なパッケージを特定。
| リスク指標 | 確認方法 |
|---|---|
| メンテナンス状況 | 最終コミット日、イシュー対応状況 |
| コントリビューター | 単一 vs 複数、組織 vs 個人 |
| 脆弱性履歴 | 過去のCVE、対応速度 |
| 利用状況 | ダウンロード数、依存されている数 |
OSSの安全な利用で解説した評価基準も参考にしてください。
サービス依存の分析
クラウドサービス、SaaSなどの外部サービスへの依存を分析します。
- サービスの連鎖：利用しているSaaSが、さらに別のサービスに依存している可能性
- 単一障害点：特定のサービスが停止した場合の影響範囲
- データの所在：データがどの地域のどのインフラに保存されているか
- アクセス権限：サービスプロバイダーが自社データにアクセスできる範囲
組織依存の分析
取引先、委託先との依存関係を分析します。
- 再委託先への波及
- 委託先がさらに再委託している場合、リスクは連鎖的に波及する。再委託先の管理状況、セキュリティレベルも考慮が必要。
- 集中リスク
- 複数の重要業務が同一のサプライヤーに依存している場合、そのサプライヤーの障害が事業全体に影響。
サードパーティリスク管理（TPRM）の枠組みで、組織依存を管理することが推奨されます。
脅威の特定とリスク評価
依存関係を分析したら、具体的な脅威を特定し、リスクを評価します。
STRIDEモデルの適用
STRIDEは、Microsoftが開発した脅威分類モデルです。6つのカテゴリで脅威を体系的に特定できます。
| 脅威カテゴリ | 説明 | サプライチェーン攻撃での例 |
|---|---|---|
| Spoofing（なりすまし） | 偽のIDでアクセス | 偽のパッケージ、偽の取引先 |
| Tampering（改ざん） | データやコードの改変 | ビルドパイプライン侵害、パッケージ改ざん |
| Repudiation（否認） | 行為の否認 | 監査ログ改ざん、署名なしソフトウェア |
| Information Disclosure（情報漏洩） | 機密情報の流出 | 依存先からの情報漏洩 |
| Denial of Service（DoS） | サービス妨害 | 依存サービスの停止 |
| Elevation of Privilege（権限昇格） | 不正な権限取得 | 依存パッケージ経由の権限奪取 |
各依存関係に対して、STRIDEの6カテゴリで脅威を検討します。
脅威シナリオの作成
具体的な攻撃シナリオを記述することで、脅威をより具体的に理解できます。
- 攻撃シナリオの例
- 「攻撃者Aは、人気OSSパッケージXのメンテナー権限をソーシャルエンジニアリングで取得し、バックドアを混入。当社の製品Yはパッケージに依存しており、ビルド時にバックドアが組み込まれる。製品Yを利用する顧客環境に攻撃者がアクセス可能になる。」
- 攻撃者の視点で考える
- 攻撃者の動機（金銭、国家支援、競合攻撃等）、能力（スキル、リソース）、機会（脆弱な依存先）を考慮。
リスクスコアリング
特定した脅威に対して、リスクを定量的に評価します。
- リスク = 影響度 × 発生可能性
- 影響度：脅威が現実化した場合のビジネスへの影響（財務、評判、法的責任等）
発生可能性：脅威が現実化する可能性（脆弱性の存在、攻撃者の動機等）
| 影響度：低 | 影響度：中 | 影響度：高 | |
|---|---|---|---|
| 発生可能性：高 | 中リスク | 高リスク | 最高リスク |
| 発生可能性：中 | 低リスク | 中リスク | 高リスク |
| 発生可能性：低 | 最低リスク | 低リスク | 中リスク |
リスクマトリクスを使用して優先順位を決定し、高リスクの脅威から優先的に対策を講じます。
脅威モデリングの実施方法
脅威モデリングを実際に実施する方法を紹介します。
ワークショップ形式
関係者を集めたワークショップは、脅威モデリングの効果的な実施方法です。
- 参加者
- 開発者、セキュリティチーム、アーキテクト、運用チーム、ビジネス担当者など、異なる視点を持つメンバーを含める。
- ファシリテーション
- セキュリティの専門知識を持つファシリテーターが議論を導く。STRIDEなどのフレームワークに沿って体系的に進行。
- 成果物
- 脅威一覧、リスク評価結果、対策計画を文書化。
- 対象システム・プロセスの説明（アーキテクチャ図、データフロー図）
- 資産の特定（何を守るべきか）
- 攻撃面の特定（外部依存、接続ポイント）
- 脅威の特定（STRIDEを使用）
- リスク評価（影響度×発生可能性）
- 対策の検討と優先順位付け
ツールの活用
脅威モデリングを支援するツールがあります。
| ツール | 特徴 | 提供元 |
|---|---|---|
| Microsoft Threat Modeling Tool | STRIDEベース、DFD作成、脅威自動生成 | Microsoft（無料） |
| OWASP Threat Dragon | オープンソース、Webベース | OWASP（無料） |
| IriusRisk | 商用、自動化、統合機能 | IriusRisk社 |
| ThreatModeler | 商用、エンタープライズ向け | ThreatModeler社 |
継続的な見直し
脅威モデリングは一度きりではなく、継続的に見直す必要があります。
- 変更時：システム変更、新規サービス導入、取引先追加時に見直し
- 定期的：年次または半期ごとの定期レビュー
- インシデント後：セキュリティインシデント発生後の振り返り
- 脅威情報更新時：新たな攻撃手法や脆弱性が発見された際
変更管理プロセスと連携し、変更がセキュリティに与える影響を評価する仕組みを構築しましょう。
脅威モデリングの成果物
脅威モデリングの結果は、以下の成果物として文書化します。
- 脅威一覧
- 特定されたすべての脅威のリスト。脅威ID、説明、影響を受ける資産/コンポーネント、攻撃ベクトルを含む。
- リスク評価結果
- 各脅威のリスクスコア（影響度×発生可能性）、優先順位付け、リスクマトリクス。
- 対策計画
- 各脅威に対する対策案、担当者、期限、必要なリソース。対策の種類（回避、軽減、移転、受容）。
- 残存リスク
- 対策後も残るリスクの一覧。受容可能なリスクレベルかどうかの判断。経営層への報告事項。
これらの成果物は、インシデント対応計画の策定や、セキュリティ教育・訓練のシナリオ作成にも活用できます。
関連する攻撃手法
脅威モデリングで特定すべきサプライチェーン関連の攻撃手法を紹介します。
| 攻撃手法 | 脅威モデリングでの考慮点 |
|---|---|
| ソフトウェアサプライチェーン攻撃 | ソフトウェア依存関係の分析、ビルドパイプラインの保護 |
| ビジネスサプライチェーン攻撃 | 取引先依存の分析、信頼関係の評価 |
| サービスサプライチェーン攻撃 | 外部サービス依存の分析、MSPリスク |
| 標的型攻撃（APT） | 高度な攻撃者を想定したシナリオ |
| 内部不正 | 内部関係者によるサプライチェーン悪用 |
| ゼロデイ攻撃 | 未知の脆弱性への対応体制 |
| 情報漏洩 | 依存先からの情報流出リスク |
よくある質問
- Q: 脅威モデリングはどの頻度で実施すべきですか？
- A: 大きなシステム変更、新規サービス導入、主要な取引先追加時には必ず実施すべきです。また、年次または半期ごとの定期レビューも推奨されます。新たな攻撃手法や脆弱性が発見された場合、自組織への影響を評価するために追加レビューを行うことも有効です。継続的な見直しにより、脅威モデリングの有効性を維持できます。
- Q: 小規模な組織でも脅威モデリングは必要ですか？
- A: はい、組織規模に関わらず脅威モデリングは有効です。小規模組織では、大規模なワークショップを開催する必要はありません。主要な依存関係（クラウドサービス、重要取引先、使用しているOSS）に焦点を絞り、簡易的な分析から始めることができます。脅威モデリングの本質は「何がリスクか」を考えることであり、形式よりも思考プロセスが重要です。
- Q: 脅威モデリングにはどのくらいの時間がかかりますか？
- A: 対象範囲と深さによりますが、初回のワークショップは2〜4時間程度が一般的です。複雑なシステムや広範なサプライチェーンを対象とする場合は、複数回のセッションに分けることもあります。一度フレームワークを確立すれば、更新レビューは初回より短時間で実施できます。重要なのは「完璧な分析」よりも「継続的な改善」です。
- Q: 外部の専門家に依頼すべきですか？
- A: 組織のセキュリティ成熟度によります。脅威モデリングの経験がない組織では、最初は外部の専門家にファシリテーションを依頼し、手法を学ぶことが有効です。ただし、内部の関係者の参加は必須です。外部専門家だけでは、組織固有のビジネスコンテキストや依存関係を十分に理解できません。内部と外部の知見を組み合わせることがベストプラクティスです。
- Q: 脅威モデリングの結果はどう活用すべきですか？
- A: 脅威モデリングの結果は、セキュリティ対策の優先順位付け、予算配分の根拠、開発プロセスへのセキュリティ要件組み込み、インシデント対応計画の策定、取引先セキュリティ要件の設定などに活用できます。結果を経営層に報告し、リスクに関する意思決定の材料とすることも重要です。
まとめ
本記事では、サプライチェーン攻撃対策としての脅威モデリングについて解説しました。主なポイントは以下の通りです。
- 脅威モデリングは、潜在的な脅威を体系的に特定し、リスクを評価し、対策の優先順位を決定する手法
- サプライチェーン攻撃の脅威モデリングでは、**外部依存**（ソフトウェア、サービス、組織）まで分析範囲を拡大
- 攻撃面（アタックサーフェス）の特定では、外部依存の洗い出し、接続ポイントの特定、データフローの分析を実施
- 依存関係の分析では、SBOMを活用したソフトウェア依存、サービス依存、組織依存を詳細に分析
- STRIDEモデルで脅威を体系的に特定し、リスクマトリクスで優先順位を決定
- ワークショップ形式で関係者を集め、Microsoft Threat Modeling ToolやOWASP Threat Dragonなどのツールを活用
- 脅威モデリングは**継続的に見直し**、変更管理と連携することが重要
技術者向けカテゴリの全体像については、サプライチェーン攻撃の技術対策｜SBOM・CI/CD・OSS・EDIをご覧ください。
サプライチェーン攻撃の総合的な理解には、サプライチェーン攻撃とは｜仕組み・事例・対策を初心者にもわかりやすく解説もあわせてご参照ください。
重要なお知らせ
- 本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません。
- 実際にサイバー攻撃の被害に遭われた場合は、警察（#9110）やIPA（03-5978-7509）などの公的機関にご相談ください。
- 法的な対応が必要な場合は、弁護士などの専門家にご相談ください。
- 記載内容は作成時点の情報であり、攻撃手法は日々進化している可能性があります。
サプライチェーン攻撃 完全ガイド ナビゲーション
総合ガイド
目的別に探す
役職・立場別に探す
技術対策（技術者向け）
- SBOM
- CI/CD・SLSA
- OSSセキュリティ
- npmセキュリティ
- EDIセキュリティ
- 脅威モデリング（現在のページ）
業種別に探す
人気のページ
更新履歴
- 初稿公開
