このページは Cloud Translation API によって翻訳されました。

複合検出

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

Google SecOps SIEM

複合検出では、ルールの出力を別のルールの入力として使用できるように、ルールを相互接続できます。この機能を使用すると、より複雑で柔軟なルールを作成できます。複合検出では、さまざまなデータソースと期間にわたってイベントを関連付けて分析することで、個別のイベント検出の制限を克服します。

複合検出のメリット

多段階攻撃の検出: サイバー攻撃は多面的で相互に関連していることがよくあります。複合検出は、一見独立しているインシデントを関連付けることで、攻撃の全体像を把握するのに役立ちます。たとえば、複合ルールを使用すると、最初の侵害に続いて権限昇格とデータ漏洩が発生するなど、攻撃シーケンス全体を特定できます。
アラート疲れを軽減する: 消費者ルールを実装して、重大な脅威を優先し、アラート疲れを軽減します。これらのルールは、入力ルールによって生成されたノイズの多いアラートを統合してフィルタリングし、より的を絞った対応を可能にします。これにより、影響の大きいインシデントの優先順位付けや、アラート疲労の軽減に役立ちます。
検出精度の向上: UDM イベント、他のルール検出、エンティティ情報、UEBA の検出結果、データテーブルの分析情報を組み合わせて、正確な検出ロジックを作成します。
複雑なロジックの効率化: 複雑な検出シナリオを管理可能で相互接続された再利用可能なルールに分割し、開発と保守を効率化します。

複合検出の用語とコンセプト

検出: ルールの結果。アラートとも呼ばれます。
複合: 相互接続された一連のルール。1 つのルールの出力が次のルールの入力として機能します。たとえば、複合ルールシーケンス rule1 -> rule2 -> rule3 では、rule1 によって生成された検出が rule2 に渡され、処理されて新しい検出が生成されます。これらの検出結果は rule3 によって使用され、最終的な出力が生成されます。
入力ルール: 検出結果が別のルールの入力として使用されるルール。どのルールも入力ルールとして機能できます。特別な指定は必要ありません。入力ルールは、エンティティとイベントを入力として使用します。検出をインプットとして使用しません。
複合ルール: ルールテキストで検出を入力として使用するルール。複合ルールには match セクションが必要です。

高度なコンセプト

単一イベント検出ルール

Google SecOps では、単一イベントの複合ルールは許可されていません。つまり、検出を入力ソースとして使用するルールには、match セクションが必要です。

検出のレイテンシ

スケジューリングの動作により、複合ルールは単一イベントの入力ルールでのみ作成することをおすすめします。単一イベントルールはほぼリアルタイムで実行されるため、通常、複合ルールが実行されるまでに検出結果が利用可能になります。複合ルールが入力としてマルチイベントルールに依存している場合、入力ルールが複合ルールのスケジュールされた実行後に実行される可能性があります。これにより、複合ルールの遅延や検出漏れが発生する可能性があります。

TestRule と Retrohunt

複合ルールで RetroHunt をテストまたは実行すると、既存の検出を使用して選択した特定のルールのみが実行されます。複合全体を実行するには、シーケンスの最初のルールから手動で遡及検索を開始し、各実行が完了するのを待ってから、次のルールに進む必要があります。

ルールでテストを実行しても、検出結果はデータベースに保存または書き込まれません。複合ルールでは、入力検出結果がデータベースに存在する必要があります。

ルールでテストを実行しても、検出はデータベースに保存または書き込まれません。複合ルールは、機能するためにデータベースに入力検出が存在することを必要とするため、TestRule を使用して複合ルールを検証することはできません。

複合ルールを作成する

複合ルールは、入力ルールと複合ルールの組み合わせを使用して作成します。

入力ルール

入力ルールは複合ルールの基盤となります。これらのルールは、特定のイベントや条件を検出し、それらを組み合わせることで悪意のあるアクティビティを特定します。入力ルールを構成するには、次の操作を行います。

新しいルールを作成するか、既存のルールを再利用します。
アラートを無効にします。これにより、これらの入力ルールが個別のアラートを生成することがなくなります。この構成を使用すると、イベントチェーン全体を評価する複合ルールによって生成されたより重要なアラートに優先順位を付けることができます。
outcome セクションを使用して、チェーンルールからアクセスできる変数を定義します。

