Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

検索とダッシュボードで結合を適用する

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

Google SecOps SIEM

結合を使用すると、複数のソースからのデータを関連付けて、調査のコンテキストをより詳細に把握できます。関連するイベント、エンティティ、その他のデータをリンクすることで、複雑な攻撃シナリオを調査し、傾向を可視化できます。

このドキュメントでは、Google SecOps の検索フィールドとダッシュボードパネルで結合オペレーションを使用する方法について説明します。サポートされている結合タイプ、ユースケース、ベストプラクティスについて説明します。

結合の基本コンセプト

結合を作成するには、共有プレースホルダ変数または明示的な等式ステートメント（$e1.hostname = $e2.hostname など）を使用してデータソースを接続します。統計情報に基づくクエリの match セクションで結合を定義する場合は、プレースホルダ変数を使用する必要があります。

次の例は、等号（=）と共有プレースホルダ変数を使用して 2 つのフィールドでデータソースをリンクする方法を示しています。

例 1: プレースホルダ変数を使用した暗黙的な結合

events:
  // Assign a value from the first event to the placeholder variable $user
  $user = $e1.principal.user.userid

  // The second assignment creates an implicit join, linking $e2 to $e1
  // where the user ID is the same.
  $user = $e2.principal.user.userid

match:
  $user over 1h

condition:
  $e1 and $e2

例 2: 等式とプレースホルダを使用した明示的な結合

$e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"
$e1.principal.hostname = $host

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"
$e2.target.hostname = $host

match:
  $ip, $host over 5m

検索の結合

このセクションの例では、検索で使用される構文を示します。

検索のクエリでは、デフォルトで大文字と小文字が区別されません。

イベント間結合

イベント間結合は、2 つの異なるユニバーサルデータモデル（UDM）イベントを接続します。次のクエリ例では、USER_LOGIN イベントを別のイベントにリンクして、共通の IP アドレスに基づいてユーザーが操作したホスト名（altostrat）を検索します。
```
$e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"

match:
  $ip over 5m
```

Event-ECG 結合

イベントと ECG の結合は、UDM イベントをエンティティコンテキストグラフ（ECG）のエンティティに接続します。次のクエリの例では、1 時間のウィンドウ内で同じホスト名を共有するエンティティグラフから NETWORK_CONNECTION イベントと ASSET を検索します。
```
events:
  $e1.metadata.event_type = "NETWORK_CONNECTION"
  $g1.graph.metadata.entity_type = "ASSET"
  $e1.principal.asset.hostname = $g1.graph.entity.asset.hostname
  $x = $g1.graph.entity.asset.hostname

match:
  $x over 1h

condition:
  $e1 and $g1
```

Datatable-event join

データテーブルとイベントの結合により、UDM イベントがカスタムデータテーブルのエントリに接続されます。これは、既知の悪意のある IP アドレスや脅威アクターなど、ユーザー定義のリストに対してライブイベントデータを照合する場合に便利です。次のクエリの例では、NETWORK_CONNECTION イベントをデータテーブルと結合して、そのリストの特定の IP アドレスを含む接続を検索します。
```
$ip = %DATATABLE_NAME.COLUMN_NAME
$ip = $e1.principal.ip
$e1.metadata.event_type = "NETWORK_CONNECTION"

match:
  $ip over 1h
```

データテーブルで IN 句を使用する

in 句を使用して、フィールド値がデータテーブルの列に存在するかどうかを確認することもできます。この構文はすべてのデータソース（ioc.type in %abc.type など）でサポートされており、結合のプレースホルダ変数を明示的に定義することなく、参照リストに基づいてイベントをフィルタリングする便利な方法を提供します。

一般的なユースケース

このセクションでは、結合の一般的な使用方法をいくつか紹介します。

認証情報の盗難と使用を検出する

目標: ユーザーが正常にログインした後、重要なシステムファイルをすばやく削除したインスタンスを見つけます。これは、アカウントの乗っ取りや悪意のある内部関係者の活動を示している可能性があります。

結合タイプ: イベントとイベントの結合

説明: このクエリは、単独では疑わしくない 2 つの異なるイベントを接続しますが、同時に発生すると非常に疑わしくなります。まず USER_LOGIN イベントを探し、次に FILE_DELETION イベントを探します。これらは、短い時間枠で共通の user.userid によって結合されます。

認証情報の窃取を検出するクエリ

// Event 1: A user successfully logs in
$e1.metadata.event_type = "USER_LOGIN"
$e1.security_result.action = "ALLOW"
$e1.principal.user.userid = $user

// Event 2: The same user deletes a critical file
$e2.metadata.event_type = "FILE_DELETION"
$e2.target.file.full_path = /etc\/passwd|C:\\Windows\\System32\\/
$e2.principal.user.userid = $user

match:
  $user over 10m

condition:
  $e1 and $e2

重要なアセットからの危険な接続を特定する

目標: アセット情報でライブネットワークデータを拡充し、外部の低頻度ドメインと通信すべきでないサーバー（本番環境データベースサーバーなど）からのアウトバウンド接続を見つける。

