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

ルールの連携

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

Google SecOpsSIEM

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

ルールのチェーン化のメリット:

マルチステージ攻撃の検出: サイバー攻撃は多くの場合相互に関連しています。ルールの連鎖は、一見孤立したインシデントの間のリンクを表示することで、攻撃のストーリーを明らかにするのに役立ちます。たとえば、ルールチェーンを使用すると、最初の侵害に続いて権限昇格とデータ漏洩が発生するなど、攻撃シーケンス全体を特定できます。
アラート疲れの軽減: コンシューマルールを実装して、重要な脅威を優先し、アラート疲れを軽減します。これらのルールは、プロデューサールールによって生成されたノイズの多いアラートを統合してフィルタし、より的を絞ったレスポンスを可能にします。
検出精度の向上: UDM イベント、他のルール検出、エンティティ情報、UEBA の検出結果、データテーブルの分析情報を組み合わせて、正確な検出ロジックを作成します。
複雑なロジックの効率化: 複雑な検出シナリオを、管理しやすく、相互接続され、再利用可能なルールに分割して、開発と保守を効率化します。

ルールチェーンの用語と概念:

検出: ルールの結果であり、アラートとも呼ばれます。
チェーン: 1 つのルールの出力が次のルールの入力として機能する一連のルールです。たとえば、ルール 1 -> ルール 2 -> ルール 3 のチェーンでは、ルール 1 によって生成された検出結果がルール 2 によって使用され、新しい検出結果が生成されます。この検出結果は、ルール 3 によって独自の検出セットの生成に使用されます。
プロデューサールール: 検出結果が別のルールへの入力として使用されるルールです。どのルールもプロデューサールールとして機能できます。特別な指定は必要ありません。プロデューサールールは、エンティティとイベントを入力として使用します。検出結果を入力として使用しません。
コンシューマルール: 検出結果をルールテキストの入力として使用するルールです。コンシューマルールには、一致セクションが必要です。
チェーンルール: コンシューマルールとも呼ばれます。

高度なコンセプト

単一イベント検出ルール

Google SecOps では、単一イベント検出ルールは使用できません。つまり、検出をデータソースとして使用するルールには、一致セクションが必要です。

検出のレイテンシ

スケジューリングに関する懸念があるため、コンシューマルールは単一イベントルールにのみ連結することをおすすめします。単一イベントルールは準リアルタイムで実行されるため、これらのルールによる検出は、コンシューマルールの最初の実行でほぼ確実に使用できます。マルチイベントルールを使用してルールチェーンを作成すると、プロデューサールールがコンシューマルールの後に実行され、コンシューマルールでの検出の生成が遅れる可能性があります。

TestRule と Retrohunt

コンシューマルールで RetroHunt をテストまたは実行すると、既存の検出を使用して選択した特定のルールのみが実行されます。チェーンをすべて実行するには、チェーンの先頭で RetroHunt を開始し、各実行が完了するまで待ってから次のルールを実行する必要があります。

ルールでテストを実行しても、検出結果が永続化またはデータベースに書き込まれることはありません。コンシューマルールでは、入力検出結果がデータベースに存在している必要があります。そのため、テストルールでルールの連鎖をテストすることはできません。

ルールチェーンを構築する

ルールチェーンは、プロデューサールールとコンシューマルールを組み合わせて作成します。

プロデューサーのルール

プロデューサールールは、チェーンの基盤となります。特定のイベントや条件を特定し、組み合わせることで悪意のあるアクティビティを検出します。プロデューサールールを構成する手順は次のとおりです。

新しいルールを作成するか、既存のルールを再利用します。
アラートを無効にして、結果セクションで $risk_score を 0 に設定します。これにより、これらのルールが個別のアラートを生成したり、エンティティのリスクスコアに影響したりすることがなくなります。この構成を使用すると、イベントチェーン全体を評価するコンシューマルールによって生成された、より重要なアラートに優先順位を付けることができます。
outcome セクションを使用して、チェーンルールでアクセス可能な変数を定義します。

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

rule failed_login {
  meta:

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

  outcome:
   $risk_score = 0
   $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 検出などです。

プロデューサールールを変更する際の考慮事項

ルールチェーンでプロデューサールールが更新されると、プロデューサールールの新しいバージョンが作成されます。これは、ロジックの更新（条件、イベント、結果）とメタデータの更新（名前、説明、重大度）の両方に適用されます。コンシューマルールは、新しいバージョンを使用して引き続き機能します。更新されたプロデューサールールとそのダウンストリームコンシューマルールをテストして、意図した動作を確認することが重要です。

制限事項

ルールの連携には次の制限があります。

検出専用ルールとエンティティリスクスコア

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

ケースビューでのルールチェーンのサポート

ケースビューでは複合アラートはサポートされていません。