セキュリティ インシデント対応に関する推奨事項

  • [アーティクル]

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

SE:12 ローカライズされた問題からディザスター リカバリーまで、さまざまなインシデントをカバーする効果的なインシデント対応手順を定義してテストします。 プロシージャを実行するチームまたは個人を明確に定義します。

このガイドでは、ワークロードのセキュリティ インシデント対応を実装するための推奨事項について説明します。 システムにセキュリティ侵害がある場合、体系的なインシデント対応アプローチは、セキュリティ インシデントの特定、管理、軽減にかかる時間を短縮するのに役立ちます。 これらのインシデントは、ソフトウェア システムとデータの機密性、整合性、可用性を脅かす可能性があります。

ほとんどの企業には、中央のセキュリティ運用チーム (Security Operations Center (SOC) または SecOps とも呼ばれます) があります。 セキュリティ運用チームの責任は、潜在的な攻撃を迅速に検出し、優先順位を付け、トリアージすることです。 また、セキュリティ関連のテレメトリ データを監視し、セキュリティ侵害を調査します。

潜在的なリスクを軽減するコラボレーション アプローチを示す概念図。

ただし、ワークロードを保護する責任もあります。 コミュニケーション、調査、ハンティングのアクティビティは、ワークロード チームと SecOps チーム間の共同作業である必要があります。

このガイドでは、攻撃の迅速な検出、トリアージ、調査に役立つ推奨事項を自分とワークロード チームに提供します。

定義

期間 定義
アラート: インシデントに関する情報を含む通知。
アラートの忠実性 アラートを決定するデータの精度。 忠実度の高いアラートには、直ちにアクションを実行するために必要なセキュリティ コンテキストが含まれています。 忠実度の低いアラートには情報が不足しているか、ノイズが含まれています。
偽陽性 発生しなかったインシデントを示すアラート。
インシデント システムへの未承認のアクセスを示すイベント。
インシデント対応 インシデントに関連するリスクを検出、対応、軽減するプロセス。
トリアージ セキュリティの問題を分析し、軽減策に優先順位を付けるインシデント対応操作。

主要な設計戦略

お客様とチームは、侵害の可能性に関するシグナルまたはアラートがある場合に、インシデント対応操作を実行します。 忠実度の高いアラートには、アナリストが意思決定を容易にする十分なセキュリティ コンテキストが含まれています。 忠実度の高いアラートでは、誤検知の数が少なくなります。 このガイドでは、アラート システムが忠実度の低い信号をフィルター処理し、実際のインシデントを示す可能性がある忠実度の高いアラートに焦点を当てていることを前提としています。

インシデント通知を割り当てる

セキュリティ アラートは、チームとorganizationの適切なユーザーに連絡する必要があります。 インシデント通知を受け取るために、ワークロード チームに指定された連絡先を確立します。 これらの通知には、侵害されたリソースとシステムに関するできるだけ多くの情報が含まれている必要があります。 チームがアクションを迅速化できるように、アラートには次の手順を含める必要があります。

監査証跡を保持する特殊なツールを使用して、インシデント通知とアクションをログに記録して管理することをお勧めします。 標準ツールを使用すると、潜在的な法的調査に必要な証拠を保持できます。 責任を負う関係者の責任に基づいて通知を送信できる自動化を実装する機会を探します。 インシデント発生時に、コミュニケーションとレポートの明確なチェーンを維持します。

セキュリティ情報イベント管理 (SIEM) ソリューションと、organizationが提供するセキュリティ オーケストレーション自動応答 (SOAR) ソリューションを活用します。 または、インシデント管理ツールを調達し、すべてのワークロード チームに対してそれらを標準化するようにorganizationを促すことができます。

トリアージ チームで調査する

インシデント通知を受け取るチーム メンバーは、使用可能なデータに基づいて適切なユーザーを含むトリアージ プロセスを設定する責任があります。 ブリッジ チームと呼ばれるトリアージ チームは、コミュニケーションのモードとプロセスについて合意する必要があります。 このインシデントには、非同期のディスカッションまたはブリッジ呼び出しが必要ですか? チームは調査の進捗状況をどのように追跡し、伝える必要がありますか? チームはどこでインシデント資産にアクセスできますか?

インシデント対応は、システムのアーキテクチャ レイアウト、コンポーネント レベルの情報、プライバシーまたはセキュリティの分類、所有者、重要な連絡先など、ドキュメントを最新の状態に保つための重要な理由です。 情報が不正確または古い場合、ブリッジ チームは、システムのしくみ、各領域の責任者、およびイベントの影響を理解しようとする貴重な時間を無駄にします。

さらに調査を行うには、適切な担当者を関与させる必要があります。 インシデント マネージャー、セキュリティ責任者、またはワークロード中心のリードを含めることができます。 トリアージに焦点を当て続けるために、問題の範囲外のユーザーを除外します。 個別のチームがインシデントを調査する場合があります。 最初に問題を調査し、インシデントの軽減を試みるチームと、広範な問題を確認するための詳細な調査のためにフォレンジックを実行する別の専門チームが存在する可能性があります。 ワークロード環境を検疫して、フォレンジック チームが調査を行えるようにすることができます。 場合によっては、同じチームが調査全体を処理する場合があります。

最初のフェーズでは、トリアージ チームは、システムの機密性、整合性、可用性 ( CIA とも呼ばれます) に対する潜在的なベクトルとその影響を決定する責任があります。

CIA のカテゴリ内で、損傷の深さと修復の緊急性を示す初期重大度レベルを割り当てます。 トリアージのレベルで詳細な情報が検出されるため、このレベルは時間の経過と同時に変化することが予想されます。

