複合検出の概要

以下でサポートされています。

Google SecOps SIEM

このドキュメントでは、複合検出と、複数のルールからの出力を関連付けることで脅威検出ワークフローを強化する方法について説明します。

複合検出は、他のルールの検出を入力として使用するルールによって生成されます。このルールは、イベント、指標、エンティティ リスク シグナルと組み合わされます。これらのルールは、イベント、指標、エンティティのリスクシグナルと組み合わされ、個々のルールでは検出できない複雑な多段階の脅威を検出します。

複合検出は、定義されたルールの相互作用とトリガーを通じてイベントを分析するのに役立ちます。これにより、精度が向上し、誤検出が減り、さまざまなソースや攻撃ステージのデータを関連付けることで、セキュリティ脅威の包括的なビューが提供されます。

次のコンセプトは、複合ルールの構成要素を定義し、検出ワークフロー内での機能について説明します。

• 複合ルール: 検出またはアラート（あるいはその両方）を入力として使用します。必要に応じて、イベント、指標、エンティティ グラフの幅広いコンテキスト データ（普及率データ、脅威インテリジェンス、エンティティ リスクスコアなど）で拡充します。これらのルールには常に一致セクションが必要であり、入力ルールからメタ フィールド、match 変数、outcome 変数を参照できます。

• 検出: ルールの条件が満たされたときに生成される出力。

• 検出のみのルール: 検出またはアラートのみを入力として使用する複合ルール。

複合検出を使用する場面

複合検出は、次の目標を達成するうえで役立ちます。

• 2 つ以上のルールの結果を関連付ける（たとえば、マルウェアのダウンロード検出を、同じホストからの後続の C2 ビーコン アラートにリンクする）。

• 関連するイベントデータを使用してアラートを拡充する。

• ノイズが多く信頼性の低い検出が複数回発生した場合や、他の不審なアクティビティと組み合わせて発生した場合にのみ最終アラートをトリガーすることで、アラート疲れを軽減します。

• 各ステージが独自のルールで識別されている、複雑な多段階攻撃のアラートを作成する。

複合検出のメリット

複合検出には次の利点があります。

• 多段階攻撃を明らかにする: サイバー攻撃は多くの場合、多面的で相互に関連しています。複合検出では、一見独立しているセキュリティ イベントをリンクすることで、より広範な攻撃のストーリーを明らかにします。たとえば、複合検出では、最初の侵害に続いて権限昇格とデータ漏洩が発生するなど、攻撃シーケンス全体を特定できます。

• アラート疲れを軽減する: 複合ルールは、ノイズの多いアラートを統合してフィルタリングし、より焦点を絞った対応を可能にします。このアプローチは、影響の大きいインシデントを優先し、全体的なアラート疲れを軽減するのに役立ちます。

• 検出精度の向上: 統合データモデル（UDM）イベント、ルール検出、エンティティ コンテキスト、ユーザーとエンティティの行動分析（UEBA）の検出結果、データテーブルの分析情報を組み合わせて、より正確な検出ロジックを構築します。

• 複雑なロジックを合理化する: 複雑な検出シナリオを、管理可能で相互接続された再利用可能なルールに分割して、開発とメンテナンスを簡素化します。

• ダッシュボードで使用する: 複合検出を Google SecOps ダッシュボードのデータソースとしてシームレスに統合します。これらを使用して、多段階の攻撃パターンを要約する可視化を作成し、複雑なリスクを簡単に把握できます。

一般的なユースケース

このセクションでは、複合検出の一般的なユースケースをいくつか紹介します。

未加工イベントのコンテキストで検出を拡充する

このユースケースでは、あるシステムからの高レベルのアラートを別のシステムのイベントログにリンクします。

• 目標: 高レベルのアラートの原因となった特定のローカル アクションを特定する。

• 例:

  1. ワークロードが悪意のあるドメインに DNS 呼び出しを行ったため、 Google Cloud Event Threat Detection でアラートがトリガーされます。これが検出です。

  2. この検出によって複合ルールがトリガーされます。

  3. 次に、このルールは、同じワークロードから 1 分以内に未加工のエンドポイント検出と対応（EDR）ログ（イベント）を検索し、同じ悪意のあるドメインを含むコマンドライン オペレーションを探します。

  最終的なアラートには、悪意のあるドメインに接続されたことと、使用された特定の ssh コマンドが示され、豊富なコンテキストが提供されます。この情報により、元の検出よりもはるかに実用的な結果が得られます。

