threat-modeling

脅威モデリング

このスキルにより、エージェントはソフトウェアアプリケーション、API、インフラストラクチャの構造化された脅威モデリングを実行できます。エージェントは、システムアーキテクチャ、データフロー、信頼境界を分析し、STRIDE、DREAD、PASTA、攻撃ツリーなどの確立された手法を用いて、潜在的なセキュリティ脅威を体系的に特定します。出力として、開発チームがバックログに取り込める、具体的で実行可能な緩和策を含む、優先順位付けされた脅威一覧を作成します。

ワークフロー

1. システムアーキテクチャを分解する — アーキテクチャ図、コードリポジトリ、Infrastructure as Code ファイル、デプロイ設定を分析し、すべてのコンポーネント、データストア、外部サービス、通信チャネルを特定します。ネットワーク、サービス、ユーザー権限レベル間の信頼境界をマッピングします。システム内でデータがどのように移動するかを示すデータフロー図（DFD）を作成します。

2. 脅威モデリング手法を選択する — プロジェクトのニーズに基づいて適切な手法を選びます。コンポーネントごとに脅威カテゴリを体系的に列挙するには STRIDE を使用します。既知の脅威のスコアリングと優先順位付けには DREAD を使用します。ビジネス目標に沿ったリスク中心の分析には、PASTA（Process for Attack Simulation and Threat Analysis）を使用します。認証や決済システムなど、特定の価値の高い対象を詳細に分析するには攻撃ツリーを使用します。

3. 脅威を列挙する — DFD 内の各コンポーネントとデータフローに、選択した手法を適用します。STRIDE では、各要素を 6 つの脅威カテゴリすべて（なりすまし、改ざん、否認、情報漏えい、サービス拒否、権限昇格）に照らして評価します。各脅威に一意の識別子、説明、影響を受けるコンポーネント、越境する信頼境界を記載します。

4. リスクを評価し、優先順位を付ける — DREAD（Damage、Reproducibility、Exploitability、Affected Users、Discoverability）または同様の定量的なフレームワークを使用して、各脅威をスコアリングします。スコアにビジネス上の状況を加味します。同じ脅威でも、決済サービスへの脅威は内部管理ダッシュボードへの脅威より優先度が高くなります。順位付けされた脅威一覧を作成します。

5. 緩和策とセキュリティ制御を定義する — 優先度が高または中の各脅威について、アーキテクチャの変更、コードレベルの修正、設定の強化、運用上の制御など、具体的な緩和策を指定します。該当する場合は、緩和策をセキュリティフレームワーク（NIST 800-53、CIS Controls）に対応付けます。各緩和策の実装工数を見積もります。

6. 脅威モデルを文書化し、維持する — DFD、脅威一覧、リスクスコア、緩和策の状況を記録した、継続的に更新するドキュメントを作成します。アーキテクチャの変更、新機能の追加、新たな攻撃手法の出現に応じて脅威モデルを更新します。脅威モデルのレビューをスプリント計画と設計レビューのプロセスに組み込みます。

対応技術

• 手法：STRIDE、DREAD、PASTA、攻撃ツリー、VAST（Visual Agile Simple Threat modeling）
• 図表作成：データフロー図（DFD）、Mermaid、draw.io、Microsoft Threat Modeling Tool
• アーキテクチャの種類：モノリス、マイクロサービス、サーバーレス、イベント駆動型、モバイルバックエンド、IoT システム
• インフラストラクチャ：AWS、GCP、Azure、Kubernetes、オンプレミスとのハイブリッド環境
• 標準への対応付け：OWASP Top 10、MITRE ATT&CK、NIST 800-53、CIS Controls

使用方法

アーキテクチャのドキュメント、ソースコード、Infrastructure as Code ファイル、またはシステムの説明を参照できるようにエージェントを設定します。希望する手法と、対応付けるコンプライアンス標準を指定します。エージェントは、優先順位付けされた脅威一覧と緩和計画を含む、完全な脅威モデルを作成します。

プロンプトの例：

Perform a STRIDE threat model on our microservices architecture. The services are defined in /infra/docker-compose.yml and the source code is in /services/. Focus on the API gateway, authentication service, and payment service. Map findings to OWASP Top 10.

例

例 1：マイクロサービス型 E コマースプラットフォームの STRIDE 分析

システムコンポーネント：API Gateway、Auth Service、Product Service、Payment Service、PostgreSQL データベース、Redis キャッシュ、RabbitMQ メッセージブローカー。

