フレームワーク活用ガイドひとことで言うと#
システムに対する脅威を Spoofing（なりすまし）・Tampering（改ざん）・Repudiation（否認）・Information Disclosure（情報漏洩）・Denial of Service（サービス拒否）・Elevation of Privilege（権限昇格）の6分類で網羅的に洗い出し、対策の優先順位を決めるセキュリティ設計手法。
押さえておきたい用語#
- Spoofing（スプーフィング）
- 正規ユーザーやシステムになりすましてアクセスする脅威のこと。認証の突破や偽装が典型例。
- Tampering（タンペリング）
- データや通信内容を不正に改ざんする脅威を指す。リクエストの書き換えやDB直接操作が該当する。
- Repudiation（リピュディエーション）
- 操作を行ったにもかかわらず**「やっていない」と否認できてしまう脅威**である。監査ログの不備が原因になる。
- Information Disclosure（インフォメーション ディスクロージャー）
- 機密データが意図しない相手に漏洩する脅威のこと。暗号化不備やアクセス制御の欠陥が典型例。
- Denial of Service（サービス拒否）
- 大量リクエストやリソース枯渇によりサービスを利用不能にする脅威。可用性を直接脅かす攻撃手法。
- Elevation of Privilege（権限昇格）
- 一般ユーザーが管理者権限を不正に取得する脅威を指す。認可ロジックの不備が主な原因となる。
STRIDE脅威モデリングの全体像#
こんな悩みに効く#
- セキュリティレビューが「思いつきベース」で網羅性に自信がない
- 開発チームがセキュリティを後回しにし、リリース直前に問題が見つかる
- 脅威の洗い出し方法がわからず、外部のペネトレーションテストに頼りきり
基本の使い方#
具体例#
エンジニア45名のECプラットフォーム。PCI DSS準拠の更新審査を控え、決済フロー全体のセキュリティレビューが必要だった。従来は「経験者の勘」で脅威を列挙していたが、審査員から「網羅性の根拠がない」と指摘されていた。
決済フローのDFDを作成し、STRIDEを適用。38件 の脅威が洗い出され、そのうち 7件 が既存の対策でカバーされていなかった。特に「決済APIへのリプレイ攻撃（Tampering）」と「管理画面の権限昇格（Elevation of Privilege）」が高リスクと判定された。
対策実装後、PCI DSS審査を 1回 で通過。以前は平均 2.5回 の再審査が必要だった。
エンジニア20名の医療SaaS。HIPAA準拠が求められる中、セキュリティ設計が各チームの裁量に任されており、API 120本 のうちセキュリティレビュー済みは 35本 にとどまっていた。
新機能開発プロセスにSTRIDE脅威モデリングを組み込み、Design Doc段階で必須化。チーム全員が参加するワークショップ形式で実施し、1機能あたり 90分 で完了するテンプレートを整備した。
6ヶ月で全APIのレビューが完了。Information Disclosure関連の脆弱性 12件 を本番デプロイ前に発見・修正し、セキュリティインシデントの発生件数は四半期 5件 → 0件 になった。
エンジニア30名の自治体向けシステムベンダー。入札時のセキュリティ提案がチェックリスト形式で競合と差別化できず、価格勝負に陥っていた。
提案段階でSTRIDE脅威モデリングの結果を添付する方式に変更。自治体側のシステム構成からDFDを起こし、想定脅威と対策を可視化して提案書に含めた。
セキュリティ提案の説得力が「具体的な脅威と対策のマッピング」として評価され、受注率が 28% → 52% に向上。単価も平均 15% 上昇した。
やりがちな失敗パターン#
- DFDなしで脅威を列挙する — システムの全体像なしにSTRIDEを適用しても漏れが出る。まずデータフロー図を描くことが出発点
- すべての脅威に同じ優先度で対策する — 脅威の数は膨大になる。リスク評価で優先度を付け、高リスクから順に対策する
- 開発完了後にSTRIDEを実施する — 設計段階で行うから効果がある。実装後の変更はコストが 10〜100倍 になる
- 1回だけ実施して終わり — システムは変化する。新機能追加やアーキテクチャ変更のたびに差分のSTRIDEを実施する
まとめ#
STRIDE脅威モデリングは、Microsoftが開発した6分類（Spoofing・Tampering・Repudiation・Information Disclosure・Denial of Service・Elevation of Privilege）でセキュリティ脅威を網羅的に洗い出す手法。DFDによるシステム可視化からSTRIDE適用、リスク評価、対策実装までの一連のプロセスにより、「思いつきベース」 から「体系的」なセキュリティ設計への転換を実現する。設計段階で実施することが最も費用対効果が高い。