脅威分析に関する推奨事項

この Azure Well-Architected Framework のセキュリティ チェックリストの推奨事項に適用されます。

関連ガイド: 開発ライフサイクルをセキュリティで保護するための推奨事項

ワークロードの設計フェーズでは、脅威、攻撃、脆弱性、対策を特定するための包括的な分析が重要です。 脅威モデリング は、セキュリティ要件の定義、脅威の特定と軽減、それらの軽減策の検証を含むエンジニアリング演習です。 この手法は、アプリケーション開発または運用のどの段階でも使用できますが、新機能の設計段階で最も効果的です。

このガイドでは、セキュリティギャップをすばやく特定し、セキュリティ防御を設計できるように、脅威モデリングを行うための推奨事項について説明します。

定義 

主要な設計戦略

脅威モデリングは、組織が SDLC に統合する必要がある重要なプロセスです。 脅威モデリングは、開発者のタスクではありません。 これは、次の間の共同責任です。

• システムの技術的な側面を担当するワークロード チーム。
• ビジネスの成果を理解し、セキュリティに既得権を持つビジネス利害関係者。

重要なワークロードのビジネス要件に関しては、組織のリーダーと技術チームの間でしばしば齟齬が発生します。 この切断は、特にセキュリティ投資に対して、望ましくない結果につながる可能性があります。

ワークロード チームが脅威モデリング演習を行うときは、ビジネス要件と技術要件の両方を考慮する必要があります。 ワークロード チームとビジネス利害関係者は、対策に十分な投資を行うことができるように、ワークロードのセキュリティ固有のニーズに同意する必要があります。

セキュリティ要件は、脅威モデリングのプロセス全体のガイドとして機能します。 効果的な演習を行うには、ワークロード チームはセキュリティの考え方を持ち、脅威モデリング ツールでトレーニングを受ける必要があります。

演習の範囲を理解する

スコープを明確に理解することは、効果的な脅威モデリングに不可欠です。 これは、最も重要な領域に取り組みとリソースを集中するのに役立ちます。 この戦略では、システムの境界を定義し、保護する必要がある資産のインベントリを取得し、セキュリティ制御に必要な投資のレベルを理解する必要があります。

各コンポーネントに関する情報を収集する

ワークロード アーキテクチャ図は、システムの視覚的な表現を提供するため、情報を収集するための開始点です。 この図では、システムの技術的なディメンションが強調表示されています。 たとえば、ユーザー フロー、ネットワーク内でのデータの移動方法、データの秘密度レベルと情報の種類、ID アクセス パスなどが表示されます。

この詳細な分析は、多くの場合、設計の潜在的な脆弱性に関する分析情報を提供できます。 各コンポーネントとその依存関係の機能を理解することが重要です。

潜在的な脅威を評価する

外部の観点から各コンポーネントを分析します。 たとえば、攻撃者が機密データに簡単にアクセスできるでしょうか。 攻撃者が環境にアクセスできる場合、攻撃者は横方向に移動し、潜在的に他のリソースにアクセスしたり、他のリソースを操作したりすることはできますか? これらの質問は、攻撃者がワークロード資産を悪用する方法を理解するのに役立ちます。

業界の方法論を使用して脅威を分類する

脅威 を分類する方法の 1 つは、Microsoft セキュリティ開発ライフサイクルで使用される STRIDE です。 脅威の分類は、各脅威の性質を理解し、適切なセキュリティ制御を使用するのに役立ちます。

脅威を軽減する

特定されたすべての脅威を文書化します。 脅威ごとに、セキュリティ コントロールと、それらのコントロールが失敗した場合の攻撃への対応を定義します。 ワークロードで特定された脆弱性への露出を最小限に抑えるプロセスとタイムラインを定義して、それらの脆弱性を解決できないようにします。

侵害想定アプローチを使用します。 これは、主要なセキュリティ コントロールが失敗した場合にリスクを軽減するために設計に必要なコントロールを特定するのに役立ちます。 主要な制御が失敗する可能性を評価します。 失敗した場合、潜在的な組織リスクの程度は何ですか? また、補正制御の効果は何ですか? 評価に基づいて、多層防御対策を適用して、セキュリティコントロールの潜在的な障害に対処します。

次に例を示します。

脅威モデリングの結果を追跡する

脅威モデリング ツールを使用することを強くお勧めします。 ツールを使用すると、脅威を特定するプロセスを自動化し、特定されたすべての脅威の包括的なレポートを生成できます。 必ず、関心のあるすべてのチームに結果を伝えます。

ワークロード チームのバックログの一部として結果を追跡し、タイムリーに説明責任を果たすことができます。 脅威モデリングによって特定された特定のリスクの軽減を担当する個人にタスクを割り当てます。

ソリューションに新しい機能を追加したら、脅威モデルを更新し、コード管理プロセスに統合します。 セキュリティの問題が見つかる場合は、重大度に基づいて問題をトリアージするプロセスがあることを確認します。 このプロセスは、問題を修復するタイミングと方法を決定するのに役立ちます (たとえば、次のリリース サイクルやより高速なリリース)。

ビジネスクリティカルなワークロード要件を定期的に確認する

エグゼクティブ スポンサーと定期的に会い、要件を定義します。 これらのレビューは、期待を整合させ、イニシアチブへの運用リソースの割り当てを確保する機会を提供します。

Azure ファシリテーション

Microsoft セキュリティ開発ライフサイクルには、脅威モデリング プロセスを支援する脅威モデリング ツールが用意されています。 このツールは、追加料金なしで利用できます。 詳細については、「脅威モデリング」 ページを参照してください。

例

この例は、セキュリティ ベースライン (SE:01) で確立された情報技術 (IT) 環境に基づいています。 このアプローチでは、さまざまな IT シナリオにおける脅威の状況を幅広く理解できます。

1. 開発ライフサイクル ペルソナ。 開発ライフサイクルには、開発者、テスト担当者、最終ユーザー、管理者など、多くのペルソナが関与しています。 これらのすべてが侵害され、意図的に作成された脆弱性や脅威によって環境が危険にさらされる可能性があります。

2. 潜在的な攻撃者。 攻撃者は、脆弱性を調査して攻撃を開始するために、いつでも簡単に使用できる幅広いツールを検討しています。

3. セキュリティ コントロール。 脅威分析の一環として、ソリューションの保護に使用する Azure セキュリティ サービスと、それらのソリューションの効果を特定します。

4. ログ収集。 Azure リソースと一部のオンプレミス コンポーネントからのログが Azure Log Analytics に送信される可能性があるため、開発されたソリューションの動作を理解し、初期の脆弱性をキャプチャしようとする可能性があります。

5. セキュリティ情報イベント管理 (SIEM) ソリューション。 Microsoft Sentinel は、ソリューションの初期段階でも追加される可能性があるため、いくつかの分析クエリを作成して脅威や脆弱性を軽減し、運用環境のセキュリティ環境を予測できます。

6. Microsoft Defender for Cloud では、セキュリティ体制を改善するために、いくつかのセキュリティに関する推奨事項が作成される場合があります。

関連リンク

• STRIDE
• 脅威モデリング

コミュニティ リンク

Open Web Application Security Project (OWASP) によって、アプリケーション向けの脅威モデリング アプローチが文書化されています。

セキュリティ チェックリスト

レコメンデーションの完全なセットを参照してください。