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

Microsoft Sentinel の 概要ルール を使用して、バックグラウンドで大量のデータ セットを集計し、すべてのログ層でスムーズなセキュリティ操作エクスペリエンスを実現します。 集計データはカスタム ログ テーブルでプリコンパイルされ、低コストのログ層から派生したデータに対して実行されるクエリを含め、高速なクエリ パフォーマンスが提供されます。 集計ルールを使用すると、次の目的でデータを最適化できます。

• 分析とレポート。特に、セキュリティおよびインシデント分析、月次または年次ビジネス レポートなどに必要な、大規模なデータ セットと時間の範囲が対象。
• 詳細ログをコストの低いログ層で財布に優しい期間で保持し、必要に応じて要約データを分析とレポート用にAnalyticsテーブルのみに送信することで、コストを削減できます。
• セキュリティとデータ プライバシー。集計された共有可能なデータのプライバシーの詳細を削除または難読化し、生データを含むテーブルへのアクセスを制限することで確保します。

Microsoft Sentinel では、 Analytics データ プランを使用して、集計ルールの結果をカスタム テーブルに格納します。 データ プランとストレージ コストの詳細については、「 ログ テーブル プラン」を参照してください。

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

Prerequisites

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

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

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

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

ルールを作成する前に、[ログ] ページで集計ルールクエリを試しておくことをお勧めします。 クエリがクエリの 制限に達していないか、または近くに達していないことを確認し、クエリによって目的のスキーマと予想される結果が生成されることを確認します。 クエリがクエリの制限に近づいている場合は、小さな binSize を使用して、ビンごとに処理するデータを減らすことを検討してください。 また、クエリを変更して、返されるレコード数を減らしたり、ボリュームが大きいフィールドを削除したりすることもできます。

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

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

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

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

   • Azure portal の Microsoft Sentinel ナビゲーション メニューの [ 構成] で、[ 概要ルール] を選択します。 例えば次が挙げられます。

     

2. [ + 作成] を選択し、次の詳細を入力します。

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

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

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

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

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

3. ワークスペースで SummaryLogs 診断設定を有効にして、履歴ログおよび障害を表示することをお勧めします。 SummaryLogs 診断設定が有効になっていない場合は、[診断設定] 領域で有効にするように求められます。

   SummaryLogs 診断設定が既に有効になっていても、設定を変更する場合は、[診断の詳細設定の構成] を選択します。 [集計ルール ウィザード] ページに戻ったら、必ず [更新] を選択して設定の詳細を更新してください。

   Important

   SummaryLogs 診断設定には追加のコストがかかります。 詳しくは、「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. [ 結果のプレビュー ] を選択すると、構成されたクエリで収集するデータの例が表示されます。

7. [クエリ スケジュール] 領域で、次の詳細を定義します。

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

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

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

既存のサマリー ルールが [ 概要ルール ] ページに一覧表示され、ルールの状態を確認できます。 ルールごとに、行の末尾にあるオプション メニューを選択して、次のいずれかのアクションを実行します。

• クエリをすぐに実行するかのように、[ ログ ] ページでルールの現在のデータを表示する
• 選択したルールの実行履歴を表示する
• ルールを無効または有効にする
• ルールの構成を編集する

ルールを削除するには、ルール行を選択し、ページの上部にあるツール バーの [ 削除 ] を選択します。

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

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

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

1. コンテンツ ハブを開き、概要ルールでコンテンツ タイプをフィルター処理して、使用可能なサマリー ルール テンプレートを表示します。

   

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

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

   

3. [ インストール] を選択してテンプレートをインストールします。

4. [概要ルール] ページで [テンプレート] タブを選択し、インストールした概要ルールを選択します。

   

5. [ 作成 ] を選択して概要ルール ウィザードを開きます。ここでは、すべてのフィールドが事前設定されています。

6. 概要ルール ウィザードを実行し、[ 保存] を選択して概要ルールを展開します。

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

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

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

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

シナリオ: 脅威ハンターであり、チームの目標の 1 つは、過去 90 日間にアクティブなインシデントからネットワーク トラフィック ログで悪意のある IP アドレスが対話した場合のすべてのインスタンスを特定することです。

課題: Microsoft Sentinel は現在、1 日に数テラバイトのネットワーク ログを取り込みます。 悪意のある IP アドレスと一致するアドレスを見つけるには、大量のログを迅速に調査していく必要があります。

解決策: 概要ルールを使用して、次の操作を行うことをお勧めします。

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

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

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

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

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

   例えば次が挙げられます。

   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. 次の検索や他のデータとの関連付けを実行して、攻撃のストーリーを完了します。

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

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

シナリオ: 脅威インテリジェンス ドメイン名リストに対してアクセスされたシステム内のドメイン名と一致するように、ファイアウォール ログの分析規則を構築する必要があります。

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

課題: 個別のルールを作成するには、複数のロジック アプリが必要であり、追加のセットアップとメンテナンスのオーバーヘッドとコストが必要です。

解決策: 概要ルールを使用して、次の操作を行うことをお勧めします。

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

   1. クエリを拡張して、補助プランの CommonSecurityLog である CommonSecurityLog_CL テーブルから、ソース アドレス、宛先アドレス、宛先ポートなどのキー フィールドを抽出します。

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

   3. 生成された時間、アクティビティの種類、悪意のあるソース IP、宛先の詳細などの関連情報を射影します。 クエリを実行する頻度と、対象テーブル ( MaliciousIPDetection など) を設定します。 このテーブルの結果は分析レベルにあり、それに応じて課金されます。

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

   MaliciousIPDetection テーブルからの結果に基づいてアラートを生成する分析ルールを Microsoft Sentinel で作成する。 この手順は、プロアクティブな脅威検出とインシデント対応に不可欠です。

集計ルールの例:

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

関連するコンテンツ

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