結合タイプ: イベント ECG 結合

説明: 珍しいドメインへの単一のネットワーク接続は、優先度が高くない可能性があります。ただし、このクエリでは、エンティティコンテキストグラフ（ECG）と結合することで、そのイベントの重要度を高めています。具体的には、エンティティグラフで「Critical Database Server」とラベル付けされたアセットから発生した NETWORK_CONNECTION イベントを探します。

リスクの高い接続のクエリ

events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.target.domain.prevalence.day_count <= 5

  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.entity.asset.labels.value = "Critical Database Server"

  $e.principal.asset.hostname = $asset.graph.entity.asset.hostname
  $host = $e.principal.asset.hostname

match:
  $host over 1h

condition:
  $e and $asset

脅威アクターの IOC をハンティングする

目標: 特定の脅威アクターが使用していることがわかっているドメインのリストに対して、すべてのライブ DNS クエリをチェックすることで、侵害の指標（IoC）を積極的に検索します。

結合タイプ: Datatable-Event join

説明: 脅威インテリジェンスチームは、悪意のあるドメインを一覧表示する ThreatActor_Domains というデータテーブルを管理しています。このクエリは、すべてのリアルタイム NETWORK_DNS_QUERY イベントをこのデータテーブルに結合します。ネットワーク内のホストが脅威インテリジェンスリストからドメインを解決しようとしたインスタンスがすぐに表示されます。

脅威アクターの IOC 検索クエリ

// Datatable: Get the list of malicious domains
$domain = %DATATABLE_NAME.COLUMN_NAME

// Event: A DNS query is made
$e.metadata.event_type = "NETWORK_DNS"
$e.network.dns.questions.name = $domain

match:
  $domain over 5m

condition:
  $e

ダッシュボードの結合

ダッシュボードは、検索よりも幅広いデータソースと長い相関ウィンドウをサポートしています。標準 SQL クエリとは異なり、YARA-L 2.0 では明示的な JOIN ステートメントは使用されません。代わりに、共有プレースホルダ変数またはマルチステージクエリを関連付けてデータソースを接続します。

大文字と小文字の区別

ダッシュボードのクエリでは大文字と小文字が区別されます。ダッシュボードで大文字と小文字を区別しない結合または検索を行うには、nocase 修飾子を使用します。

サポートされるデータソース

ダッシュボードでは、サポートされているデータソースの結合の組み合わせからデータを結合できます。（データソースのすべての組み合わせを 1 つのクエリで結合できるわけではありません）。

マルチソースダッシュボードクエリのすべてのデータ参照には、結合されたフィールドだけでなく、YARA-L 接頭辞修飾子（$u1 など）を含める必要があります。これにより、システムは重複するデータソース間でフィールドの所有権を正しく特定できます。

サポートされている結合の組み合わせ

結合を使用すると、組み込みのダッシュボードで UDM イベント、エンティティコンテキスト、データテーブルを関連付けることができます。システムのパフォーマンスを維持するには、クエリを作成する前に、このセクションでサポートされている組み合わせと技術的な制限事項を確認してください。

UDM イベントから UDM イベント（マルチイベント）
UDM イベントからエンティティコンテキスト
UDM イベントからデータテーブルへ
ケースからケース履歴: この組み合わせは、case ソース 1 つと case_history ソース 1 つに厳密に制限されます。この結合に他のデータソースを含めることはできません。

注: SOAR ケースデータ（case または case_history）を SIEM UDM イベント、エンティティコンテキスト、データテーブルと関連付けるには、まずデータセットを BigQuery にエクスポートすることを検討してください。データがエクスポートされたら、BigQuery で標準 SQL クエリを使用するか、ビジネスインテリジェンスツールでクロスソースの可視化を構築できます。設定手順については、セルフマネージド BigQuery プロジェクトにエクスポートするをご覧ください。

上限とガードレールについては、技術的な上限と制約をご覧ください。

例: ケースと case_history を結合する

一意のケース ID で結合することで、ケースのメタデータを過去のアクティビティと関連付けることができます。

次の例では、case データソースと case_history データソースを結合して、優先度の高いケースごとに過去のアクションの総数をカウントします。

  // 1. Establish the Join using a shared placeholder variable ($case_id)
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Apply Filters
  $c.case.priority = "PRIORITY_HIGH"

  // 3. Group the correlated data by the Case ID
  match:
    $case_id

  // 4. Calculate the selected metrics to display on the dashboard
  outcome:
    $case_name = array_distinct($c.case.display_name)
    $total_historical_actions = count($h.case_history.case_activity)

高度なユースケース: MTTR の計算

平均解決時間（MTTR）や平均クローズ時間（MTTC）などの複雑な指標には、マルチステージクエリを使用できます。これにより、最初のステージの個々のケースの期間を計算し、最終結果ブロックでそれらの期間をグローバルに平均化できます。

次のクエリは、「Default Environment」のすべてのケースでケースをクローズするまでの平均時間（分単位）を計算します。

