運用ワークフローに直接対応するように、ドキュメントのナビゲーション構造を再編成しました。詳しくは、リリースノートとチュートリアル動画をご覧ください。

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 つの異なる Universal Data Model（UDM）イベントを接続します。次のクエリの例では、共通の IP アドレスに基づいて、USER_LOGIN イベントを別のイベントにリンクして、ユーザーが操作したホスト名（altostrat）を検索します。
```
$e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"

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

match:
  $ip over 5m
```

イベントと ECG の結合

イベントと ECG の結合は、UDM イベントを Entity Context Graph（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
```

データテーブルとイベントの結合

データテーブルとイベントの結合は、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）と結合することで、そのイベントの重要度を高めます。具体的には、エンティティグラフで「重要なデータベースサーバー」としてラベル付けされたアセットからの 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）を積極的に検索します。

結合タイプ: データテーブルとイベントの結合

説明: 脅威インテリジェンスチームは、悪意のあるドメインを一覧表示する 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）など、より複雑な指標の場合は、複数段階のクエリを使用できます。これにより、最初のステージで個々のケースの期間を計算し、最終結果ブロックでそれらの期間をグローバルに平均化できます。

次のクエリは、「デフォルト環境」のすべてのケースでケースをクローズするまでの平均時間（分）を計算します。

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 から UDM と UDM からエンティティ	31 日	大量のテレメトリークエリ。
ケースから CaseHistory	90 日	ライフサイクルトラッキングクエリ。
サポートされているその他の構成	最大 365 日	UDM ベースまたは指標ベース以外のソース（取り込み指標など）のフォールバック。

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

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

検索の制約

1 つのクエリで使用できる UDM イベント は最大 2 つです。
1 つのクエリで使用できる ECG イベント は最大 1 つです。
1 つのクエリで使用できる データテーブル は最大 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 のプロフェッショナルから回答を得ることができます。