概要ルールを使用して Microsoft Sentinel データを集計する

Use summary rules in Microsoft Sentinel to aggregate large sets of data in the background for a smoother security operations experience across all log tiers. 集計データはカスタム ログ テーブルでプリコンパイルされ、低コストのログ層から派生したデータに対して実行されるクエリを含め、高速なクエリ パフォーマンスが提供されます。 集計ルールを使用すると、次の目的でデータを最適化できます。

• 分析とレポート。特に、セキュリティおよびインシデント分析、月次または年次ビジネス レポートなどに必要な、大規模なデータ セットと時間の範囲が対象。
• Cost savings on verbose logs, which you can retain for as little or as long as you need in a less expensive log tier, and send as summarized data only to an Analytics table for analysis and reports.
• セキュリティとデータ プライバシー。集計された共有可能なデータのプライバシーの詳細を削除または難読化し、生データを含むテーブルへのアクセスを制限することで確保します。

Microsoft Sentinel stores summary rule results in custom tables with the Analytics data plan. データ プランとストレージ コストの詳細については、「 ログ テーブル プラン」を参照してください。

この記事では、概要ルールを作成する方法、または Microsoft Sentinel で事前構築済みの概要ルール テンプレートをデプロイする方法について説明し、概要ルールを使用するための一般的なシナリオの例を示します。

Prerequisites

Microsoft Sentinel で集計ルールを作成するための前提条件は、以下の通りです。

• Microsoft Sentinel を少なくとも 1 つのワークスペースで有効にし、ログをアクティブに使用する必要があります。

• Microsoft Sentinel 共同作成者のアクセス許可を使用して Microsoft Sentinel にアクセスできるようにする必要があります。 詳細については、Microsoft Sentinel でのロールとアクセス許可に関する記事を参照してください。

• Microsoft Defender ポータルで集計ルールを作成するには、最初にワークスペースを Defender ポータルにオンボードする必要があります。 詳細については、「Microsoft Defender ポータルに Microsoft Sentinel を接続する」を参照してください。

ルールを作成する前に、[ログ] ページで集計ルールクエリを試しておくことをお勧めします。 Verify that the query doesn't reach or near the query limit, and check that the query produces the intended schema and expected results. クエリがクエリの制限に近づいている場合は、小さな binSize を使用して、ビンごとに処理するデータを減らすことを検討してください。 また、クエリを変更して、返されるレコード数を減らしたり、ボリュームが大きいフィールドを削除したりすることもできます。

新しい概要ルールを作成する

新しい集計ルールを作成して、大規模な特定のデータ セットを動的テーブルで集計します。 ルールの頻度を設定して、集計されたデータ セットが生データから更新される頻度を決定します。

1. 概要ルール ウィザードを開きます。

   • Defender ポータルで [Microsoft Sentinel] > [構成] > [集計ルール] を選択します。

   • For example: For example:

     

2. Select + Create and enter the following details:

   • Name. ルールのわかりやすい名前を入力します。

   • Description. 必要に応じて説明を入力します。

   • Destination table. データが集計されるカスタム ログ テーブルを定義します。

     • [既存のカスタム ログ テーブル] を選択した場合は、使用するテーブルを選択します。

     • [新しいカスタム ログ テーブル] を選択した場合は、テーブルにわかりやすい名前を入力します。 完全なテーブル名には、<tableName>_CL 構文を使用してください。

3. We recommend that you enable SummaryLogs diagnostic settings on your workspace to get visibility for historical runes and failures. If SummaryLogs diagnostic settings aren't enabled, you're prompted to enable them in the Diagnostic settings area.

   If SummaryLogs diagnostic settings are already enabled, but you want to modify the settings, select Configure advanced diagnostic settings. [集計ルール ウィザード] ページに戻ったら、必ず [更新] を選択して設定の詳細を更新してください。

   Important

   The SummaryLogs diagnostic setting has additional costs. 詳しくは、「Azure Monitor の診断設定」をご覧ください。

