脅威モデリング入門：設計段階でセキュリティリスクを洗い出す

はじめに

多くのセキュリティ脆弱性は、コーディング段階のミスではなく、設計段階での考慮漏れに起因します。リリース後に設計上の欠陥を修正するのは、多大なコストと時間がかかります。「脅威モデリング」は、開発の初期段階、つまり設計段階で、システムに潜むセキュリティリスクを体系的に洗い出し、対策を検討するための構造化されたアプローチです。

なぜ脅威モデリングが必要か？

• セキュリティのシフトレフト: 開発ライフサイクルの早い段階で問題を特定し、手戻りを減らす。
• 網羅的なリスク分析: アドホックな脆弱性診断では見逃しがちな、設計レベルのリスクを特定できる。
• 共通言語の提供: 開発者、運用者、セキュリティ担当者が、システムのセキュリティについて具体的に議論するための共通の土台となる。

脅威モデリングの4つのステップ

Step 1: 対象の分析 (What are we working on?)

• データフロー図 (DFD) の作成: システムを構成するコンポーネント（プロセス、データストア、外部エンティティ）と、それらの間のデータの流れを可視化します。これにより、攻撃者が狙う可能性のある箇所（アタックサーフェス）が明確になります。

Step 2: 脅威の洗い出し (What can go wrong?)

• STRIDEフレームワークの活用: Microsoftが提唱した脅威の分類フレームワークであるSTRIDEを使って、脅威を網羅的に洗い出します。
  • Spoofing (なりすまし)
  • Tampering (改ざん)
  • Repudiation (否認)
  • Information Disclosure (情報漏洩)
  • Denial of Service (サービス拒否)
  • Elevation of Privilege (権限昇格)

Step 3: 対策の検討 (What are we going to do about it?)

• 洗い出した脅威に対して、どのようなセキュリティ対策を講じるかを決定します。「修正」「軽減」「転移」「受容」の4つの選択肢があります。

Step 4: 検証 (Did we do a good job?)

• 対策が正しく実装されているか、テストやコードレビューで確認します。また、新たな機能追加があった際には、脅威モデルを更新し、プロセスを繰り返します。

まとめ

脅威モデリングは、一度きりの作業ではありません。システム設計の変更や新たな脅威の出現に合わせて、継続的に見直していくリビングドキュメントです。最初は難しく感じるかもしれませんが、まずは小規模な機能からでもデータフロー図を描き、STRIDEを使って脅威を考えてみることから始めてみましょう。この習慣が、堅牢なシステム設計の第一歩となります。