stage stage1 {
  // 1. Establish the Join
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Filter by specific environment
  $c.case.environment = "Default Environment"

  // 3. Group by Case ID to process per case
  match:
    $case_id

  // 4. Calculate the Time to Close (TTC) for each case individually
  outcome:
    $case_close_time = max(if($h.case_history.case_activity = "CLOSE_CASE", $h.case_history.event_time.seconds, 0))
    $status = array_distinct($h.case_history.case_activity)

    // Subtract the very first event time (creation) from the close time
    $TTC = $case_close_time - min($h.case_history.event_time.seconds)

  // 5. Filter to ensure the case has a complete lifecycle
  condition:
    arrays.contains($status, "CREATE_CASE") and
    arrays.contains($status, "CLOSE_CASE")
}

// 6. Global Aggregation: Calculate the Mean (Average) across all processed cases
outcome:
  $case_count = count($stage1.case_id)
  $MTTC = (math.round(avg($stage1.TTC) / 60))

ベストプラクティス

結合クエリのパフォーマンスを最適化し、効率的に処理するには、イベントのフィルタリングと検索範囲の管理に関する次のベストプラクティスに従ってください。

特定のフィルタを使用してイベントの数を減らす

結合クエリは、多くの結果を結合するため、リソースを大量に消費する可能性があります。

広範で一般的なフィルタを使用すると、クエリが失敗することがあります。たとえば、次のような場合です。
- target.ip != ""
- metadata.event_type = "NETWORK_CONNECTION"（このイベントタイプが環境内で非常に一般的な場合）
一般的なフィルタとより具体的なフィルタを組み合わせて、クエリで処理する必要があるイベントの総数を減らすことをおすすめします。target.ip != "" などの広範なフィルタは、クエリのパフォーマンスを向上させるために、より具体的なフィルタと組み合わせて使用する必要があります。例:
```
$e1.metadata.log_type = $log
$e1.metadata.event_type = "USER_LOGIN"
$e1.target.ip != ""

$e2.metadata.log_type = $log
$e2.principal.ip = "10.0.0.76"
$e2.target.hostname != "altostrat"

match:
$log over 5m
```

クエリがまだ遅い場合は、クエリの全体的な期間を短縮することもできます（たとえば、30 日から 1 週間に短縮します）。

詳細については、YARA-L のベストプラクティスをご覧ください。

技術的な制限と制約

検索とダッシュボードで結合を使用する場合は、次の制限事項と上限が適用されます。

ウィンドウとクエリの上限を一致させる

一致ウィンドウは、イベントを関連付ける特定の期間を定義します。これは、ユーザーインターフェースで選択する検索期間とは異なります。

検索の上限

検索は、短い期間でのライブ調査や迅速な調査に最適化されています。

クエリの上限	用途
最大 48 時間（クエリによっては、より長い期間がサポートされる場合があります）。	迅速な調査でイベントを関連付けます。

ダッシュボードの制限

ダッシュボードは、長期的な履歴分析をサポートしています。

結合タイプ	クエリの上限	用途
UDM-to-UDM と UDM-to-Entity	31 日間	大量のテレメトリークエリ。
Case-to-CaseHistory	90 日間	ライフサイクルトラッキングクエリ。
サポートされているその他の構成	最長 365 日間	UDM または指標ベースのソース（取り込み指標など）のフォールバック。

データソースとテーブルの上限

1 つのクエリで結合できるデータソースとテーブルの最大数は、検索を使用しているか、ダッシュボードを使用しているかによって異なります。

検索の制約

クエリごとに最大 2 つの UDM イベントを使用できます。
1 つのクエリで使用できる心電図イベントは 1 つまでです。
1 つのクエリで使用できる Datatable は最大 2 つです。
データテーブルをエンティティコンテキストテーブルに直接結合することはできません。UDM イベントを仲介ブリッジとして使用する必要があります（たとえば、$event.target.hostname を $datatable.hostname と $asset.graph.entity.asset.hostname の両方に関連付けます）。

ダッシュボードの制約

結合タイプ	イベントテーブルの最大数（UDM またはデータテーブル）	最大エンティティテーブル数
マルチイベント（UDM から UDM）	2	なし
UDM からエンティティへ	2	1
UDM からデータテーブルへ	2	なし
マルチステージクエリ	2	1

パフォーマンスとガードレール

システムは、複雑な結合クエリでリソースの過剰な消費をモニタリングします。環境全体のパフォーマンスを保護するため、リソースの安全なしきい値を超えるクエリは自動的に一時停止または隔離されることがあります。

クエリが失敗した場合や、リソース上限を超えたことを示すエラーが返された場合は、次の最適化を試してください。

クエリの期間を絞り込みます。
より具体的なフィルタを追加して、結合が行われる前にデータセットのサイズを縮小します。
集計を簡素化します。

API とクエリの種類の制約

結合は、ユーザーインターフェースと EventService.UDMSearch API でサポートされていますが、SearchService.UDMSearch API ではサポートされていません。

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