4. [Next: Set summary logic]\(次へ: 集計 ロジックの設定)\> を選択して続行します。

5. [Set summary logic]\(集計ロジックの設定)\ ページで、集計クエリを入力します。 たとえば、Google Cloud Platform のデータを要約するには、次のように入力します。

   GCPAuditLogs
   | where ServiceName == 'pubsub.googleapis.com'
   | summarize count() by Severity
   

   詳細については、「集計ルールのシナリオのサンプル」と「Azure Monitor の Kusto 照会言語 (KQL)」を参照してください。

6. Select Preview results to show an example of the data you'd collect with the configured query.

7. In the Query scheduling area, define the following details:

   • ルールを実行する頻度
   • 何らかの遅延があってもルールを実行するかどうか (分単位)
   • ルールの実行を開始するタイミング

   スケジューリングで定義される時間は、データ内の timegenerated 列に基づきます

8. [次へ: 確認と作成]>>[保存] を選択して、集計ルールを完了します。

ルールごとに、行の末尾にあるオプション メニューを選択して、次のいずれかのアクションを実行します。 For each rule, select the options menu at the end of the row to take any of the following actions:

• View the rule's current data in the Logs page, as if you were to run the query immediately
• 選択したルールの実行履歴を表示する
• ルールを無効または有効にする
• ルールの構成を編集する

To delete a rule, select the rule row and then select Delete in the toolbar at the top of the page.

事前構築済みの概要ルール テンプレートをデプロイする

サマリー ルール テンプレートは、as-is をデプロイしたり、ニーズに合わせてカスタマイズしたりできる事前構築済みの概要ルールです。

概要ルール テンプレートをデプロイするには:

1. Open the Content hub and filter Content type by Summary rules to view the available summary rule templates.

   

2. 概要ルール テンプレートを選択します。

   概要ルール テンプレートに関する情報が表示されたパネルが開き、説明、サマリー クエリ、変換先テーブルなどのフィールドが表示されます。

   

3. Select Install to install the template.

4. Select the Templates tab on the Summary rules page, and select the summary rule you installed.

   

5. Select Create to open the Summary rule wizard, where all of the fields are prepopulated.

6. Go through the Summary rule wizard and select Save to deploy the summary rule.

   概要ルール ウィザードの詳細については、「 新しい概要ルールを作成する」を参照してください。

Microsoft Sentinel の概要ルール シナリオの例

このセクションでは、Microsoft Sentinel で集計ルールを作成するための一般的なシナリオと、各ルールの構成方法に関する推奨事項について説明します。 詳細と例については、「 補助テーブルの生データから Microsoft Sentinel の分析テーブルへの分析情報の要約 」および 「補助ログの取り込みに使用するログ ソース」を参照してください。

ネットワーク トラフィック内の悪意のある IP アドレスをすばやく見つける

Scenario: You're a threat hunter, and one of your team's goals is to identify all instances of when a malicious IP address interacted in the network traffic logs from an active incident, in the last 90 days.

Challenge: Microsoft Sentinel currently ingests multiple terabytes of network logs a day. 悪意のある IP アドレスと一致するアドレスを見つけるには、大量のログを迅速に調査していく必要があります。

Solution: We recommend using summary rules to do the following:

1. インシデントに関連する各 IP アドレスに集計データ セットを作成します。これには SourceIP、DestinationIP、MaliciousIP、RemoteIP や、IPType、FirstTimeSeen、LastTimeSeen などの重要な属性のリストが含まれます。

   集計データセットを使用すると、特定の IP アドレスをすばやく検索し、IP アドレスが検出された時間範囲を絞り込むことができます。 この操作は、検索されたイベントが 90 日以上前に発生し、ワークスペースの保持期間を超えた場合でも実行できます。

   この例では、有効期限が切れるまでクエリに毎日新しい集計 レコードが追加されるように、集計を毎日実行するよう構成します。

