コンテキストアウェア分析の概要

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

Google SecOpsSIEM

Google SecOps を使用すると、テレメトリー、エンティティコンテキスト、関係、脆弱性を Google SecOps アカウント内の単一の検出として表示できます。エンティティのコンテキストを利用することで、テレメトリーの動作パターンと、これらのパターンから影響を受けるエンティティのコンテキストを理解できます。

例:

ブルートフォースログインを試行しているアカウントの権限の表示。
送信ネットワークアクティビティの送信元でもある、アセットによってホストされるデータの重要度。

このコンテキストを使用すると、検出フィルタリング、ヒューリスティックなアラートの優先順位付け、トリアージ、調査を行うことができます。

セキュリティアナリストと検出エンジニアは通常、イベントテレメトリーの基本パターン（アウトバウンドネットワーク接続）に基づいて検出を作成します。これにより、アナリストが優先度を判断できる多数の検出が作成されます。アナリストは、アラートをトリガーした原因と脅威の重大度を理解しようとします。

コンテキストアウェア分析では、検出のオーサリングと実行のワークフローの早い段階で高度な拡張機能が組み込まれており、次の追加機能を使用できます。

関連するコンテキストを、人間のトリアージステージではなく、検出実行時のヒューリスティックなコンテキストリスクスコアリングで使用できるようにする
さまざまな IT セキュリティシステム（EDR コンソール、ファイアウォールまたはプロキシログ、CMDB と IAM のコンテキスト、脆弱性スキャンの結果）から取得した情報のトリアージと手動で結びつける作業に費やす時間を短縮する
アナリストや検出エンジニアが、企業にとってリスクがほとんど、あるいはまったくない脅威（サンドボックス環境でのマルウェアテスト、開発ネットワークのセンシティブデータやアクセスのない脆弱性や異常なアクティビティなど）を除外できる

Writing rules for context-aware analytics

検出エンジンのルールを使用すると、Google SecOps アカウントのエンティティコンテキストデータを検索できます。

エンティティコンテキストデータを検索するには、次のことを行います。

udm またはエンティティを使用して、ソースを指定します。

$eventname.[<source>].field1.field2 エンティティコンテキストの場合、<source> は「graph」です。UDM イベントの場合、<source> は「udm」です。省略した場合、<source> はデフォルトで udm になります。
エンティティデータを指定します。

$e1.graph.entity.hostname = "my-hostname"

$e1.graph.entity.relations.relationship = "OWNS"
UDM イベントデータを指定します。次のステートメントは同等です。

$e1.udm.principal.asset_id = "my_asset_id"

$e1.principal.asset_id = "my_asset_id"

エンティティコンテキストには、UDM イベントの場合と同じ種類のルールの多くを作成できます。たとえば次のようなルールを作成できます。

複数のイベントルール

注: すべてのマルチイベントルールで UDM イベントを使用する必要があります。UDM のみを使用するルールを作成することも、UDM とエンティティの両方を使用するルールを作成することもできます。エンティティのみを使用するルールは作成できません。
エンティティコンテキストと他のエンティティコンテキストの比較
エンティティコンテキストと UDM イベントの比較
エンティティコンテキスト内の繰り返しフィールド
スライディング　ウィンドウ
検出のリスクスコアの計算

注: スライディングウィンドウのピボットとして、エンティティコンテキストを使用することはできません。

UDM イベントとは異なり、エンティティコンテキストには特定のタイムスタンプがありません。各エンティティコンテキストレコードには、エンティティコンテキストが有効な期間（entity.metadata.interval）があります。この時間間隔は日境界ではなく、任意の期間に設定できます。

UDM イベントは、UDM イベントのタイムスタンプがエンティティコンテキストレコードの時間枠内にある場合にのみ、エンティティコンテキストレコードと関連付けられます。この条件が満たされない場合、UDM とエンティティは検出のために評価されません。これは検出エンジンによって暗黙的に強制されるため、ルールの条件として指定する必要はありません。

ウィンドウ処理を使用して UDM イベントをエンティティコンテキストと比較する場合、エンティティコンテキストは指定された時間枠に対する定数値を表します。
エンティティコンテキストによって値が変更される隣接する日単位のバケットが存在する場合、Google SecOps は、エンティティのコンテキスト値をすべて照合して、見つかった場合はすべての一致を返すことを試行します。

ルールの例

管理者コンテキストでエンティティを検索する

次のルールは、管理者権限にも関連付けられているエンティティを検索します。管理者権限を持つユーザーがシステムに対してログインまたはログアウトを試行した時刻を検索します。

rule LoginLogout {
  meta:
  events:
    ($log_inout.metadata.event_type = "USER_LOGIN" or  $log_inout.metadata.event_type = "USER_LOGOUT")
    $log_inout.principal.user.user_display_name = $user

    $context.graph.entity.user.user_display_name = $user
    $context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"

  match:
    $user over 2m

  condition:
    $log_inout and $context
}

