脅威のモデリングを理解する

完了

脅威モデリングは、Microsoft セキュリティ開発ライフサイクル (SDL) の中核となる要素であり、セキュリティで保護されたアプリケーションを構築するための基本的なセキュリティプラクティスです。 これは、アプリケーションに影響を与える可能性がある脅威、攻撃、脆弱性、および対策を体系的に特定するのに役立つエンジニアリング手法です。

脅威モデリングとは

目的: 脅威モデリングは、アプリケーションのセキュリティ リスクを理解するための構造化されたアプローチを提供します。 脅威モデリングでは、考えられるすべてのセキュリティの問題を考えるのではなく、体系的なプロセスを通じて脅威を特定し、対処します。

利点: 脅威モデリングを使用して、次のことができます。

  • シェイプ アプリケーションの設計: セキュリティを後から考慮するのではなく、セキュリティに関する考慮事項に基づいてアーキテクチャの決定に影響を与えます。
  • セキュリティ目標を達成する: アプリケーションが組織のセキュリティ目標とコンプライアンス要件を満たしていることを確認します。
  • リスクを軽減する: 運用環境で脅威を検出するのではなく、設計時に脅威を特定して対処することで、セキュリティ リスクを体系的に軽減します。
  • セキュリティ作業に優先順位を付けます。 一度にすべてに対処するのではなく、最も重大な脅威にセキュリティの取り組みを集中します。
  • セキュリティに関する懸念事項を伝える: 開発者、セキュリティ チーム、関係者がセキュリティについて話し合う共通言語を提供します。

アクセシビリティ: このアプローチは、セキュリティ以外の専門家を念頭に置いて設計されています。 脅威モデリングは、脅威モデルの作成と分析に関する明確なガイダンスを通じて、セキュリティ スペシャリストだけでなく、すべての開発者がアクセスできます。

5 段階の脅威モデリング プロセス

脅威モデリングは、体系的な 5 段階のプロセスに従います。

5 つの脅威モデリング 段階を示す図: セキュリティ要件の定義、アプリケーション アーキテクチャの図、脅威の特定、脅威の軽減、軽減策の検証。

1. セキュリティ要件を定義する

セキュリティ目標を確立する: 脅威を分析する前に、アプリケーションのセキュリティの意味を明確にしてください。

機密性の要件:

  • 機密を保持する必要があるデータは何ですか?
  • 機密情報にアクセスできるのは誰ですか?
  • データを機密のままにしておく必要がある期間はどのくらいですか?
  • 機密保持違反の結果は何ですか?

整合性の要件:

  • 不正な変更から保護する必要があるデータや操作は何ですか?
  • データが改ざんされたかどうかを検出するにはどうすればよいですか?
  • 整合性違反の結果は何ですか?

可用性の要件:

  • どのようなアップタイム保証が必要ですか?
  • さまざまなコンポーネントで許容されるダウンタイムは何ですか?
  • 利用できないというビジネスへの影響は何ですか?

コンプライアンス要件:

  • どのような規制要件が適用されますか (GDPR、HIPAA、PCI DSS など)。
  • どの業界標準 (ISO 27001、SOC 2 など) を満たす必要がありますか?
  • 顧客にはどのような契約上のセキュリティ義務がありますか?

要件の例: 「顧客の支払い情報は機密のままにする必要があります。 このデータにアクセスできるのは、承認された支払処理システムだけです。 すべてのアクセスは、監査目的でログに記録する必要があります。 データは転送中と保存時に暗号化する必要があります。

2. アプリケーション ダイアグラムを作成する

アーキテクチャを視覚化します。 次を示す、アプリケーションのアーキテクチャを表す図を作成します。

システム コンポーネント:

  • Web サーバー、アプリケーション サーバー、データベース、マイクロサービス。
  • アプリケーションが依存する外部サービスと API。
  • 認証システムと承認システム。
  • ロード バランサー、キャッシュ レイヤー、メッセージ キュー。