ログイン後のユーザー アクティビティを追跡する

ユーザーのログイン イベントと、その後の不審なアクティビティをリンクすることに重点を置いた主なユースケース。標準のマルチイベント ルールでは短いシーケンスを追跡できますが、複合検出は、ユーザーのセッション全体の包括的なリスク プロファイルの構築に適しています。

• 目標: 高リスクのログインなどの単一のイベントを、1 日などの長期間にわたる幅広い「弱いシグナル」アクティビティと関連付けます。

• 例: 低レベルの検出を生成する複数のルールを作成します。次に、長い一致ウィンドウ（24 時間など）を持つ複合ルールを使用して、最初の不審なログインをトリガーし、同じユーザーからの次の検出のいずれかと関連付けます。

  • ユーザーがコマンドライン履歴を消去している。

  • 新しいローカル管理者アカウントの作成。

  • 個人の Cloud Storage サイトへの大量のデータ アップロード。

UEBA 指標と組み合わせる

このユースケースでは、既存の UEBA 指標を複合検出の出発点として活用し、より複雑で長期的な動作を検出します。

• 目標: UEBA 指標の急増を別の異常なアクティビティと関連付ける。

• 例:

  1. UEBA ルールが、ユーザーのログイン失敗回数が過剰であることを検出します。

  2. 別の UEBA ルールでは、同じユーザーからの大量の下り（外向き）バイトが検出されます。

  3. 複合検出では、これら 2 つの個別の UEBA の検出結果を数日間にわたってリンクし、アカウントの侵害の可能性と、それに続くデータ窃盗を特定します。

データの引き出しの試みを検出する

これには、複数の異なるユーザー アクションを関連付けることが含まれます。これらのアクションを組み合わせると、データの引き出しを試みていることを示す可能性があります。

• 目標: 複数のデバイスとアクションにわたる単一ユーザーによるリスクの高いデータ処理のプロファイルを構築する。

• 関連するアクション:

  • 複数のデバイス（自宅のパソコンと職場のパソコンなど）からログインしている。

  • 通常よりも多くのデータソースにアクセスしている。

  • データのダウンロード、印刷、メール送信を同時に行う。

  • ユーザーが一定期間内にアクセスした機密ドキュメントの数をカウントする。

  • 退職届を提出している。

多段階マルウェアを検出する

このユースケースでは、長期間にわたってゆっくりと動作するマルウェアを特定します。これは、一致ウィンドウが短い単一のルールでは検出が困難です。

• 目標: 初期感染ベクトルと、その後の悪意のあるアクションを、数時間または数日離れていても関連付ける。

• 例:

  1. ユーザーが不正なウェブサイトにアクセスする（最初のネットワーク イベント）。

  2. 「ドロッパー ファイル」がダウンロードされ、実行されます（最初のプロセス イベント）。

  3. かなり後になって、ドロッパー ファイルが別の実行可能ファイルをダウンロードして実行します（2 番目のプロセス イベント）。

  これには、親プロセスと子プロセスを接続するための長い match ウィンドウが必要です。これは、複合検出で提供できます。

アラートノイズを低減する

このユースケースでは、単独では「ノイズ」が多すぎる、または誤検出が多すぎる検出を管理します。

• 目標: ルールを無効にしたり、複雑な除外を作成したりせずに、ノイズの多いルールを調整します。

• 例:

  1. ノイズの多いキュレーテッド検出を「検出のみ」に設定して、アラートが生成されないようにします。

  2. そのキュレートされたルールの出力を最初の条件として使用する複合検出を作成します。

  3. 2 つ目の条件を追加して、追加の条件を指定します。たとえば、「この検出が 1 時間に同じユーザーに対して 5 回発生した場合にのみアラートを生成する」や、別のルールからの検出と組み合わせる場合などです。

複合検出の仕組み

ルールが事前定義された条件を満たすと、検出が生成されます。これらの検出には、特定のデータまたはイベントの状態をキャプチャする結果変数を含めることもできます。

複合ルールは、他のルールからの検出を入力の一部として使用します。評価は、元のルールのメタ セクション、結果変数、一致変数の情報に基づいて行うことができます。

この評価に基づいて、複合ルールを使用して新しい検出を作成し、調査の中間表現として使用したり、後続のルールでアラートを生成したりできます。これにより、さまざまな検出結果から複数の要素を関連付けて、複雑な脅威を特定できます。