STRIDE 脅威テーブル：

ID	コンポーネント	STRIDE カテゴリ	脅威の説明	リスク	OWASP	緩和策
T-01	API Gateway	なりすまし	攻撃者が JWT トークンを偽造し、ユーザーになりすまします	高	A07:2021	キーローテーションを行いながら RS256 で JWT 署名を検証し、HS256 トークンを拒否します
T-02	API Gateway	サービス拒否	大量のトラフィックによる攻撃でゲートウェイが過負荷になり、正規のトラフィックが遮断されます	高	—	クライアント IP と API キーごとにレート制限を実装し、DDoS 対策を備えた CDN の背後に配置します
T-03	Auth Service	なりすまし	流出したユーザー名／パスワードのデータベースを利用したクレデンシャルスタッフィング	高	A07:2021	MFA を必須にし、/login のレート制限を実装し、漏えい検知 API（HaveIBeenPwned）と連携します
T-04	Auth Service	否認	ユーザーが機密性の高い操作（例：メールアドレスの変更）を行ったことを否認します	中	A09:2021	すべての認証イベントとアカウント変更を、タイムスタンプと送信元 IP を含む改ざん不能な監査ログに記録します
T-05	Payment Service	改ざん	攻撃者が Product Service と Payment Service 間の通信中に注文合計額を改ざんします	重大	A04:2021	サービス間メッセージに HMAC 署名を付与し、Payment Service はリクエストのペイロードを信用せず、データベースから価格を再取得します
T-06	Payment Service	情報漏えい	クレジットカード番号がアプリケーションログに平文で記録されます	重大	A02:2021	すべてのログで PAN データをマスキングし、PCI 準拠のトークン化サービスを使用し、ログへのアクセスを制限します
T-07	PostgreSQL	改ざん	Product Service の検索エンドポイントを介した SQL インジェクションにより、データベースのレコードが改ざんされます	高	A03:2021	パラメーター化クエリのみを使用し、サービスごとに最小権限のデータベースロールを適用します
T-08	RabbitMQ	情報漏えい	サービス間で転送中のメッセージを、ネットワーク上の攻撃者が読み取れます	中	A02:2021	すべての RabbitMQ 接続で TLS を有効にし、機密性の高いメッセージのペイロードをアプリケーション層で暗号化します
T-09	Redis Cache	権限昇格	認証されていない Redis インスタンスにより、あらゆるサービスがセッションデータを読み書きできます	高	A01:2021	強力なパスワードを設定して Redis AUTH を有効にし、プライベートネットワークインターフェースのみにバインドし、ACL でサービスごとのキーアクセスを制限します

例 2：認証システムの攻撃ツリー

最終目標：ユーザーアカウントへの不正アクセスを獲得する。

Gain Unauthorized Access to User Account
├── 1. Steal Valid Credentials
│   ├── 1.1 Phishing attack targeting user email [Likelihood: High]
│   ├── 1.2 Credential stuffing from breached databases [Likelihood: High]
│   └── 1.3 Keylogger malware on user device [Likelihood: Medium]
├── 2. Bypass Authentication
│   ├── 2.1 Exploit password reset flow
│   │   ├── 2.1.1 Predictable reset token (insufficient entropy) [Likelihood: Medium]
│   │   └── 2.1.2 Reset link does not expire [Likelihood: Low]
│   ├── 2.2 Session hijacking
│   │   ├── 2.2.1 Steal session cookie via XSS [Likelihood: Medium]
│   │   └── 2.2.2 Session fixation attack [Likelihood: Low]
│   └── 2.3 Forge or tamper with JWT
│       ├── 2.3.1 Algorithm confusion attack (HS256 vs RS256) [Likelihood: Medium]
│       └── 2.3.2 Weak signing secret (brute-forceable) [Likelihood: Medium]
├── 3. Exploit Authorization Flaws
│   ├── 3.1 IDOR — access another user's resources by changing user ID in URL [Likelihood: High]
│   └── 3.2 Privilege escalation — modify role claim in JWT payload [Likelihood: Medium]
└── 4. Compromise the Auth Service Directly
    ├── 4.1 SQL injection in login endpoint [Likelihood: Medium]
    └── 4.2 Exploit unpatched dependency in auth service [Likelihood: Medium]

攻撃ツリーから導き出される緩和策：

