複合検出の概要

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

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

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

複合検出は、定義されたルールのインタラクションとトリガーを通じてイベントを分析するのに役立ちます。これにより、精度が向上し、誤検出が減り、さまざまなソースと攻撃段階のデータを関連付けることで、セキュリティの脅威を包括的に把握できます。

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

  • 複合ルール: 検出またはアラート（あるいはその両方）を入力として使用します。必要に応じて、エンティティ グラフのイベント、指標、幅広いコンテキスト データ（普及データ、脅威インテリジェンス、エンティティ リスクスコアなど）で拡充します。これらのルールには常に一致セクションが必要であり、入力ルールのメタフィールド、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 回のログイン失敗はコンテキストを提供しますが、ログイン失敗回数が多い場合はブルート フォース攻撃のリスクを示します。

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

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

長い一致時間枠を戦略的に使用する

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

可視化に検出を使用する

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

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

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

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

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

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

複合検出を構築する

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

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

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

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

  4. 複合ルールを構築する: 入力ルールから検出を取り込むルールを記述します。

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

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

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

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

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

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

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

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

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

例:


rule CheckCuratedDetection_with_EDR_and_EG {

  meta:
    author = "noone@cymbal.com"

  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 の両方がある場合は、結果を確認することもできます。[**ケース**] タブで。

複合検出を最適化する

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

レイテンシを最適化する

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

効率的な方法で検出を結合する

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

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

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

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

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

関数ライブラリで検出を強化する

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

ルールの更新を管理する

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

制限事項

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

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

  • 複合ルール: Google SecOps では、複合ルールの最大深度は 10 です。深度とは、ベースルールから最終的な複合ルールまでのルールの数です。

  • 検出のみのルール: 最大一致時間枠は 14 日間で、 1 ルールあたりの 1 日の検出上限は 10,000 件です。

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

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

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

次のステップ

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

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