構文と例の詳細については、複合検出ルールと例をご覧ください。

戦略を定義する

複合ルールの作成を開始する前に、新しいルールが効果的かつ効率的で、適切な問題を解決できるように、戦略を計画します。

1. 現在の検出戦略を評価する。既存のルールを確認して、ノイズが多すぎるルール、誤検出が多いルール、複雑すぎて管理が難しいルールを特定します。

2. 複合ルールが価値を提供できる特定のシナリオを特定する。これには、多段階攻撃の検出、複数の信頼度の低いアラートを 1 つの信頼度の高いアラートに関連付けること、他のデータソースからの追加のコンテキストで検出を拡充することが含まれます。

3. 評価に基づいて実装計画を作成する。調整が必要なノイズの多いルール、簡素化が必要な複雑なルール、優先度を上げる必要がある新しい多段階検出を決定します。

この定義済みの計画は、ターゲットを絞った効果的な複合ルールを作成するためのロードマップとなります。技術的な制約を管理しながら、複合検出を最大限に活用するための大まかな戦略を検討します。

適切な方法を選択する

複合検出を構築する前に、他の代替手段で必要な結果を達成できるかどうか。既存の UEBA 検出で複雑なパターンを特定できるかどうかを分析します。検出を過度に複雑にすると、メンテナンスのオーバーヘッドが増加し、ルール割り当てが消費される可能性があります。

• 複合検出を使用する場合: 2 つ以上の異なる既存のルールの最終結果を関連付けることが目的の場合。これにより、概念的に分離された攻撃のステージが接続されます。

  例: マルウェア ダウンロード ルールからの検出と、その後の C2 ビーコン検出ルールからの検出を関連付ける。

• 既存の UEBA 検出を使用する場合: ユーザーまたはデバイスが通常のアクティビティ パターンを破ったタイミングを検出する場合。

  例: 通常は 1 GB のデータをダウンロードするユーザーが、100 GB のデータをダウンロードしたことを自動的に検出します。

ルール割り当てとリスク スコアリングを管理する

組織のリソースを管理するには、さまざまなルールタイプがルール割り当てにどのように影響するかを理解します。

• キュレートされたルールは、カスタムルールの割り当てにカウントされません。

• 複合ルールとカスタム マルチイベント ルールは割り当てにカウントされます。

キュレーテッド検出を検出のみに設定して使用できます。これにより、キュレーテッド ルールはアラートを生成せずに最初の広範な検出を実行できます。その後、複合ルールを使用して、これらの検出結果に特定のロジックを適用し、割り当てを戦略的に管理しながら、より多くの価値を提供できます。

リスクとコンテキストの違いを理解する

検出ロジックを設計する際は、リスクを評価するルールとコンテキストを提供するルールを区別します。

リスクは、一連のアクティビティの危険性を評価するものです。リスクを対象とするルールでは、多くの場合、複数のコンテキスト イベントまたは検出を集計して判断します。たとえば、1 回のログイン失敗はコンテキストを提供しますが、多数のログイン失敗はブルート フォース攻撃のリスクを示します。

コンテキストとは、イベントを取り巻く事実の詳細を指します。コンテキスト用に設計されたルールは、1 つのイベントを別のイベントの詳細で拡充します。たとえば、ルールでユーザーのログイン成功を検出できる一方、コンテキスト ルールでは、このログインが新しい国や通常とは異なる国から行われたという重要なコンテキストが提供されます。

例: 最初の検出で、悪意のあるドメインへの DNS 呼び出しなどの潜在的なリスクをアラートで通知できます。次に、複合ルールがそのアラートを Google SecOps のイベントログと関連付け、呼び出しを開始した特定のコマンドライン プロセスを特定します。これにより、高レベルのリスクアラートに、重要な実用的なコンテキストが追加されます。

長いマッチ ウィンドウを戦略的に使用する

長い一致ウィンドウ（14 日など）で構成された複合ルールは、実行頻度が低くなります。レイテンシが高いため、時間制約のあるアラートには適していません。これらの長い期間の時間枠は、長期間にわたる、ゆっくりとした、持続的な敵対的アクティビティを検出するために使用することを検討してください。

可視化に検出を使用する

ノイズの多いルールを管理する戦略の 1 つは、その出力をダッシュボードの可視化に変換することです。このアプローチでは、ルール割り当てを消費せず、大量の低忠実度データを価値ある分析情報に変換できます。

