次の方法で共有


集計ルールを使用して Microsoft Sentinel データを集計する (プレビュー)

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

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

検出、調査、ハンティング、およびレポートアクティビティ全体で、Kusto 照会言語 (KQL) を介して集計ルールの結果にアクセスします。 集計ルールの結果は、履歴調査、ハンティング、コンプライアンス アクティビティで長期的に使います。

集計ルールの結果は、Analytics データ プランの下にある個別のテーブルに格納され、それに応じて課金されます。 データ プランとストレージ コストの詳細については、「Log Analytics ワークスペースの使用パターンに基づいてテーブル プランを選択する」を参照してください。

重要

集計ルールは現在、プレビュー段階です。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用されるその他の法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

Microsoft Sentinel は、Microsoft Defender ポータルの Microsoft の統合セキュリティ オペレーション プラットフォーム内で一般提供されています。 プレビューでは、Microsoft Defender XDR または E5 ライセンスなしで Microsoft Sentinel を Defender ポータルで利用できます。 詳しくは、「Microsoft Defender ポータルの Microsoft Sentinel」を参照してください。

前提条件

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

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

集計ルールを作成する

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

  1. Azure portal で、Microsoft Sentinel のナビゲーション メニューから [構成] の下にある [集計ルール (プレビュー)] を選択します。 Defender ポータルで [Microsoft Sentinel]>[構成]>[集計ルール (プレビュー)] を選択します。 次に例を示します。

    Azure portal の [集計ルール] ページのスクリーンショット。

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

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

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

    • [ターゲット テーブル]。 データが集計されるカスタム ログ テーブルを定義します。

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

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

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

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

    重要

    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. [次へ: 確認と作成]>>[保存] を選択して、集計ルールを完了します。

既存の集計ルールは [集計ルール (プレビュー)] ページに一覧表示され、ここでルールの状態を確認できます。 ルールごとに、行の末尾にあるオプション メニューを選択して、次のいずれかのアクションを実行します。

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

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

Note

Azure Monitor では、API または Azure Resource Monitor (ARM) テンプレートを使用した集計ルールの作成もサポートされています。 詳細については、「集計ルールの作成または更新」を参照してください。

集計ルールのシナリオの例

このセクションでは、Microsoft Sentinel で集計ルールを作成するための一般的なシナリオと、各ルールの構成方法に関する推奨事項について説明します。 詳細と例については、「補助ログと共に集計ルールを使用する (サンプル プロセス)」と「補助ログのインジェストに使用するログ ソース」を参照してください。

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

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

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

ソリューション: 集計ルールを使用して、次の手順を実行することをお勧めします。

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

    集計データセットを使用すると、特定の 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_CL テーブルからソース アドレス、宛先アドレス、宛先ポートなどのキー フィールドを抽出します。これは、Auxilairy プランを使用した CommonSecurityLog です。

    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

補助ログと共に集計ルールを使用する (サンプル プロセス)

この手順では、Logstash から CEF データを取り込むために ARM テンプレートを介して作成されたカスタム接続を使用して、補助ログで集計ルールを使用するサンプル プロセスについて説明します。

  1. Logstash からカスタム CEF コネクタを設定します。

    1. 次の ARM テンプレートを Microsoft Sentinel ワークスペースにデプロイして、データ収集規則 (DCR) とデータ収集エンドポイント (DCE) を含むカスタム テーブルを作成します。

      Azure に配置する

    2. ARM テンプレートの出力では、次の詳細に着目します。

      • tenant_id
      • data_collection_endpoint
      • dcr_immutable_id
      • dcr_stream_name
    3. Microsoft Entra アプリケーションを作成し、アプリケーションのクライアント IDシークレットをメモします。 詳細については、「チュートリアル: ログ インジェスト API を使用して Azure Monitor ログにデータを送信する (Azure portal)」 を参照してください。

    4. Logstash 構成ファイルを更新するには、サンプル スクリプトを使用します。 この更新プログラムでは、ARM テンプレートによって作成されたカスタム テーブルに CEF ログを送信するように Logstash を構成し、JSON データを DCR 形式に変換します。 このスクリプトでは、プレースホルダーの値を、以前に作成したカスタム テーブルと Microsoft Entra アプリの独自の値に置き換えてください。

  2. CEF データが Logstash から想定どおりに流れているかどうかを確認します。 たとえば、Microsoft Sentinel で [ログ] ページに移動し、次のクエリを実行します。

    CefAux_CL
    | take 10
    
  3. CEF データを集計する集計ルールを作成します。 次に例を示します。

    • 懸念事項の検索インシデント (IoC) データ: 集計済みの集計クエリを実行して特定の IoC を検索し、一意の出現を取り込んでからそれらの出現箇所のみをクエリして、より高速な結果を得ます。 次の例は、一意の Source Ip フィードを他のメタデータと共に取り込んでから IoC 検索に対して使用する方法の例を示しています。

      // Daily Network traffic trend Per Destination IP along with Data transfer stats 
      // Frequency - Daily - Maintain 30 day or 60 Day History. 
        Custom_CommonSecurityLog 
        | extend Day = format_datetime(TimeGenerated, "yyyy-MM-dd") 
        | summarize Count= count(), DistinctSourceIps = dcount(SourceIP), NoofByesTransferred = sum(SentBytes), NoofBytesReceived = sum(ReceivedBytes)  
        by Day,DestinationIp, DeviceVendor 
      
    • 異常検出に対して集計ベースラインのクエリを実行します。 30 日や 60 日などの長期にわたる履歴期間に対してクエリを実行する代わりに、カスタム ログにデータを取り込み、時系列の異常検出など、集計ベースラインのデータのみをクエリすることをお勧めします。 次に例を示します。

      // Time series data for Firewall traffic logs 
      let starttime = 14d; 
      let endtime = 1d; 
      let timeframe = 1h; 
      let TimeSeriesData =  
      Custom_CommonSecurityLog 
        | where TimeGenerated between (startofday(ago(starttime))..startofday(ago(endtime))) 
        | where isnotempty(DestinationIP) and isnotempty(SourceIP) 
        | where ipv4_is_private(DestinationIP) == false 
        | project TimeGenerated, SentBytes, DeviceVendor 
        | make-series TotalBytesSent=sum(SentBytes) on TimeGenerated from startofday(ago(starttime)) to startofday(ago(endtime)) step timeframe by DeviceVendor