データ フロー:

  • コンポーネント間でのデータの移動方法。
  • 各接続が送信するデータ。
  • データ フローの方向。
  • データ変換ポイント。

セキュリティ境界:

  • 特権レベルが変更される信頼境界。
  • 異なるセキュリティ ゾーン間のネットワーク境界。
  • 異なる実行コンテキスト間のプロセス境界。
  • 異なる場所またはクラウド間の物理的な境界。

要素の例:

  • インターネット経由で接続しているユーザー。
  • ネットワーク エッジの Web アプリケーション ファイアウォール。
  • DMZ 内の Web サーバー。
  • 保護されたネットワーク内のアプリケーション サーバー。
  • 制限の厳しいネットワーク内のデータベース サーバー。
  • トランザクションを処理するための外部支払ゲートウェイ。

3. 脅威を特定する

体系的な脅威の識別: 構造化されたアプローチを使用して、潜在的な脅威を特定します。

STRIDE 手法: STRIDE は、脅威の分類フレームワークです。

  • Spoofing: アイデンティティの偽装に関連する脅威。
  • ざん: データの不正な変更を伴う脅威。
  • Repudiation: ユーザーがアクションの実行を拒否する脅威。
  • 情報漏えい: 不正な情報アクセスに関する脅威。
  • サービス拒否:正当なユーザーがシステムにアクセスするのを妨げる脅威。
  • 権限昇格:ユーザーが無許可の権限を取得する脅威。

データ フローに STRIDE を適用します。 ダイアグラム内の各データ フローを調べて、各 STRIDE カテゴリがどのように適用されるかを検討します。

  • 攻撃者はこのデータのソースを偽装できますか?
  • 転送中または保存中にこのデータを改ざんすることはできますか?
  • このデータ フローに対する正当なアクションを否認できますか?
  • このフローを通じて機密情報を開示できますか?
  • このフローを使用してサービス拒否を引き起こすことができるか。
  • このフローは昇格された特権を得るために悪用される可能性がありますか?

一般的な脅威の例:

  • SQL インジェクション: 攻撃者は、不正なユーザー入力 (改ざん、情報漏えい、特権の昇格) を介してデータベース クエリを操作します。
  • セッション ハイジャック: 攻撃者はセッション トークンを盗んでユーザーを偽装します (スプーフィング、特権の昇格)。
  • Man-in-the-middle: 攻撃者はコンポーネント間の通信を傍受します (情報漏えい、改ざん)。
  • DDoS 攻撃: 攻撃者は、トラフィック (サービス拒否) でシステムを圧倒します。

4. 脅威を軽減する

対策を開発する: 特定された脅威ごとに、適切な軽減策を開発します。

軽減策:

  • 鉏: 重要でない場合は、脆弱なコンポーネントまたは機能を完全に削除します。
  • 防ぐ: 脅威を不可能にするコントロールを実装します (たとえば、入力検証によってインジェクション攻撃が防止されます)。
  • 見付ける: 脅威の悪用の試行を検出するための監視とアラートを実装します。
  • 応じる: 脅威が悪用された場合のインシデント対応手順を開発します。

軽減策の例:

  • SQL インジェクションの脅威: パラメーター化されたクエリと入力検証を使用して、インジェクション攻撃を防ぎます。
  • セッションハイジャックの脅威: HTTPS、セキュリティで保護された Cookie、短いセッション タイムアウトを使用して、セキュリティで保護されたセッション管理を実装します。
  • 中間者の脅威: すべての通信に TLS を適用し、証明書のピン留めを実装します。
  • DDoS の脅威: クラウドベースの DDoS 保護サービスを使用し、レート制限を実装します。

ドキュメントの決定: 次のような軽減策の決定を記録します。

  • どの脅威が対処されていますか。
  • どの軽減アプローチが選択されたか。
  • このアプローチが適切な理由。
  • 実装を担当するのは誰ですか。
  • 残っている残りのリスク。

