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