検出フェーズでは、アクションとコミュニケーション計画の即時のコースを決定することが重要です。 システムの実行状態に変更はありますか? 攻撃を封じ込めて、さらなる悪用を阻止するにはどうすればよいですか? チームは、責任ある開示など、内部または外部の通信を送信する必要がありますか? 検出と応答時間を検討してください。 一部の種類の違反は、特定の期間内 (多くの場合、数時間または数日) 内に規制当局に報告する法的義務を負う場合があります。

システムをシャットダウンする場合は、次の手順でワークロードのディザスター リカバリー (DR) プロセスが発生します。

システムをシャットダウンしない場合は、システムの機能に影響を与えずにインシデントを修復する方法を決定します。

インシデントから復旧する

セキュリティ インシデントを災害のように扱う。 修復に完全な復旧が必要な場合は、セキュリティの観点から適切な DR メカニズムを使用します。 回復プロセスでは、繰り返し発生する可能性を防ぐ必要があります。 それ以外の場合は、破損したバックアップからの復旧によって問題が再導入されます。 同じ脆弱性を持つシステムを再デプロイすると、同じインシデントが発生します。 フェールオーバーとフェールバックの手順とプロセスを検証します。

システムが引き続き機能している場合は、システムの実行中の部分に対する影響を評価します。 システムを監視し続けて、適切な劣化プロセスを実装することで、他の信頼性とパフォーマンスの目標が満たされているか、再調整されていることを確認します。 軽減策のためにプライバシーを侵害しないでください。

診断は、ベクトルと潜在的な修正とフォールバックが識別されるまでの対話型プロセスです。 診断後、チームは修復に取り組み、受け入れ可能な期間内に必要な修正プログラムを特定して適用します。

回復メトリックは、問題の修正にかかる時間を測定します。 シャットダウンが発生した場合、修復時間に関する緊急性がある可能性があります。 システムを安定させるためには、修正プログラム、修正プログラム、テストの適用、更新プログラムのデプロイに時間がかかります。 さらなる損害とインシデントの拡散を防ぐための封じ込め戦略を決定します。 環境から脅威を完全に削除するための根絶手順を開発します。

トレードオフ: 信頼性ターゲットと修復時間の間にはトレードオフがあります。 インシデントの間に、他の非機能または機能上の要件を満たしていない可能性があります。 たとえば、インシデントの調査中にシステムの一部を無効にする必要がある場合や、インシデントの範囲を特定するまでシステム全体をオフラインにする必要がある場合があります。 ビジネスの意思決定者は、インシデント中に許容されるターゲットを明示的に決定する必要があります。 その決定に対して責任を負う人物を明確に指定します。

インシデントから学習する

インシデントは、設計または実装のギャップまたは脆弱なポイントを明らかにします。 これは、技術的な設計の側面、自動化、テストを含む製品開発プロセス、インシデント対応プロセスの有効性に関する教訓によって推進される改善機会です。 実行されたアクション、タイムライン、結果など、詳細なインシデント レコードを維持します。

根本原因分析や振り返りなど、インシデント後の構造化されたレビューを実施することを強くお勧めします。 これらのレビューの結果を追跡して優先順位を付け、将来のワークロード設計で学習した内容を使用することを検討します。

改善計画には、ビジネス継続性とディザスター リカバリー (BCDR) 訓練などのセキュリティ訓練とテストの更新が含まれている必要があります。 BCDR ドリルを実行するシナリオとして、セキュリティ侵害を使用します。 ドリルでは、文書化されたプロセスがどのように機能するかを検証できます。 複数のインシデント対応プレイブックを作成しないでください。 インシデントのサイズと、効果の広さまたはローカライズに基づいて調整できる 1 つのソースを使用します。 ドリルは仮定の状況に基づいています。 リスクの低い環境で訓練を実施し、訓練に学習フェーズを含めます。

インシデント後のレビュー (事後分析) を実施して、対応プロセスの弱点と改善のための領域を特定します。 インシデントから学習した教訓に基づいて、インシデント対応計画 (IRP) とセキュリティコントロールを更新します。

必要な通信を送信する

中断をユーザーに通知し、修復と改善について内部の利害関係者に通知するための通信計画を実装します。 将来のインシデントを防ぐために、organization内の他のユーザーにワークロードのセキュリティ ベースラインに対する変更を通知する必要があります。

内部使用用のインシデント レポートを生成し、必要に応じて規制コンプライアンスまたは法的な目的で生成します。 また、SOC チームがすべてのインシデントに使用する標準書式レポート (セクションが定義されたドキュメント テンプレート) を採用します。 調査を終了する前に、すべてのインシデントにレポートが関連付けられていることを確認します。

Azure ファシリテーション

Microsoft Sentinel は SIEM および SOAR ソリューションです。 これは、アラートの検出、脅威の可視性、予防的なハンティング、脅威への対応のための単一ソリューションです。 詳細については、「Microsoft Sentinel とは」を参照してください。

セキュリティ操作が内部プロセスを介して直接通知されるように、Azure 登録ポータルに管理者の連絡先情報が含まれていることを確認します。 詳細については、「 通知設定を更新する」を参照してください。

Microsoft Defender for Cloud から Azure インシデント通知を受信する指定された連絡先の確立の詳細については、「セキュリティ アラートの電子メール通知を構成する」を参照してください。

組織の配置

クラウド導入フレームワーク for Azure では、インシデント対応の計画とセキュリティ運用に関するガイダンスが提供されます。 詳細については、「 セキュリティ操作」を参照してください。

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

推奨事項の完全なセットを参照してください。

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