5. 軽減策を検証する

有効性を確認します。 軽減策を実装した後、特定された脅威に効果的に対処していることを検証します。

セキュリティ テスト:

  • 脅威を検証するための侵入テストは利用できません。
  • 軽減策が適切に実装されていることを確認するためのセキュリティ コード レビュー。
  • セキュリティ スキャンを自動化して、見落とされた脆弱性を検出します。
  • 赤いチームの演習では、現実的な攻撃シナリオに対する防御をテストします。

継続的な検証: 脅威と軽減策の進化:

  • テクノロジの変化に合った新しい脅威が発生します。
  • 既存の軽減策が無効になる可能性があります。
  • アプリケーションの変更により、新しい脆弱性が発生する可能性があります。

開発ライフサイクルにおける脅威モデリング

進行中のプロセス: 脅威モデリングを 1 回限りアクティビティにすることはできません。 これは、一般的な開発ライフサイクルの一部である必要があります。

初期設計: 初期アプリケーション設計時に包括的な脅威モデリングを実施し、アーキテクチャの決定に影響を与えます。

機能開発: セキュリティ境界を変更したり、新しいデータ フローを導入したりする重要な新機能を追加する場合は、脅威モデリングを実行します。

定期的な更新プログラム: 脅威の状況が変化するにつれて、大きな変更がなくても脅威モデルを定期的に確認および更新します。

インシデント対応: セキュリティ インシデントの後に脅威モデルを更新して、学習した教訓を組み込みます。

段階的なリスク削減: この反復的なアプローチを使用すると、すべてのリスクに一度に対処するのではなく、脅威モデルを調整し、時間の経過と同時にリスクを徐々に軽減できます。

Microsoft Threat Modeling Tool

Microsoft は、脅威モデリングをよりアクセシビリティと構造化にするための無料のツールを提供しています。

目的: Microsoft Threat Modeling Tool を使用すると、システム コンポーネント、データ フロー、およびセキュリティ境界を視覚化するための標準表記を使用して、すべての開発者にとって脅威モデリングが簡単になります。

脅威の自動識別: このツールは、脅威モデリング担当者が、ソフトウェア設計の構造に基づいて考慮する必要がある脅威のクラスを特定するのに役立ちます。 アプリケーション ダイアグラムを作成すると、定義したコンポーネントとデータ フローに基づいて、潜在的な脅威が自動的に提案されます。

主な機能: Threat Modeling Tool を使用すると、開発者またはソフトウェア アーキテクトは次のことが可能になります。

セキュリティ設計を伝える:

  • システム アーキテクチャの視覚的表現を作成します。
  • セキュリティ チームと開発者が理解する一貫した表記を使用します。
  • セキュリティ関連のアーキテクチャの決定を文書化します。
  • レビューとフィードバックのために、脅威モデルを利害関係者と共有します。

設計を分析する:

  • 実証済みの手法 (STRIDE) を使用して潜在的なセキュリティの問題を特定します。
  • アプリケーション構造に基づいて脅威リストを自動的に生成します。
  • 重大度と可能性に基づいて脅威に優先順位を付けます。
  • セキュリティの観点から異なる設計の代替手段を比較します。

軽減策の管理:

  • 特定された脅威の軽減策を提案します。
  • 軽減策の実装状態を追跡します。
  • セキュリティに関する決定事項と根拠を文書化します。
  • セキュリティ レビューとコンプライアンスに関するレポートを生成します。

作業の開始:

  • このツールは無料で、Microsoft からダウンロードできます。
  • これには、一般的なアプリケーションの種類のテンプレートが含まれています。
  • 組み込みのガイダンスは、新しいユーザーが脅威モデリングの概念を学習するのに役立ちます。
  • Azure DevOps との統合により、脅威を作業項目にリンクできます。

その他のリソース

脅威モデリングの詳細については、以下を参照してください。