検出のみを行うルールを設定し、その検出結果をダッシュボード ウィジェットにプロットすることで、個々のアラートに圧倒されることなく、傾向を追跡し、外れ値を特定して、アクティビティの概要を監査できます。

例: PII データの処理を追跡する

ルールは、ユーザーが機密性の高い PII データを処理するたびに追跡します。毎回アラートを出すのではなく、検出のみに設定されています。ダッシュボード ウィジェットには、1 日の下り（外向き）上限（10,000 バイトなど）に近づいているユーザーが表示されます。これにより、アラートを継続的に生成することなく、リスクの高い動作を迅速に監査できます。

例: 特定の DLP リスクをモニタリングする:

ウィジェットは、DLP ルールの特定のサブセットからリスクスコアを集計します。これにより、特定のチーム（データ損失防止（DLP）管理者など）は、関連するリスクのみをモニタリングし、他のセキュリティ ドメインからのノイズをフィルタリングできます。

複合検出を構築する

次のワークフローは、複合ルールを作成するための一般的な手順を示しています。構文と例の詳細については、複合検出ルールと例をご覧ください。

1. 脅威シナリオを定義する: 検出する特定の脅威を定義します。

2. 入力ルールを作成または特定する: 脅威シナリオの各ステージで、特定のアクティビティを検出する入力ルールを作成または特定します。

3. 結合条件を定義する: ルールラベル、変数、検出フィールドなど、入力ルールの検出をリンクする共通の情報を決定します。

4. 複合ルールを作成する: 入力ルールから検出を取り込むルールを作成します。

   • events セクションを定義し、名前、ID、または共有メタラベルで入力ルールを参照します。

   • match セクションを定義して、結合キーと一致の期間を指定します。

   • condition セクションを定義して、最終的なアラートをトリガーするために満たす必要がある条件を設定します。

5. ルールチェーンをテストしてデプロイする: シーケンス内の各ルールに対してレトロハントを手動で実行することをおすすめします。

   複合ルールでテストルール機能を使用すると、ルールの入力条件に一致する既存の検出に対してのみ実行されます。基盤となるルールを自動的に実行してテスト用の新しい入力を生成することはないため、1 回のアクションでルールチェーン全体を検証することはできません。

   ルール シーケンスに対してレトロハントを実行するには、次の操作を行います。

   1. シーケンスの最初のルールからレトロハントを手動で開始します。

   2. 完了するまで待ってください。

   3. 次のルールに進みます。

   ヒント: テスト時に以前の検出結果と誤って一致しないようにするには、複合チェーン内の各ルールに一意の meta: label を追加することを検討してください。

例: 次のルールは、基本的なルール相関テンプレートを示しています。

rule Basic_Rule_Correlation_Template {
    
    meta:
    description = "Triggers when a user triggers two different rules within X days"

    events: 
    // 1. Identify the first sub-rule detection
    $d1.metadata.event_type = "DETECTION" $d1.metadata.rule_name = "INSERT_RULE_NAME_A_HERE" $user = [REDACTED_GENERIC_ID]

    // 2. Identify the second sub-rule detection
    $d2.metadata.event_type = "DETECTION"
    $d2.metadata.rule_name = "INSERT_RULE_NAME_B_HERE"
    $user = [REDACTED_GENERIC_ID]
    match: 
    // 3. Connect the rules by the same user over the specified window
    $user over 14d
    condition: 
    // 4. Fire when both conditions have occurred
    $d1 and $d2
}

例: 次のルールは、イベント検出ルールとイベントグラフを使用してキュレーテッド検出をチェックします。また、いくつかの高度な YARA-L 関数と変数定義を使用します。

rule CheckCuratedDetection_with_EDR_and_EG {

  meta:
    author = "[e-mail]"

  events:

    $d.detection.detection.rule_name = /SCC: Custom Modules: Configurable Bad Domain/
    $d.detection.collection_elements.references.event.network.dns.questions.name = $domain
    $d.detection.collection_elements.references.event.principal.asset.hostname = $hostname

    $e.metadata.log_type = "LIMACHARLIE_EDR"
    $e.metadata.product_event_type = "NETWORK_CONNECTIONS"
    $domain = re.capture($e.principal.process.command_line, "\\s([a-zA-Z0-9.-]+\\.[a-zA-Z0-9.-]+)$")
    $hostname = re.capture($e.principal.hostname, "([^.]*)")

    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 5
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0

  match:
    $hostname over 1h

  outcome:
    $risk_score = 80
    $CL_target = array($domain)

  condition:
    $e and $d and $prevalence

}

