手順 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 チーム | 要件 | 要件を満たすPeople | 要件を満たすプロセス | 関連テクノロジ | ギャップが特定されました | ユース ケース変更ログ | 除外 (Y/N) |
|---|---|---|---|---|---|---|---|
| 脅威インテリジェンスと分析チーム | データ ソースは、脅威インテリジェンス エンジンを適切に供給しています。 | 脅威インテリジェンス アナリスト/エンジニア | 確立されたデータ フィード要件、承認されたソースからの脅威インテリジェンス トリガー | Microsoft Defender for Identity、Microsoft Defender for Endpoint | 脅威インテリジェンス チームは、自動化スクリプトを使用して、Microsoft Defender XDR API と脅威 intel エンジンをリンクしませんでした | 脅威エンジンにデータ ソースとしてMicrosoft Defender XDRを追加する ユース ケース実行ブックを更新する |
N |
| 監視チーム | データ ソースが監視ダッシュボードに適切にフィードされている | 階層 1,2 SOC アナリスト - & アラートの監視 | セキュリティ & コンプライアンス センターのセキュリティ スコアを報告するためのワークフロー | Microsoft Defender XDRでアラートを調査する セキュリティ スコアの監視 |
SOC アナリストが、セキュリティ スコアを向上させるための新しいフィッシングバリアント検出の成功を報告するメカニズムはありません | レポート ワークフローにセキュリティ スコアの向上を追跡するためのプロセスを追加する | N |
| エンジニアリングと SecOps チーム | 変更コントロールの更新は、SOC チーム Runbook で行われます | 階層 2 SOC エンジニア | SOC チーム Runbook の制御通知手順を変更する | セキュリティ デバイスに対する承認された変更 | SOC セキュリティ テクノロジへのMicrosoft Defender XDR接続の変更には、承認が必要です | MICROSOFT DEFENDER FOR CLOUD APPS、Defender for Identity、Defender for Endpoint、Security & Compliance Center を SOC Runbook に追加する | Y |
さらに、SOC チームは、上記で説明した Defender 脆弱性管理シナリオに関して、次の表に示す検出を行う可能性があります。
| SOC チーム | 要件 | 要件を満たすPeople | 要件を満たすプロセス | 関連テクノロジ | ギャップが特定されました | ユース ケース変更ログ | 除外 (Y/N) |
|---|---|---|---|---|---|---|---|
| SOC の監視 | 承認済みネットワークに接続されているすべての資産が識別され、分類されます | SOC 監視、BU 所有者、アプリケーション所有者、IT 資産所有者など。 | リスクに基づいて資産カテゴリと属性を検出して一覧表示するための一元化された資産管理システム。 | ServiceNow またはその他の資産。 Microsoft 365 デバイス インベントリ |
検出された資産の 70% のみです。 既知の資産に対してのみ有効な修復追跡をMicrosoft Defender XDRする | Microsoft Defender XDRが 100% のカバレッジを確保するための成熟した資産ライフサイクル管理サービス | N |
| エンジニアリング & SecOps Teams | 資産の高い影響と重大な脆弱性は、ポリシーに従って修復されます | SecOps エンジニア、SOC アナリスト: 脆弱性 & コンプライアンス、セキュリティ エンジニアリング | 危険度の高い脆弱性と重大な脆弱性を分類するための定義されたプロセス | Microsoft Defender 脆弱性の管理 ダッシュボード | Defender for Endpoint では、修復計画や Microsoft 推奨アクティビティの実装がない、影響の大きいアラートの高いデバイスが特定されました | ポリシーごとに 30 日以内に修復アクティビティが必要な場合に資産所有者に通知するためのワークフローを追加します。資産所有者に修復手順を通知するチケット システムを実装します。 | N |
| Teams の監視 | 脅威と脆弱性の状態は、会社のイントラネット ポータルを介して報告されます | 階層 2 SOC アナリスト | 資産の修復の進行状況を示すMicrosoft Defender XDRからの自動生成されたレポート | Microsoft Defender XDRでアラートを調査する セキュリティ スコアの監視 |
資産の脅威と脆弱性の状態に関して資産所有者に伝達されるビューやダッシュボード レポートはありません。 | Create自動化スクリプトを使用して、リスクの高い状態と重要な資産の脆弱性の修復の状態をorganizationに設定します。 | N |
これらのユース ケースの例では、テストによって、各チームの責任のベースラインとして確立された 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 つは、各 SOC チームがイベントまたはインシデントの前、実行中、および後に何を行う必要があるかについて、少しあいまいさを確保することです。 そのため、ステップ バイ ステップの手順を一覧表示することをお勧めします。
たとえば、準備フェーズには、if/then または XoR マトリックスのタスクを含めることができます。 新しいフィッシングバリアントのユース ケースの場合、このようなマトリックスは次のようになります。
| エスカレーションが保証される理由 | 次のステップ |
|---|---|
| 重要なトリガー 500/時間として評価された > SOC 監視でのアラート | プレイブック A、セクション 2、アクティビティ 5 に移動します (プレイブック セクションへのリンク付き) |
| e コマースが DDoS 攻撃の可能性を報告しました | プレイブック B セクション C、アクティビティ 19 を呼び出す (プレイブック セクションへのリンク付き) |
| エグゼクティブは、スピア フィッシングの試みとして疑わしい電子メールを報告しました | プレイブック 5、セクション 2、アクティビティ 5 に移動します (プレイブック セクションへのリンク付き) |
準備フェーズを実行した後、組織は NIST で説明されているように残りのフェーズを呼び出す必要があります。
- 検出と分析
- コンテインメント、根絶、および回復
- インシデント後のアクティビティ
次の手順
ヒント
さらに多くの情報を得るには、 Tech Community: Microsoft Defender XDR Tech Community の Microsoft Security コミュニティとEngageします。