セキュリティ オペレーション センター (SOC) の Microsoft Defender XDR について理解する
次の図は、現代のセキュリティ オペレーション センター (SOC) で Microsoft Defender XDR と Microsoft Sentinel がどのように統合されるかの概要を示しています。
セキュリティ運用モデル - 機能とツール
個人とチームへの責任の割り当ては、組織の規模や他の要因によって異なりますが、セキュリティ オペレーションはいくつかの異なる機能で構成されます。 各機能やチームには主たる対象領域があり、効果的に活動するには、他の機能や外部チームと緊密に協力する必要があります。 この図では、完全なスタッフを擁するチームによる完全なモデルが示されています。 小規模な組織では、これらの機能は、多くの場合、1 つの役割またはチームに組み合わされたり、IT オペレーションによって実行されたり (技術的な役割の場合)、リーダーや代理によって一時的な機能として実行されたりします (インシデント管理の場合)
Note
アナリストは、階層の番号ではなく、主にチーム名で呼ばれます。これらのチームはそれぞれ固有の特殊なスキルを持ち、文字どおりの価値のランク付けや階層ではありません。
トリアージと自動化
最初に、事後対応型アラートを処理します。これは、次から始まります。
自動化 – 自動化を使用した既知のインシデントの種類の凖リアルタイムの解決。 これらは、組織が何度も見てきた明確に定義された攻撃です。
トリアージ (階層 1 とも呼ばれます) – トリアージ アナリストは、まだ人間の (速やかな) 判断を必要とする大量の既知の種類のインシデントの迅速な修復に焦点を当てています。 多くの場合、これらでは、自動化された修復ワークフローを承認し、エスカレーションや調査 (階層 2) チームとの協議の正当な理由となる異常または興味深いものを特定する作業を行います。
トリアージとオートメーションに関する重要なポイント:
- 90% 真陽性 - アナリストが大量の誤ったアラームに対応する必要がないように、アナリストが対応する必要があるアラート フィードの品質基準を 90% 真陽性に設定することをお勧めします。
- アラート率 – Microsoft のサイバー防御オペレーション センターの経験では、高品質のアラートの大部分は XDR アラートによって生成され、残りは、ユーザーが報告した問題、従来のログ クエリ ベースのアラート、その他のソースから発生します
- 自動化は、これらのアナリストを支援し、手作業の負担を軽減するのに役立つ、トリアージ チームの重要な成功要因です (たとえば、自動調査を提供し、このインシデント用に自動的に構築された修復シーケンスを承認する前に、人間によるレビューを求めます)。
- ツール統合 - Microsoft の CDOC での修復にかかる時間を短縮した最も強力な時間節約テクノロジの 1 つが、アナリストがエンドポイント、メール、ID などに対する単一のコンソールを持てるようにするための XDR ツールの Microsoft Defender XDR への統合です。 この統合により、アナリストは、大きな損害を被る前に、攻撃者のフィッシング メール、マルウェア、侵害されたアカウントを迅速に検出してクリーンアップできます。
- フォーカス - これらのチームは、すべての種類のテクノロジとシナリオを常に短時間で解決することはできないため、いくつかの技術分野やシナリオに焦点を絞ります。 ほとんどの場合、これは、メール、エンドポイント AV アラート (調査を開始する EDR に対し)、ユーザーの報告への最初の対応など、ユーザーの生産性に関する問題です。
調査とインシデント管理 (階層 2)
このチームは、トリアージ (階層 1) からの問題のエスカレーション ポイントとして機能し、より高度な攻撃者を示すアラートを直接監視します。 具体的には、行動アラートをトリガーするアラート、ビジネス クリティカルな資産に関連する特殊ケース アラート、進行中の攻撃キャンペーンの監視です。 また、このチームは、トリアージ チームのアラート キューを定期的に確認し、空き時間に XDR ツールを使用して事前対応的に追求することもできます。
このチームは、数は少なくてもいっそう複雑な攻撃 (多くの場合、人間の攻撃オペレーターによって行われる多段階攻撃) のさらに詳細な調査を行います。 このチームは、新しい、または馴染みのないアラートの種類のパイロットを実施して、トリアージ チームと自動化のためのプロセスを文書化します。これには、多くの場合、クラウドでホストされているアプリ、VM、コンテナーと Kubernetes、SQL データベースなどで Microsoft Defender for Cloud によって生成されたアラートが含まれます。
インシデント管理 – このチームは、コミュニケーション、法務、リーダーシップ、その他のビジネス利害関係者などの他のチームとの調整を含む、インシデントを管理する技術的でない側面を引き受けます。
追求とインシデント管理 (階層 3)
これは、事後対応の検出をすり抜けた可能性がある攻撃者を特定し、ビジネスに影響を与える主要なイベントを処理することに重点を置いた、複数の分野にわたるチームです。
- 追求 – このチームは、検出されていない脅威を事前に検出し、エスカレーションと高度なフォレンジックによる事後対応調査を支援し、アラートと自動化を調整します。 これらのチームは、事後対応型のアラート モデルよりも仮説主導のモデルで活動し、そこではレッド/パープル チームもセキュリティ運用と結び付きます。
すべてをまとめる方法
このしくみを知るために、一般的なインシデント ライフサイクルに従ってみましょう
- トリアージ (レベル 1) アナリストは、キューからのマルウェア アラートを要求し、(たとえば、Microsoft Defender XDR コンソールを使用して) 調査を行います
- ほとんどのトリアージ ケースは迅速に修復されて閉じられますが、この場合のアナリストは、マルウェアがより複雑で高度な修復 (デバイスの分離やクリーンアップなど) を必要とする可能性があることに気付きます。 トリアージは、調査を主導する調査アナリスト (階層 2) にケースをエスカレートします。 トリアージ チームは、必要に応じて、関与を続け、詳細情報を確認することができます (調査チームは、より広範なコンテキストのために Microsoft Sentinel または別の SIEM を使用する可能性があります)
- 調査では、調査の結論を検証 (または詳細に調査) し、修復を進め、ケースを終了します。
- その後、追求 (階層 3) で、終了したインシデントを確認し、掘り下げる価値のある共通点や異常を探すときに、このケースに気付く場合があります。
- 自動修復の対象となる可能性がある検出
- 一般的な根本原因を持つ可能性がある複数の類似インシデント
- 他の潜在的なプロセス、ツール、アラートの改善 たとえば、階層 3 がケースを確認し、ユーザーが技術詐欺に陥ったことを発見しました。 その後、詐欺師がエンドポイントで管理者レベルのアクセスを取得したため、この検出には優先度が高い可能性のあるアラートとしてフラグが設定されました。 リスクにさらされるリスクが高くなります。
脅威インテリジェンス
脅威インテリジェンス チームは、(大規模な組織で脅威インテリジェンス プラットフォーム (TIP) を使用して) 他のすべての機能をサポートするためのコンテキストと分析情報を提供します。 これには、次のようなさまざまな面が含まれる可能性があります
- アクティブなインシデントに対する事後技術調査
- 攻撃者グループ、攻撃の傾向、注目度の高い攻撃、新たな手法などに関する事前技術調査。
- ビジネスおよび技術的なプロセスと優先順位を知らせるための戦略的分析、調査、分析情報。
- その他