スライディングウィンドウの例

次のスライディングウィンドウの例は有効です。

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Using e2 (a UDM event) as a pivot.
    $host over 3h after $e2

  condition:
    $e1 and $e2
}

無効なスライディングウィンドウの例

次のスライディングウィンドウの例は無効です。エンティティコンテキストは、スライディングウィンドウのピボットとして使用できません。

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Attempting to use $e1 (an entity context) as a pivot. Invalid.
    $host over 3h after $e1

  condition:
    $e1 and $e2
}

結果セクションを使用したログインの例

次の例では、outcome セクションを使用して検出のリスクスコアを計算しています。

rule Detection {
  meta:
  events:
    $auth.metadata.event_type = "USER_LOGIN"
    $auth.metadata.vendor_name = "Acme"
    $auth.metadata.product_name = "Acme SSO"
    $auth.target.user.userid = $user
    $auth.metadata.event_timestamp.seconds >
       $context.graph.entity.user.termination_date.seconds

    $context.graph.metadata.vendor_name = "Microsoft"
    $context.graph.metadata.product_name = "Azure Active Directory"
    $context.graph.metadata.entity_type = "USER"
    $context.graph.entity.user.userid = $user
    $context.graph.entity.user.termination_date.seconds > 0

  match:
    $user over 15m

  outcome:
    $risk_score = max(
        if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
        if (
            $context.graph.entity.user.title = "Remote" nocase or
            $context.graph.entity.user.title = "Temp" nocase or
            $context.graph.entity.user.title = "Vendor" nocase, 40) +
        if ( $context.graph.entity.user.title = "Legal" nocase, 10)
    )

  condition:
    $auth and $context
}

不審なプロセスの起動の例

次の例では、エンティティコンテキストとして格納された IOC コンテキストデータに対して UDM イベントプロセスデータを評価しています。

rule ProcessLaunch {
  meta:
  events:
    $ioc.graph.metadata.vendor_name = "ACME"
    $ioc.graph.metadata.product_name = "IOCs"
    $ioc.graph.metadata.entity_type = "FILE"
    $ioc.graph.entity.file.sha256 = $hash

    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.principal.hostname = $hostname
    (
        not $process.target.process.file.sha256 = "" and
        $process.target.process.file.sha256 = $hash
    )

  match:
    $hash over 15m

  condition:
    $ioc and $process
}

エンティティコンテキストの追加修飾子

エンティティコンテキストを使用するイベント変数を作成するには、イベント名の後に <source> を指定する必要があります。<source> は graph とする必要があります。

次のパターンはエンティティコンテキストを参照しています。

$e.graph.entity.hostname

UDM イベントを参照する同等の方法として、以下の 2 つがあります。

$u.udm.principal.asset_id
$u.principal.asset_id

これらの修飾子はすべて、ルールテキスト内で組み合わせて使用できます。同じイベントに異なる修飾子を使用することもできます。

結果セクション

検出エンジンは、ルールから詳細情報を導出できる outcome セクションをサポートしています。outcome セクションで定義されたロジックは、各検出に対して評価されます。ルールで N 個の検出結果を生成すると、N 個の検出のそれぞれが異なる結果に場合があります。

outcome セクションを使用するルールの例については、結果の選択を含むルールをご覧ください。

outcome セクションの詳細な使用法と構文については、結果セクションをご覧ください。

結果セクションと検出結果の重複除去 / 検出結果のグループ化

一致セクションがあるルールの場合は、別の箇所で説明したように検出結果は一致変数によって「グループ化」されます。これによって、一連の個別の一致変数と時間枠ごとに 1 つの行が返されるように、検出結果の重複が除去されます。

この重複除去では結果の変数は無視されます。したがって、一致変数と時間枠の値が同じ 2 つの異なる検出結果があり、結果変数の値が異なる場合、重複は除外され、検出は 1 つだけ表示されます。これは、データの遅延が原因で検出が作成された場合に発生することがあります。以下に、このケースを説明する例を示します。

rule ExampleOutcomeRule {
  ...
  match:
    $hostname over <some window>
  outcome:
    $risk_score = <some logic here>
  ...
}

このルールでの一致結果は次のとおりです。

検出 1: ホスト名: test-hostname 時間枠: [t1, t2] risk_score: 10

検出 2: ホスト名: test-hostname 時間枠: [t1, t2] risk_score: 73

一致変数と時間枠は検出 1 と検出 2 で同じであるため、重複が除去され、結果変数（risk_score）は異なっていても、1 つの検出結果のみが表示されます。

次のステップ

Google SecOps でコンテキストデータを取り込み、エンティティを強化する方法については、Google SecOps でイベントとエンティティデータを強化する方法をご覧ください。

さらにサポートが必要な場合 コミュニティメンバーや Google SecOps の専門家から回答を得る。