2. 集計データセットに対して 2 分未満で実行できる分析ルールを作成し、会社のネットワークで悪意のある IP アドレスが使用されたときに特定の時間範囲をすばやく調査します。

   さまざまな集計のペイロード サイズに対応できるように、実行間隔は少なくとも 5 分までで設定してください。 これにより、イベントのインジェストに遅延が発生しても損失が発生しないようにします。

   For example:

   let csl_columnmatch=(column_name: string) {
   summarized_CommonSecurityLog
   | where isnotempty(column_name)
   | extend
       Date = format_datetime(TimeGenerated, "yyyy-MM-dd"),
       IPaddress = column_ifexists(column_name, ""),
       FieldName = column_name
   | extend IPType = iff(ipv4_is_private(IPaddress) == true, "Private", "Public")
   | where isnotempty(IPaddress)
   | project Date, TimeGenerated, IPaddress, FieldName, IPType, DeviceVendor
   | summarize count(), FirstTimeSeen = min(TimeGenerated), LastTimeSeen = min(TimeGenerated) by Date, IPaddress, FieldName, IPType, DeviceVendor
   };
   union csl_columnmatch("SourceIP")
       , csl_columnmatch("DestinationIP") 
       , csl_columnmatch("MaliciousIP")
       , csl_columnmatch("RemoteIP")
   // Further summarization can be done per IPaddress to remove duplicates per day on larger timeframe for the first run
   | summarize make_set(FieldName), make_set(DeviceVendor) by IPType, IPaddress
   

3. 次の検索や他のデータとの関連付けを実行して、攻撃のストーリーを完了します。

ネットワーク データで一致した脅威インテリジェンスに対してアラートを生成する

ノイズが多く、セキュリティの値が低い大量のネットワーク データに一致する脅威インテリジェンスに対してアラートを生成しします。

Scenario: You need to build an analytics rule for firewall logs to match ___domain names in the system that have been visited against a threat intelligence ___domain name list.

ほとんどのデータ ソースは、ノイズが多くボリュームが多い生ログですが、IP アドレス、Azure Firewall トラフィック、Fortigate トラフィックなど、セキュリティ値は低くなります。 合計で 1 日あたり約 1 TB のボリュームがあります。

Challenge: Creating separate rules requires multiple logic apps, requiring extra setup and maintenance overhead and costs.

Solution: We recommend using summary rules to do the following:

1. 集計ルールを作成する:

   1. Extend your query to extract key fields, such as the source address, destination address, and destination port from the CommonSecurityLog_CL table, which is the CommonSecurityLog with the Auxiliary plan.

   2. アクティブな脅威インテリジェンス インジケーターに対して内部検索を実行して、ソース アドレスとの一致を特定します。 これにより、既知の脅威でデータを相互参照できます。

   3. 生成された時間、アクティビティの種類、悪意のあるソース IP、宛先の詳細などの関連情報を射影します。 Set the frequency you want the query to run, and the destination table, such as MaliciousIPDetection . このテーブルの結果は分析レベルにあり、それに応じて課金されます。

2. アラートを作成する:

   Creating an analytics rule in Microsoft Sentinel that alerts based on results from the MaliciousIPDetection table. この手順は、プロアクティブな脅威検出とインシデント対応に不可欠です。

集計ルールの例:

CommonSecurityLog_CL​
| extend sourceAddress = tostring(parse_json(Message).sourceAddress), destinationAddress = tostring(parse_json(Message).destinationAddress), destinationPort = tostring(parse_json(Message).destinationPort)​
| lookup kind=inner (ThreatIntelligenceIndicator | where Active == true ) on $left.sourceAddress == $right.NetworkIP​
| project TimeGenerated, Activity, Message, DeviceVendor, DeviceProduct, sourceMaliciousIP =sourceAddress, destinationAddress, destinationPort

Related content

• 集計ルールを使用して Log Analytics ワークスペースのデータを集計する
• コストを計画し、Microsoft Sentinel の価格と課金を理解する
• 補助ログのインジェストに使用するログ ソース
• 集計ルールの制限事項と制約事項