複合検出結果を表示する

検出ページで複合検出結果を表示できます。[入力] 列にソースとして [検出] が表示され、[検出タイプ] 列に [アラート] ラベルと、その横に数字（Alert (3) など）が表示されている場合、アラートは複合検出です。

注: SIEM と SOAR の両方を使用している場合は、[Cases] タブで結果を表示することもできます。

複合検出を最適化する

複合ルールを作成する際は、次の方法をおすすめします。

レイテンシを最適化する

検出パイプラインのレイテンシを最小限に抑えるには、初期トリガーなど、可能な限り単一イベントルールを使用します。複合ルールは、検出結果を使用して、他のイベント、エンティティ、検出結果とのより複雑な相関関係を実行できるため、全体的なレイテンシを短縮できます。

効率的な方法を使用して検出を結合する

検出結果を結合するには、結果変数、メタラベル、一致変数を使用することをおすすめします。これらのメソッドは、イベント サンプルを使用するよりも確定的で信頼性の高い結果を提供します。メタラベルは、複合ルールがそのラベルを持つ検出をターゲットにできるようにルールを分類できるため、特に柔軟です。

たとえば、複数のルールが同じメタラベル tactic: exfiltration を共有している場合、戦術ラベルの値が exfiltration である検出をターゲットとする複合ルールを作成できます。

ヒント: 結果変数の数は 20 に制限されているため、結果変数の共通の分類（hostname、ip_address、user、file_bytes など）を確立して、幅広いルールで一貫して再利用することをおすすめします。詳細については、制限事項をご覧ください。

複合検出で結合変数に nocase を使用すると、次のセマンティック分析エラーが発生することがあります。

semantic analysis: match variable <variable_name> is not assigned to an event field.

複合検出では、最初の変数割り当て（$username = $fact1... など）で変数のプロパティを定義します。これには、nocase を使用する場合の大文字と小文字を区別しない設定も含まれます。同じ結合変数の後続の変数割り当て（$username = $fact2... など）に nocase を適用すると、コンパイラは競合する再定義または冗長な制約として解釈し、セマンティック エラーが発生します。

関数ライブラリを使用して検出を強化する

複合ルールの戦略的なポイントで YARA-L 関数ライブラリを使用すると、シグナルを増やし、より複雑なロジックを追加できます。

ルールの更新を管理する

1 つ以上の複合ルールで使用されているルールを更新すると、システムはルールの新しいバージョンを自動的に作成します。複合ルールは、新しいバージョンを自動的に使用します。更新されたルール シーケンス全体をテストして、意図した動作を確認することをおすすめします。

制限事項

注: すべての検出ルールの最大一致ウィンドウは 14 日間です。

複合検出を設計して実装する際は、次の制限事項を考慮してください。

• 除外: ルールの除外を複合ルールに直接適用しないでください。除外は、複合ルールにフィードされる基本的なルールに適用する必要があります。これは、ルールの除外は UDM フィールド（principal.user.userid など）に対して評価されますが、複合ルールは UDM フィールドではなく他の検出に基づいてトリガーされるためです。ルールの除外を複合ルールに直接適用すると、除外は一致せず、イベントは除外されません。

• SOAR ケースデータの可用性: 複合検出は、すべての SOAR ケースデータにアクセスできません。ステータス（$edetection.feedback_summary.status != "CLOSED" など）に基づいてケースをフィルタリングまたは除外しようとするルールロジックはサポートされていません。

• 複合ルール: Google SecOps は、複合ルールの最大深度 10 をサポートしています。深さは、基本ルールから最終的な複合ルールまでのルール数です。

• 検出専用ルール: 最大一致ウィンドウは 14 日間で、ルールあたりの 1 日の検出上限は 10,000 件です。

• 結果変数: 各ルールは最大 20 個の結果変数に制限されます。また、各繰り返し結果変数は 25 個の値に制限されます。

• イベント サンプル: ルール内のイベント変数ごとに 10 個のイベント サンプルのみが保存されます（$e1 に 10 個、$e2 に 10 個など）。

検出上限の詳細については、検出上限をご覧ください。

次のステップ

複合検出ルールの作成方法については、複合検出ルールと例をご覧ください。

さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。