次のプロデューサールールの例は、ログインの失敗を検出します。

rule failed_login {
  meta:

  events:
    $e.metadata.event_type = "USER_LOGIN"
    any $e.security_result.action = "BLOCK"

  outcome:
   $target_user = $e.target.user.userid

  condition:
    $e
}

このルールは、ブロックされたログインを特定し、関連するユーザーを提供します。

複合ルール

検出を使用するルールの作成は、ソースと使用可能なフィールドが異なる点を除き、UDM を使用するルールとほぼ同じです。検出フィールドを参照するには、ソースとしてキーワード detection を使用します（$eventname.detection.field1.field2）。

detection ソースで使用可能なサブフィールドは、コレクションリソースで確認できます。

コレクションの一般的なフィールドは次のとおりです。

$d.detection.detection.rule_id
$d.detection.detection.detection_fields["match_var_name"]
$d.detection.detection.outcomes["outcome_name"]

次のルール例は、MFA なしのログイン、列挙、引き出しを検出します。

rule login_enumeration_exfiltration {
    meta:
description = "Detects when a user logs in without multifactor authentication (MFA) and then performs enumeration and exfiltration"
        rule_name = "Login Without MFA, Enumeration, Exfiltration"
        severity = "High"

    events:
     // Detection with name "Console Login Without MFA"
        // The affected user is saved as $target_user
        $login_without_mfa.detection.detection.rule_name = /Console Login Without MFA/
        $target_user = $login_without_mfa.detection.detection.outcomes["target_user"]

     // Any detection with a rule name containing 'enumeration'
     // The user performing enumeration is the user that logged in without mfa
        $enumeration.detection.detection.rule_name = /enumeration/ nocase
        $enumeration.detection.detection.outcomes["principal_users"] = $target_user

     // Any detection with the mitre tactic 'TA0010' (Exfiltration)
     // The user performing exfiltration is the user that logged in without mfa
        $exfiltration.detection.detection.rule_labels["tactic"] = "TA0010"
        $exfiltration.detection.detection.outcomes["principal_users"] = $target_user

    match:
     // Looks for detections over a 24 hour period
        $target_user over 24h

    condition:
     // All 3 must occur for a single user
        $login_without_mfa and $enumeration and $exfiltration
}

階層検出

複合検出を使用すると、階層型検出システムを作成できます。下位レベルの入力ルールは、孤立した不審なイベントを特定します。上位レベルの複合ルールは、これらの入力ルールの出力を消費して、時間、エンティティ、データソースを関連付けます。このアプローチは、この情報を他のソースのデータと関連付けて、単一イベントルールでは検出できないマルチステージ攻撃パターンを検出するのに役立ちます。

Google Security Operations は最大 3 レベルの構成をサポートしており、高度な検出ロジックと管理可能な複雑さのバランスを実現しています。

次に例を示します。

レベル 1: 入力ルールが個々の不審なイベントを検出します。たとえば、ログイン失敗イベントや異常なファイルアクセスなどです。
レベル 2: 複合ルールはレベル 1 の検出を関連付けます。たとえば、ログインに失敗した後に不審なファイルアクセスが発生した場合です。
レベル 3: より高度な複合ルールでは、レベル 2 の検出と他のデータを組み合わせて、さらに高度な検出を行います。たとえば、認証に関するレベル 2 検出と、使用しているデバイスのセキュリティポスチャーに関するレベル 2 検出などです。

複合ルールを作成する際の考慮事項

1 つ以上の複合ルールで使用されている入力ルールを更新すると、その入力ルールの新しいバージョンが自動的に作成されます。これは、ロジックの更新（condition、events、outcomes）とメタデータの更新（名前、説明、重大度）の両方に適用されます。複合ルールは、新しいバージョンを使用して引き続き動作します。更新された入力ルールとそのダウンストリームの複合ルールをテストして、意図した動作を確保することをおすすめします。

制限事項

複合ルールには次の制限があります。

検出のみのルールとエンティティリスクスコア

検出のみのルール（イベントデータやエンティティデータではなく、検出データのみをソースとして使用するルール）は、エンティティリスクスコアには影響しません。検出専用ルールに設定されたリスクスコアは、そのルールによって作成された検出にのみ適用されます。集計エンティティリスクスコアには影響しません。

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