複合検出の概要

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

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. 「同じユーザーに対して 1 時間に 5 回この検出が発生した場合のみアラートを送信する」や、別のルールの検出と組み合わされた場合など、追加の条件を追加します。

複合検出の仕組み

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

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

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

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

戦略を定義する

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

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

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

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

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

適切な方法を選択する

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

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

  例: Malware Downloaded ルールの検出と、C2 Beaconing Detected ルールの後続の検出を関連付けます。

• 既存の 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 のプロフェッショナルから回答を得ることができます。