手順 5. ユース ケースの開発とテスト

適用対象:

• Microsoft Defender XDR

Security Operations Center (SOC) にMicrosoft Defender XDRをデプロイするための推奨される方法は、SOC チームの現在のツール、プロセス、スキル セットのセットによって異なります。 プラットフォーム間でのサイバー衛生の維持は、数百のセキュリティ ソースではないにしても数十からの膨大なデータが存在するため、困難になる可能性があります。

セキュリティ ツールは相互に関連しています。 セキュリティ テクノロジで 1 つの機能をオンにしたり、プロセスを変更したりすると、別の機能が壊れる可能性があります。 このため、Microsoft では、SOC チームがユース ケースを定義して優先順位を付ける方法を正式化することをお勧めします。 ユース ケースは、さまざまなチーム間で SOC 操作の要件とテスト プロセスを定義するのに役立ちます。 適切なロールとタスクの組み合わせが適切なスキル セットで適切なチームに合わせられているかどうかを判断するためのメトリックをキャプチャするための手法が作成されます。

ユース ケース プロセスの開発と正式化

SOC は、SOC 監視チームによって規制されるユース ケースを開発するための高レベルの標準とプロセスを定義する必要があります。 SOC 監視チームは、ビジネス、IT、法務、人事などのグループと協力して、SOC チームの Runbook やプレイブックに最終的に移行する SOC のユース ケースに優先順位を付ける必要があります。 ユース ケースの優先順位は、コンプライアンスやプライバシーなどの目的に基づいています。

ユース ケース開発に関連する SOC 監視アクティビティには、次のものが含まれます。

• 要件
• スタッフ配置またはトレーニングのニーズ
• ソフトウェア ライセンス
• 仕入先契約
• プランの管理
• ユース ケース レジストリの維持
• テンプレートの保守/更新

Runbook とプレイブックの作成プロセスを容易にするには、ユース ケースデシジョン ツリーを作成します。 次の図は、例を示しています。

高度なユース ケース標準が定義され、承認されたら、次の手順では、実際のユース ケースを作成してテストします。 次のセクションでは、フィッシング対策と脅威と脆弱性スキャンのシナリオを例として使用します。

ユース ケースの例 1: 新しいフィッシングバリアント

ユース ケースを作成する最初の手順は、ストーリー ボードを使用してワークフローの概要を説明することです。 脅威インテリジェンス チームへの新しいフィッシング悪用通知の概要のストーリー ボードの例を次に示します。

ユース ケース ワークフローを呼び出す (例 1)

ストーリー ボードが承認されたら、次の手順としてユース ケース ワークフローを呼び出します。 フィッシング対策キャンペーンのプロセス例を次に示します。

ユース ケースの例 2: 脅威と脆弱性のスキャン

ユース ケースを使用できるもう 1 つのシナリオは、脅威と脆弱性のスキャンです。 この例では、SOC では、資産のスキャンを含む承認されたプロセスを介して、資産に対する脅威と脆弱性を修復する必要があります。

アセットのMicrosoft Defender 脆弱性の管理の概要ストーリーボードの例を次に示します。

ユース ケース ワークフローを呼び出す (例 2)

脅威と脆弱性のスキャンのプロセス例を次に示します。

ユース ケースの出力と学習したレッスンを分析する

ユース ケースが承認され、テストされた後、関係するユーザー、プロセス、Microsoft Defender XDR テクノロジと共に、セキュリティ チーム間のギャップを特定する必要があります。 Microsoft Defender XDRテクノロジを分析して、望ましい結果を達成できるかどうかを判断する必要があります。 これらは、チェックリストまたはマトリックスを使用して追跡できます。

たとえば、フィッシング対策シナリオの例では、SOC チームがこの表で検出を行っている可能性があります。

さらに、SOC チームは、上記で説明した Defender 脆弱性管理シナリオに関して、次の表に示す検出を行う可能性があります。

これらのユース ケースの例では、テストによって、各チームの責任のベースラインとして確立された SOC チームの要件にいくつかのギャップが明らかになっています。 ユース ケースのチェックリストは、SOC チームが新しいまたは既存の SOC 要件とのMicrosoft Defender XDR統合のために準備されるように、必要に応じて包括的にすることができます。 これは反復的なプロセスであるため、ユース ケース開発プロセスとユース ケースの出力コンテンツは、学習したレッスンを使用して SOC の Runbook を更新および成熟させるために自然に役立ちます。

運用 Runbook とプレイブックを更新する

すべてのギャップに対してユース ケース テストが修復されると、学習したレッスンとそれらの中で収集されたメトリックを、SOC チームの運用 Runbook (運用プロセス) とプレイブック (インシデント対応とエスカレーション手順) に組み込むことができます。

SOC チームの Runbook とプレイブックのメンテナンスは、さまざまな方法で整理できます。 各 SOC チームは、独自の責任を負うか、すべてのチームが中央リポジトリで共有するための 1 つの一元化されたバージョンがある場合があります。 個々の組織の Runbook とプレイブックの管理は、サイズ、スキル セット、ロール、職務の分離に基づいています。 Runbook が更新されたら、プレイブックの更新プロセスに従う必要があります。

エスカレーションに標準フレームワークを使用する

プレイブックは、ユース ケースの統合とテストの成功に基づいて、SOC チームが実際のイベントが発生したときに従う必要がある手順です。 したがって、SOC は、インシデント対応の主要な業界標準の 1 つとなっている NIST インシデント対応標準 など、インシデント対応に対する正式なアプローチに従うことが不可欠です。

NIST の 4 つのステップインシデント対応プロセスには、次の 4 つのフェーズが含まれています。

1. 準備
2. 検出と分析
3. コンテインメント、根絶、および回復
4. インシデント後のアクティビティ

例: 準備フェーズ アクティビティの追跡

エスカレーション プレイブックの主要な基盤の 1 つは、各 SOC チームがイベントまたはインシデントの前、実行中、および後に何を行う必要があるかについて、少しあいまいさを確保することです。 そのため、ステップ バイ ステップの手順を一覧表示することをお勧めします。

たとえば、準備フェーズには、if/then または XoR マトリックスのタスクを含めることができます。 新しいフィッシングバリアントのユース ケースの場合、このようなマトリックスは次のようになります。

準備フェーズを実行した後、組織は NIST で説明されているように残りのフェーズを呼び出す必要があります。

• 検出と分析
• コンテインメント、根絶、および回復
• インシデント後のアクティビティ

次の手順

手順 6. SOC メンテナンス タスクを特定する