自動化ルールを使って Microsoft Sentinel の脅威への対応を自動化する
この記事では、Microsoft Sentinel 自動化ルールの概要と、それらを使用してセキュリティ オーケストレーション、自動化、および対応 (SOAR) の操作を実装する方法について説明します。 自動化ルールは SOC の効果を高め、時間とリソースを節約します。
重要
Microsoft Sentinel が、Microsoft Defender ポータルの Microsoft 統合セキュリティ オペレーション プラットフォーム内で一般提供されました。 詳細については、Microsoft Defender ポータルの Microsoft Sentinel に関する記事を参照してください。
自動化ルールとは
自動化ルールは、さまざまなシナリオに渡って適用できる小さなルール セットを定義して調整できるようにすることで、Microsoft Sentinel の自動化を一元的に管理する方法です。
自動化ルールは、次のカテゴリのユース ケースに適用されます。
インシデント処理の基本的な自動化タスクをプレイブックを使わずに実行します。 次に例を示します。
- アナリストがフォローするインシデント タスクを追加します。
- ノイズの多いインシデントを抑制します。
- 状態を [新規] から [アクティブ] に変更し、所有者を割り当てることで、新しいインシデントをトリアージします。
- インシデントにタグ付けして分類します。
- 新しい所有者を割り当ててインシデントをエスカレートします。
- 理由を指定し、コメントを追加して、解決されたインシデントをクローズします。
一度に複数の分析ルールの応答を自動化します。
実行されるアクションの順序を制御します。
インシデントの内容 (アラート、エンティティ、その他のプロパティ) を検査し、プレイブックを呼び出してさらなるアクションを実行します。
自動化ルールは、"インシデントに関連付けられていない" アラートに応答してプレイブックを実行するのに使用するメカニズムにすることもできます。
つまり、自動化ルールを使用すると、Microsoft Sentinel での自動化の使用が効率化され、脅威対応オーケストレーション プロセスの複雑なワークフローを簡略化することができます。
コンポーネント
自動化ルールは、次のいくつかのコンポーネントで構成されています。
- トリガーは、ルールが実行されたり、条件の対象となったりする原因となるインシデント イベントの種類を定義します。
- 条件は、ルールがアクションを実行する正確な状況を決定します。
- アクションは、インシデントを何らかの方法で変更するか、プレイブックを呼び出します。ここでは、より複雑なアクションを実行し、他のサービスと対話します。
トリガー
自動化ルールは、インシデントが作成または更新されると、あるいはアラートが作成されると、トリガーされます。 インシデントにはアラートが含まれており、「Microsoft Sentinel での脅威検出」で説明されているように、アラートとインシデントはどちらも分析ルールによって作成できることを思い出してください。
次の表は、オートメーション ルールが実行される、さまざまなシナリオを示しています。
| トリガーの種類 | ルールが実行される原因となるイベント |
|---|---|
| インシデント作成時 | Microsoft Defender の統合セキュリティ運用プラットフォーム: 統合プラットフォームにオンボードされていない Microsoft Sentinel: |
| インシデント更新時 | |
| アラートが作成されたとき |
インシデントベースまたはアラートベースの自動化
インシデントとアラートのどちらにも対応する自動化ルールを一元管理する場合、どのような状況で、どちらを自動化する必要があるか、どのように選択すべきでしょうか。
ほとんどのユース ケースでは、インシデントでトリガーされる自動化が推奨されるアプローチです。 Microsoft Sentinel では、インシデントは "ケース ファイル" であり、特定の調査に関連するすべての証拠を集計したものです。 これは、アラート、エンティティ、コメント、コラボレーション、その他の成果物のコンテナーです。 1 つの証拠要素であるアラートとは異なり、インシデントは変更可能で、最新の状態を持ち、コメント、タグ、ブックマークでエンリッチすることができます。 インシデントを使用すると、新しいアラートを追加することで進化し続ける攻撃ストーリーを追跡できます。
これらの理由から、インシデントを中心に自動化を構築する方がより理にかなっています。 そのため、プレイブックを作成する最も適切な方法は、Azure Logic Apps の Microsoft Sentinel インシデント トリガーをベースにすることです。
アラートでトリガーされる自動化を使用する主な理由は、"インシデントを作成しない" 分析ルール (つまり、分析ルール ウィザードの [インシデント設定] タブで "無効化" した場合) によって生成されたアラートに応答するためです。
この理由は、Microsoft Sentinel ワークスペースが統合セキュリティ オペレーション プラットフォームにオンボードされている場合に特に関連します。 このシナリオでは、すべてのインシデント作成は Microsoft Defender XDR で発生するため、Microsoft Sentinel のインシデント作成ルールを無効にする必要があります。
統合ポータルにオンボードしなくても、他の外部ロジックを使用してアラートからインシデントを作成するかどうかとその方法、およびアラートをグループ化する方法を決定する場合は、アラートでトリガーされる自動化の使用を決定できます。 次に例を示します。
プレイブックでは、関連付けられたインシデントを持たないアラートによってトリガーされ、他のソースからの情報でアラートのエンリッチを行い、いくつかの外部ロジックに基づいてインシデントを作成するかどうかを決定することができます。
プレイブックはアラートによってトリガーされ、インシデントを作成する代わりに、アラートを追加するための適切な既存のインシデントを探すことができます。 インシデント拡張の詳細について参照してください。
プレイブックはアラートでトリガーされ、SOC の担当者にアラートを通知するため、チームはインシデントを作成するかどうかを決定できます。
プレイブックはアラートによってトリガーされ、インシデントの作成と管理のために外部のチケット システムにアラートを送信し、システムで各アラートに対して新しいチケットが作成されます。
Note
アラートでトリガーされる自動化は、スケジュールされた分析ルール、NRT 分析ルール、Microsoft セキュリティ分析ルールによって作成されるアラートに対してのみ使用できます。
Microsoft Defender XDR によって作成されるアラートのアラートでトリガーされる自動化は、統合セキュリティ オペレーション プラットフォームでは使用できません。 詳細については、「統合セキュリティ オペレーション プラットフォームを使用した自動化」を参照してください。
条件
複雑な条件のセットを定義して、アクション (以下を参照) を実行するタイミングを制御できます。 これらの条件には、ルールをトリガーするイベント (作成または更新されたインシデント、または作成されたアラート)、インシデントのプロパティとエンティティ プロパティの状態または値 (インシデント トリガーのみ)、およびインシデントかアラートを生成した 1 つまたは複数の分析ルールが含まれます。
自動化ルールがトリガーされると、ルールで定義されている条件に照らしてトリガーのインシデントまたはアラートがチェックされます。 インシデントの場合、プロパティベースの条件は、評価が発生した時点のプロパティの現在の状態に従って、またはプロパティの状態の変化に従って評価されます (詳細については以下を参照)。 1 つのインシデント作成または更新イベントによって複数の自動化ルールがトリガーされる可能性があるため、実行の順序 (下記を参照) によって、条件の評価結果の判断に違いが生じます。 ルールで定義されているアクションは、すべての条件が満たされている場合にのみ実行されます。
インシデント作成トリガー
インシデントの作成時トリガーを使用して定義されたルールの場合、次の演算子の 1 つ以上を使用して、インシデント プロパティの特定のリストの値の現在の状態を確認する条件を定義できます。
- 条件で定義された値と等しいまたは等しくない。
- 条件で定義された値を含むまたは含まない。
- 条件で定義された値で開始するまたは開始しない。
- 条件で定義された値で終了するまたは終了しない。
たとえば、"分析ルール名" を Contains == Brute force attack against a Cloud PC として定義した場合、Brute force attack against Azure portal を含む分析ルールは条件を満たしていません。 しかし、"分析ルール名" を Does not contain == User credentials として定義した場合、Brute force attack against a Cloud PC 分析ルールと Brute force against Azure portal 分析ルールは条件を満たしています。
Note
このコンテキストでの現在の状態とは、条件が評価される瞬間 (つまり、自動化ルールが実行された瞬間) を指します。 このインシデントの作成に応じて実行するように複数の自動化ルールが定義されている場合、先に実行された自動化ルールによってインシデントに加えられた変更は、後で実行されるルールの現在の状態と見なされます。
インシデント更新トリガー
インシデントの更新時トリガーを使用して定義されたルールで評価される条件には、インシデント作成トリガーに対して一覧表示されているものがすべて含まれます。 ただし、更新トリガーには、評価できるプロパティがさらに含まれています。
これらのプロパティの 1 つが更新者です。 このプロパティを使用すると、インシデントで変更を加えたソースの種類を追跡できます。 統合セキュリティ オペレーション プラットフォームにワークスペースをオンボードしたかどうかに応じて、インシデントが次のいずれかの値によって更新されたかどうかを評価する条件を作成できます。
- アプリケーション (Azure および Defender ポータルの両方のアプリケーションを含む)。
- ユーザー (Azure および Defender ポータルの両方でユーザーが行った変更を含む)。
- AIR (Microsoft Defender for Office 365 での自動化された調査と対応による更新プログラム用)
- アラートのグループ化 (インシデントにアラートを追加) (分析ルールと組み込みの Microsoft Defender XDR 相関ロジックの両方によって実行されたアラートのグループ化を含む)
- プレイブック
- オートメーション ルール
- その他 (上記のどの値も適用されない場合)
たとえば、この条件を使用すると、別の自動化ルールによって行われた場合を除き、インシデントに対して行われた変更に対して実行するようにこの自動化ルールに指示できます。
さらに重要なことに、更新トリガーでは、インシデント プロパティの値とその現在の状態の状態の変化をチェックする他の演算子も使用されます。 次の場合に、状態の変化条件が満たされます。
インシデント プロパティの値が
- 変更された (前後の実際の値は問わない)。
- 条件で定義された値から変更された。
- 条件で定義された値に変更された。
- 追加された (これは、値の一覧があるプロパティに適用されます)。
[タグ] プロパティ: 個々とコレクション
インシデント プロパティの [タグ] は、個々のアイテムのコレクションです。つまり、1 つのインシデントに複数のタグを適用できます。 コレクション内の各タグを個別にチェックする条件と、タグのコレクションをユニットとしてチェックする条件を定義できます。
- 個々のタグオペレーターは、コレクション内のすべてのタグに対して条件をチェックします。 少なくとも 1 つのタグが条件を満たしている場合、評価は true です。
- すべてのタグのコレクションオペレーターは、1 つのユニットとしてタグのコレクションに対して条件をチェックします。 コレクション全体が条件を満たしている場合にのみ、評価は true です。
この違いは、条件が否定形 (含まない) であり、コレクション内の一部のタグが条件を満たし、その他のタグが満たしていない場合に重要です。
タグに "2024" が含まれていないという状態で、それぞれ 2 つのタグを持つ 2 つのインシデントがある例を見てみましょう。
| \ インシデント ▶ 条件 ▼ \ |
インシデント 1 タグ 1: 2024 タグ 2: 2023 |
インシデント 2 タグ 1: 2023 タグ 2: 2022 |
|---|---|---|
| 個々のタグに "2024" が含まれない |
TRUE | TRUE |
| すべてのタグのコレクションに "2024" が含まれない |
FALSE | TRUE |
この例では、インシデント 1 では次のようになります。
- 条件が各タグを個別にチェックする場合、 条件を満たす ("2024" が含まれていない) タグが少なくとも 1 つ存在するため、全体的な条件は true になります。
- 条件がインシデント内のすべてのタグを 1 つのユニットとしてチェックする場合、条件を満たしていない ("2024" が含まれている) タグが少なくとも 1 つ存在するため、全体的な条件は false になります。
インシデント 2 では、定義されている条件の種類に関係なく、結果は同じになります。
サポートされているエンティティのプロパティ
自動化ルールの条件としてサポートされているエンティティ プロパティの一覧については、「Microsoft Sentinel 自動化ルールのリファレンス」を参照してください。
アラート作成トリガー
現在、アラート作成トリガーに対して構成できる条件は、自動化ルールが実行される分析ルールのセットのみです。
アクション
条件 (上記参照) が満たされたときに実行するようにアクションを定義できます。 ルールには多くのアクションを定義できます。また、実行する順序を選択することもできます (下記参照)。 次のアクションは、プレイブックの高度な機能を必要とせずに、自動化ルールを使用して定義できます。
インシデントにタスクを追加する - インシデントのトリアージ、調査、修復のプロセス全体を通して、アナリストがフォローするタスクのチェックリストを作成し、重要な手順が見逃されないようにすることができます。
インシデントの状態の変更 – ワークフローを最新の状態に保ちます。
インシデントの重大度の変更 – インシデントに関連するエンティティの存在、非存在、値、または属性に基づいて、再評価や優先順位の変更を行うことができます。
所有者へのインシデントの割り当て – これにより、インシデントの種類を最も適した担当者に伝えたり、最も時間のある担当者に送信したりすることができます。
インシデントへのタグの追加 – これは、インシデントをサブジェクト、攻撃者、またはその他の共通点別に分類する場合に便利です。
また、外部システムを含むものも含めて、より複雑な対応アクションを実行するために、プレイブックを実行するアクションを定義できます。 自動化ルールで使用できるプレイブックは、プレイブック "と" 自動化ルールが基づいているトリガーによって異なります。インシデント トリガーの自動化ルールから実行できるのはインシデント トリガーのプレイブックのみで、アラート トリガーの自動化ルールから実行できるのはアラート トリガーのプレイブックのみです。 プレイブックを呼び出す複数のアクション、またはプレイブックと他のアクションの組み合わせを定義することができます。 アクションは、ルールに記載された順序で実行されます。
いずれかのバージョンの Azure Logic Apps (Standard または Consumption) を使用するプレイブックは、自動化ルールから実行できます。
有効期限
自動化ルールの有効期限を定義できます。 その日が過ぎると、ルールは無効になります。 これは、侵入テストなど、計画された時間限定のアクティビティによって発生する "ノイズ" インシデントの処理 (つまり、終了) に役立ちます。
注文
自動化ルールを実行する順序を定義できます。 その後の自動化規則は、前の自動化規則によって処理された後の状態に従って、インシデントの状態を評価します。
たとえば、"最初の自動化ルール" によってインシデントの重要度が "中" から "低" に変更され、"第 2 の自動化ルール" が "中" または "高" の重大度のインシデントでのみ実行されるように定義されている場合、そのインシデントでは実行されません。
インシデント タスクを追加する自動化ルールの順序によって、特定のインシデントにタスクが現れる順序が決まります。
更新トリガーに基づくルールには、独自の個別の順序キューがあります。 このようなルールは、(別の自動化ルールによって行われた変更によって) 作成されたばかりのインシデントで実行されるようにトリガーされた場合、作成トリガーに基づいて適用できるすべてのルールの実行完了後にのみ実行されます。
実行順序と優先度に関する注意事項
- オートメーション ルール内で順序番号を設定すると、実行順序が決まります。
- トリガー タイプごとに、独自のキューが保持されます。
- Azure portal で作成されたルールの場合、順序フィールドには、同じトリガー タイプの既存のルールで使用されている最大数に続く番号が自動的に入力されます。
- しかし、他の方法 (コマンド ライン、API など) で作成されたルールの場合は、順序番号を手動で割り当てる必要があります。
- 同じトリガー タイプ内であっても、複数のルールが同じ順序番号を持つことを防ぐ検証メカニズムはありません。
- ルールがどの順序で実行されるかを気にしない場合は、同じトリガー タイプの 2 つ以上のルールに同じ順序番号を持たせることができます。
- 同じ順序番号を持つ同じトリガー タイプのルールに関しては、実行エンジンが、どのルールがどの順序で実行されるかをランダムに選択します。
- "インシデント トリガー" タイプが異なるルールの場合、"インシデント作成" トリガー タイプを持つルールが (それらの順序番号に従って) 最初に実行され、その後になって初めて "インシデント更新" トリガー タイプを持つルールが ("それらの" 順序番号に従って) 実行されます。
- ルールは常に順番に実行され、並列に実行されることはありません。
Note
統合セキュリティ オペレーション プラットフォームへのオンボードの後、5 から 10 分間に同じインシデントに複数の変更が加えられた場合、最新の変更のみを含む 1 つの更新が Microsoft Sentinel に送信されます。
一般的なユース ケースとシナリオ
インシデント タスク
オートメーション ルールを使用すると、オートメーション ルールで設定した条件と、基になっている分析ルールの脅威検出ロジックに従って、1 つのインシデント、インシデントグループの全体、またはすべてのインシデントに適用できるタスクを作成することで、インシデントのトリアージ、調査、修復に必要な手順を標準化し、正式化することができます。 インシデントに適用されたタスクはインシデントのページに表示されるため、アナリストには、実行する必要があるアクションの一覧全体が目の前に用意されるので、重要な手順を見逃すことがありません。
インシデントとアラートによってトリガーされる自動化
自動化ルールは、インシデントの作成または更新、およびアラートの作成によってトリガーできます。 これらの事象は、すべての自動応答チェーンをトリガーできます。これにはプレイブックを含めることができます (特別なアクセス許可が必要です)。
Microsoft プロバイダーのプレイブックをトリガーする
自動化ルールは、アラートから作成されたインシデントにこれらのルールを適用することによって、Microsoft セキュリティ アラートの処理を自動化する方法を提供します。 自動化ルールでは、プレイブックを呼び出すことができ (特別なアクセス許可が必要)、アラートやエンティティなどのすべての詳細情報を含むインシデントをそれらに渡すことができます。 一般に、Microsoft Sentinel のベスト プラクティスでは、セキュリティ操作の中心としてインシデント キューを使用します。
Microsoft セキュリティ アラートには、次のものが含まれます。
- Microsoft Entra ID Protection
- Microsoft Defender for Cloud
- Microsoft Defender for Cloud Apps
- Microsoft Defender for Office 365
- Microsoft Defender for Endpoint
- Microsoft Defender for Identity
- Microsoft Defender for IoT
1 つのルールで順序付けられた複数のプレイブック/アクション
1 つの自動化ルールで、アクションとプレイブックの実行順序をほぼ完全に制御できるようになりました。 また、自動化ルールの実行順序も制御します。 これにより、プレイブックを大幅に簡素化し、1 つのタスクまたは小規模で簡単な一連のタスクに減らすことができます。また、これらの小さなプレイブックは、さまざまな自動化ルールで異なる組み合わせで組み合わせることができます。
一度に 1 つのプレイブックを複数の分析ルールに割り当てる
外部のチケット発行システムでサポート チケットを作成するなど、すべての分析ルールで自動化するタスクがある場合は、すべての分析ルール (将来のルールを含む) に 1 つのプレイブックを 1 回の操作で適用できます。 これにより、簡単であるものの反復的なメンテナンスとハウスキーピング タスクの手間が省けます。
インシデントの自動割り当て
適切な所有者にインシデントを自動的に割り当てることができます。 SOC に特定のプラットフォームを専門とするアナリストがいる場合、そのプラットフォームに関連するすべてのインシデントを自動的にそのアナリストに割り当てることができます。
インシデントの抑制
ルールを使用して、プレイブックを使用せずに、誤検知または害のないインシデントを自動的に解決できます。 たとえば、侵入テストを実行するとき、スケジュールされたメンテナンスやアップグレードを実行するとき、または自動化手順をテストするときに、SOC が無視する多くの誤検知インシデントを作成することができます。 時間限定の自動化ルールは、作成時にこれらのインシデントを自動的に閉じ、生成の原因の記述子でタグ付けします。
時間限定の自動化
自動化ルールに有効期限を追加できます。 時間限定の自動化を保証するインシデント抑制以外のケースもあります。 特定の期間の特定のユーザー (たとえば、インターンやコンサルタント) に特定の種類のインシデントを割り当てることができます。 時間枠が事前にわかっている場合は、適切なタイミングでルールを無効にすることができます。その場合、そのことを覚えておく必要はありません。
インシデントに自動的にタグを付ける
フリーテキスト タグをインシデントに自動的に追加して、選択した条件に従ってグループ化または分類することができます。
更新トリガーによって追加されたユース ケース
インシデントに加えられた変更によって自動化ルールをトリガーできるようになったので、自動化に対してより多くのシナリオが開かれています。
インシデントの進化時に自動化を拡張する
更新トリガーを使用すると、調査が進行し、アナリストがアラート、コメント、タグを追加するときに、上記のユース ケースの多くをインシデントに適用できます。 インシデントでのアラートのグループ化を制御します。
オーケストレーションと通知を更新する
インシデントに変更が加えられたときにさまざまなチームやその他の担当者に通知して、重要な更新が見逃されないようにします。 インシデントをエスカレートするには、それらを新しい所有者に割り当て、新しい所有者に割り当てを通知します。 インシデントを再び開くタイミングと方法を制御します。
外部システムとの同期を維持する
インシデントの作成時にプレイブックを使用して外部システムでチケットを作成した場合は、update-trigger 自動化ルールを使用して、それらのチケットを更新するプレイブックを呼び出すことができます。
自動化ルールの実行
自動化ルールは、決定した順序に従って順番に実行されます。 各自動化ルールは、前の規則の実行が完了した後に実行されます。 自動化ルール内では、すべてのアクションが、定義されている順序で順番に実行されます。
自動化ルール内のプレイブック アクションは、次の基準に従って、ある状況下では異なって処理されることがあります。
| プレイブックの実行時間 | 自動化ルールが次のアクションに進むタイミング |
|---|---|
| 1 秒未満 | プレイブックが完了した直後 |
| 2 分未満 | プレイブックの実行開始から最長 2 分後。 ただし、プレイブックが完了してから 10 秒以内 |
| 2 分以上 | プレイブックの実行開始から 2 分後。 それが完了したかどうかは無関係 |
プレイブックを実行するための自動化ルールへのアクセス許可
Microsoft Sentinel オートメーション ルールでプレイブックを実行すると、このアクションに対して特別に承認された特別な Microsoft Sentinel サービス アカウントが使用されます。 (ユーザー アカウントではなく) このアカウントを使用すると、サービスのセキュリティ レベルが向上します。
自動化ルールでプレイブックを実行するには、このアカウントに、プレイブックが存在するリソース グループに対する明示的なアクセス許可が付与されている必要があります。 その時点で、すべての自動化ルールでそのリソース グループ内のすべてのプレイブックを実行できるようになります。
自動化ルールを構成し、[プレイブックの実行] アクションを追加すると、プレイブックのドロップダウン リストが表示されます。 Microsoft Sentinel でアクセス許可を持たないプレイブックは、使用不可として ("淡色表示" で) 表示されます。 [プレイブックのアクセス許可の管理] リンクを選択すると、Microsoft Sentinel のアクセス許可を、プレイブックのリソース グループにすぐに付与できます。 これらのアクセス許可を付与するには、それらのリソース グループに対する所有者アクセス許可が必要です。 フル アクセス許可の要件を参照してください。
マルチテナント アーキテクチャにおけるアクセス許可
オートメーション ルールでは、クロスワークスペースおよびマルチテナント デプロイが完全にサポートされています (マルチテナントの場合は、Azure Lighthouse を使用します)。
そのため、Microsoft Sentinel デプロイでマルチテナント アーキテクチャを使用している場合、1 つのテナント内のオートメーション ルールに別のテナント内に存在するプレイブックを実行させることができます。ただし、Sentinel がプレイブックを実行するためのアクセス許可は、オートメーション ルールが定義されているテナント内ではなく、プレイブックが存在するテナント内で定義する必要があります。
顧客テナント内でサービス プロバイダー テナントによって Microsoft Sentinel ワークスペースが管理される、マネージド セキュリティ サービス プロバイダー (MSSP) の特殊なケースでは、注意が必要なシナリオが 2 つあります。
顧客テナント内に作成された自動化ルールが、サービス プロバイダー テナント内に配置されているプレイブックを実行するように構成されている。
このアプローチは、通常、プレイブック内の知的所有権を保護するために使用されます。 このシナリオは、特に何もしなくても機能します。 オートメーション ルール内でプレイブック アクションを定義しているとき、([プレイブックのアクセス許可の管理] ウィンドウを使用して) プレイブックが配置されている関連リソース グループに対して Microsoft Sentinel アクセス許可を付与する段階になると、サービス プロバイダー テナントに属するリソース グループを確認できるため、ここから選択できます。 プロセス全体については、こちらをご覧ください。
(サービス プロバイダー テナントへのサインイン中に) 顧客ワークスペース内に作成された自動化ルールが、顧客テナント内に配置されているプレイブックを実行するように構成されている。
この構成は、知的所有権を保護する必要がない場合に使用されます。 このシナリオが機能するためには、プレイブックを実行するためのアクセス許可が、"両方のテナント" 内の Microsoft Sentinel に付与されている必要があります。 顧客テナント内では、上記のシナリオと同様、_[プレイブックのアクセス許可の管理] パネル内でそれらを付与します。 サービス プロバイダー テナント内で関連するアクセス許可を付与するには、プレイブックが存在するリソース グループに対して、Microsoft Sentinel Automation 共同作成者ロールを使用して、Azure Security Insights アプリへのアクセス権を付与する追加の Azure Lighthouse 委任を追加する必要があります。
シナリオは次のようになります。
この設定方法については、こちらの手順を参照してください。
自動化ルールの作成と管理
特定のニーズやユース ケースに応じて、Microsoft Sentinel または統合セキュリティ オペレーション プラットフォームのさまざまな領域から自動化ルールを作成および管理できます。
[自動化] ページ
自動化ルールは、[自動化ルール] タブの [自動化] ページで一元的に管理できます。ここから、新しい自動化ルールを作成したり、既存の自動化ルールを編集したりすることができます。 また、自動化ルールをドラッグして、実行の順序を変更し、それらを有効または無効にすることもできます。
[自動化] ページでは、定義されているすべてのルールとその状態 (有効/無効)、および適用されている分析ルールがワークスペースに表示されます。
Microsoft Defender XDR または Microsoft Sentinel の多くの分析ルールからのインシデントに適用される自動化ルールが必要な場合は、[自動化] ページで直接作成します。
分析ルール ウィザード
Microsoft Sentinel 分析ルール ウィザードの [自動応答] タブの [自動化ルール] で、ウィザードで作成または編集する特定の分析ルールに適用される自動化ルールを表示、編集、作成できます。
ここから自動化ルールを作成すると、[新しい自動化ルールの作成] パネルに [分析ルール] の条件が [使用不可] として表示されます。このルールは、ウィザードで編集中の分析ルールにのみ適用されるように既に設定されているためです。 その他のすべての構成オプションは、引き続き使用できます。
[インシデント] ページ
単一の定期的なインシデントに対応するために、[インシデント] ページから自動化ルールを作成することもできます。 これは、"ノイズの多い" インシデントを自動的に閉じるための抑制ルールを作成する場合に便利です。
ここで自動化ルールを作成するときに、[新しい自動化ルールの作成] パネルには、すべてのフィールドにインシデントの値が設定されていることがわかります。 このルールには、インシデントと同じ名前を付けて、インシデントを生成した分析ルールに適用し、インシデントで使用可能なすべてのエンティティをルールの条件として使用します。 また、既定では抑制 (終了) アクションが提案され、ルールの有効期限が提案されます。 必要に応じて、条件とアクションを追加または削除したり、有効期限を変更したりできます。
オートメーション ルールのエクスポートとインポートを行う
Microsoft Sentinel デプロイをコードとして管理および制御する一環として、自動化ルールを Azure Resource Manager (ARM) テンプレート ファイルからエクスポートし、それらのルールを同様のファイルにインポートします。 エクスポート操作により、ブラウザーのダウンロード場所に JSON ファイルが作成されます。このファイルは、ファイル名の変更や移動など、他のファイルと同様に処理することができます。
エクスポートされた JSON ファイルはワークスペースに依存しないので、他のワークスペースや他のテナントにもインポートできます。 コードとして、マネージド CI/CD フレームワークでバージョン管理、更新、デプロイすることもできます。
このファイルには、オートメーション ルールで定義されているすべてのパラメーターが含まれています。 任意の種類のトリガーのルールを JSON ファイルにエクスポートできます。
自動化ルールのエクスポートとインポートの手順については、Microsoft Sentinel 自動化ルールのエクスポートとインポートに関するページを参照してください。
次のステップ
このドキュメントでは、Microsoft Sentinel のインシデントとアラートに対する応答の自動化を自動化ルールで一元管理する方法について説明しました。
- Microsoft Sentinel 自動化ルールを作成および使用してインシデントを管理します。
- オートメーション ルールを使用してアナリスト向けのタスクのリストを作成します。
- 高度な自動化オプションの詳細については、「Microsoft Sentinel のプレイブックを使用して脅威への対応を自動化する」を参照してください。
- プレイブックを実装する方法については、プレイブックを使用して Microsoft Sentinel で脅威への対応を自動化する方法のチュートリアルに関するページを参照してください。