攻撃経路	緩和策	優先度
1.2 クレデンシャルスタッフィング	IP ごとに、ログインを1分あたり5回までに制限します。HaveIBeenPwned API と連携し、MFA を必須にします	重大
2.1.1 予測可能なリセットトークン	256 ビットの暗号学的乱数を使用してトークンを生成し、15 分後に有効期限が切れるようにします	高
2.3.1 アルゴリズムの混同	JWT の検証で algorithms: ["RS256"] を明示的に設定し、alg: none または HS256 を含むトークンを拒否します	高
3.1 IDOR	すべてのリソースアクセスでサーバー側の所有権チェックを適用し、クライアントから渡されたユーザー ID を決して信用しません	高
4.1 SQL インジェクション	パラメーター化クエリを使用し、ログインエンドポイントで SQL インジェクションのパターンを検知する WAF ルールを適用します	高

ベストプラクティス

• 設計フェーズの早い段階で脅威モデルを作成する — コードを書く前に脅威を特定するほうが、本番環境で発見するよりもはるかに低コストです。設計レビューのプロセスに脅威モデリングを必須のチェック項目として含めてください。
• 脅威モデルを常に最新の状態に保つ — 一度作成したきり更新されない脅威モデルは、誤った安心感を生むため、役に立たないどころか有害です。主要なアーキテクチャ変更や新機能の追加のたびに、見直して更新してください。
• 部門横断で関係者を巻き込む — 開発者はコードを、運用担当者はデプロイを、プロダクト担当者はビジネスへの影響を理解しています。効果的な脅威モデリングには、これら3つの視点すべてからの意見が必要です。
• 信頼境界に注目する — 悪用されやすい脆弱性は、ユーザーとアプリケーションの間、サービス間、アプリケーションとデータベースの間など、データが信頼境界を越える場所で発生します。こうした接点における脅威を優先してください。
• 脅威モデリングをバックログ項目につなげる — 特定した緩和策はすべて、担当者と期限を設定した追跡可能な作業項目にしてください。実行可能なバックログ項目につながらない脅威モデルは、役割を果たしていません。
• テストで脅威への対処を検証する — 脅威を特定したら、それに対応するセキュリティテスト（侵入テスト、統合テスト、またはDASTルール）を作成し、緩和策が有効であることを確認してください。

安全上の境界

• ユーザーが所有するシステム、または評価を明示的に許可されたシステムのみを対象とし、テスト前に承認済みの範囲を記録してください。
• 受動的、または読み取り専用の調査から始めてください。アクティブスキャン、エクスプロイト、負荷生成、またはサービスに影響を与える修復を行う前に、明示的な承認を得てください。
• シークレットを漏えいさせたり、無関係なデータを抽出したり、本番環境の制御を弱めたり、承認済みの対象範囲を超えたりしないでください。
• 証拠を保全し、影響を最小限に抑え、不安定な状態が発生したら停止してください。また、重要な変更ごとにロールバックまたは封じ込めの手順を用意してください。

エッジケース

• データベースを共有するマイクロサービス — 複数のサービスが同じデータベースに対して読み書きを行うと、信頼境界が曖昧になります。あるサービスの脆弱性によって、別のサービスに「属する」データが侵害される可能性があります。各サービスのデータベースアクセスを個別の信頼境界としてモデル化し、スキーマレベルで分離してください。
• サードパーティ API との連携 — 外部 API（決済処理業者、ID プロバイダー、分析サービス）は、制御できない脅威をもたらします。この連携を信頼できないデータソースとしてモデル化し、すべてのレスポンスを検証するとともに、API の停止やデータ整合性の破損に備えてください。
• イベント駆動型アーキテクチャ — メッセージキューやイベントバスを使うシステムでは、メッセージの挿入、リプレイ攻撃、順序どおりに処理されない事象などが脅威になります。メッセージブローカーを独自の信頼境界を持つコンポーネントとしてモデル化し、メッセージ認証と冪等な処理を確保してください。
• マルチテナント SaaS プラットフォーム — マルチテナント特有の脅威には、テナント間のデータ漏えい、ノイジーネイバーによるサービス拒否、テナントのなりすましなどがあります。ネットワーク、アプリケーション、データの各レイヤーで、テナント分離を個別にモデル化してください。
• 頻繁なデプロイを伴う急速に変化するシステム — アーキテクチャが毎週変化する場合、四半期ごとの脅威モデルレビューでは不十分です。信頼境界を変更する変更、新たなデータフローを追加する変更、または新たな外部連携を導入する変更については、軽量な脅威評価をPRレビューのプロセスに組み込んでください。