データテーブルを使用する

データテーブルは、ユーザーが独自のデータを Google Security Operations に入力できる、複数列のデータ構造です。定義された列と行に格納されたデータによってルックアップ テーブルとして機能します。Google SecOps ウェブ インターフェース、データテーブル API、または YARA-L クエリを使用して、Google SecOps アカウントにデータテーブルを作成またはインポートできます。

データ RBAC を使用してデータテーブルにスコープを割り当てる

データテーブルを使用するには、データのロールベース アクセス制御（データ RBAC）を使用して、データテーブルにスコープを割り当てる必要があります。データテーブルにスコープを割り当てることで、どのユーザーとリソースがデータテーブルにアクセスして利用できるかを制御できます。詳細については、データテーブルのデータ RBAC を構成するをご覧ください。

Google SecOps ウェブ インターフェースを使用してデータテーブルを管理する

以降のセクションでは、ウェブ インターフェースを使用してデータテーブルを管理する方法について説明します。データテーブルへのアクセス方法、新しいデータテーブルの追加と内容の編集方法、テーブルへのデータのインポート方法、行の追加方法、カンマまたはタブを使用したデータの区切り方法、アカウントからデータテーブルを削除する方法などについて説明します。

データ表にアクセスする

[データテーブル] ページにアクセスするには、次の操作を行います。

• 左側のサイドバーで、[調査] > [データテーブル] を選択します。

特定のデータテーブルを見つけるには、サイドバーの上部にある [検索] フィールドに名前を入力します。

新しいデータテーブルを追加する

Google SecOps に新しいデータテーブルを追加する手順は次のとおりです。

1. サイドバーの右上にある add [作成] をクリックします。

2. [新しいデータテーブルを作成] ダイアログで、新しいテーブルに名前を付け、必要に応じて説明を追加します。

3. [作成] をクリックします。新しいデータテーブルがメイン ウィンドウに表示され、データを受け入れる準備が整います。

データテーブルにデータをインポートする

データテーブルにデータを追加するには、次のようにデータを Google SecOps に直接インポートします。

1. [データをインポート] をクリックします。

2. 標準の CSV ファイルを選択します（Google SecOps にインポートできるのは CSV ファイルのみです）。

3. データテーブルにデータをインポートする準備ができたら、[開く] をクリックします。

データ型をデータテーブルの列にマッピングする

ウェブ インターフェースまたは API を使用して、単一のデータ フィールドをデータ列にマッピングしたり、繰り返しデータ フィールドをデータ列にマッピングしたりできます。

• ウェブ インターフェースと API の両方で、データ フィールドの値を | 文字で区切ります。ウェブ インターフェースでは、値に | 文字が含まれている場合、デフォルトで繰り返し値として扱われます。

• API リクエストの場合は、repeated_values を true に設定します。

詳細については、繰り返しフィールドをご覧ください。

次の例では、データテーブルの列 Field_value に複数のフィールドの値が含まれています。

上の表は 4 つの列に分割されており、各列は、このドキュメントで説明するデータテーブルのユースケースで使用される前に、1 つのフィールド タイプにのみマッピングされます。

特定の列をキー列として指定する

列をキー列としてマークすると、その列の値が一意に識別され、データの重複が防止され、ルールと検索のデータ検出が改善されます。

繰り返しフィールドをサポートする特定の列を指定する

複数値フィールドまたは繰り返しフィールドを格納する列は、データテーブルの作成時に明示的に repeated として指定する必要があります。

列名をエンティティ フィールドにマッピングする（省略可）

データテーブルを作成するときに、データテーブルの列名をエンティティ フィールドにマッピングできます。

次のデータテーブルの例では、Userid 列と Role 列がそれぞれ entity.user.userid と entity.user.attribute.role.name にマッピングされています。

DataTable リソースの mapped_column_path フィールドを使用して、データテーブルの列をエンティティ proto フィールドにマッピングできます。

この例のテーブルの Email など、エンティティ パスが定義されていない列については、データ型を手動で指定する必要があります。参照リストと同様に、データテーブルでサポートされているデータ型は number、string、regex、cidr です。

join 条件を指定すると、マッピングされた列とマッピングされていない列の両方をデータテーブルに含めることができます。

マッピングされていない列は、テーブルが結合するエンティティの additional フィールドに保存されます。これらは Key-Value ペアとして追加されます。ここで、key は列名、value は対応する行の値です。

データテーブルに新しい行を追加する

新しい行を追加する手順は次のとおりです。

1. [詳細] タブで、既存の行を右クリックして [上に行を追加] を選択します。

2. 新しい行のデータを入力します。最初の行はテーブル ヘッダーとして扱われます。

   1. データ フィールドはカンマまたはタブで区切ります。
   2. 各データ項目を適切なデータ列に必ず一致させてください。
   3. [詳細] タブで入力した行データは、[テーブル エディタ] に入力されます。

データテーブルの行を編集する

行を編集するには、次の操作を行います。

1. 変更するフィールドをクリックします。これで、フィールドを編集できるようになります。

2. 変更を加えたら、[保存] をクリックします。

データを区切る際にカンマとタブのどちらを使用するかを指定する

カンマまたはタブを使用してデータを区切るには、次の操作を行います。

1. [データをインポート] の横にある grid_view [区切り文字の種類を編集] をクリックします。

2. [区切り文字の種類を編集] ダイアログで、[区切り文字] メニューから [カンマ] または [タブ] を選択します。

データテーブルの行を検索する

ウェブ インターフェースを使用して、データテーブル内の特定の情報を検索できます。[詳細] タブで、検索フィールドに検索文字列を入力し、[検索] をクリックします。検索文字列を含む行が表示されます。

テーブル行の TTL を管理する

テーブル行の有効期間（TTL）値を管理するには、次の操作を行います。

1. [TTL を列ごとに表示] をクリックします。TTL 列が表示され、各行が期限切れかどうかを示します。有効期限が切れていない場合は、有効期限までの残り時間が表示されます。

2. [デフォルトの行の有効期限] をクリックして [デフォルトの行の有効期限を更新] ダイアログを表示し、テーブル行の TTL を調整します。

3. [時間] または [日数] に新しい TTL 値を入力します。最小値は 24 時間です。最大値は 365 日です。

4. [保存] をクリックします。

テーブルの行を削除する

行を削除するには、行を右クリックして [行を削除] を選択します。

複数の行を削除するには、削除する各行を選択します。次に、選択した行のいずれかを右クリックして、[行を削除] を選択します。

データテーブルを削除する

データテーブルを削除するには:

1. 左側の [データ表] リストからデータ表を選択します。

2. [削除] をクリックします。

Chronicle API を使用してデータテーブルを管理する

Chronicle API で使用可能な REST リソースを使用して、Google SecOps のデータテーブルを管理することもできます。この API は、ウェブ インターフェースで使用できるすべての機能を複製できます。また、データテーブルをより高いパフォーマンスとより大きなスケールで管理できる追加機能も含まれています。

データテーブルの REST リソースは次のとおりです。

• dataTables

• dataTableRows

• dataTableOperationErrors

例: フィルタ構文

次の Chronicle API の例は、filter 構文を使用してデータテーブルの行で google.com を検索する方法を示しています。

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json" https://staging-chronicle.sandbox.googleapis.com/v1alpha/projects/{$PROJECT}/locations/${REGION}/instances/${INSTANCE}/dataTables/${DATA_TABLE_NAME}/dataTableRows?filter=google.com

Google SecOps でデータテーブルを使用する

データテーブルを Google SecOps インスタンスにインポートすると、YARA-L クエリを使用してデータをフィルタリング、強化、拡充できます。このドキュメントには、Google SecOps に組み込むことができる YARA-L 構文の例が多数含まれています。

データテーブルは、検索とルールの両方で YARA-L クエリと組み合わせて使用できます。データテーブルは、次の方法で使用できます。

• データテーブルを使用して UDM イベントまたはエンティティ データをフィルタする。データテーブルのエントリと比較することで、UDM テレメトリー イベントとエンティティをフィルタできます。

• データテーブルを複数列の参照リストとして使用する。データテーブルを複数列の参照リストとして使用できます。参照リストは 1 つのディメンションのデータにアクセスできますが、データテーブルでは複数のディメンションのデータにアクセスして、データをフィルタできます。

• データテーブルをイベントまたはエンティティと結合する。行ベースの比較に等価（=）演算子を使用すると、UDM イベントをデータテーブルにリンクできます。この比較を使用すると、データをフィルタできます。行ベースの比較は、ステートメント内のすべての条件がデータテーブルの 1 つの行と一致する場合にのみ true と評価されます。

データテーブルを使用して UDM イベントとエンティティ データをフィルタする

データテーブルのエントリと比較して、UDM イベントとエンティティをフィルタできます。

次のいずれかの方法で、UDM イベントをデータテーブルにリンクします。

• 行ベースの比較に等価演算子（=, !=, >, >=, <, <=）を使用します。例: $<udm_variable>.<field_path> = %<data_table_name>.<column_name>

• 列ベースの比較に in キーワードを使用します。例: $<udm_variable>.<field_path> in %<data_table_name>.<column_name>

参照リストと同様に、各データテーブル列でサポートされているデータ型は、number、string、regex、CIDR です。

列ベースの比較と結合に number 型のデータテーブル列を使用するには、次の構文を使用します。この例では、target.port 8080 を含むイベントを検索します。

%table.number_field = target.port
%table.number_field = 8080
target.port in %table.number_field

行ベースの比較に CIDR または regex 型のデータテーブル列を使用するには、次の構文を使用します。

net.ip_in_range_cidr($e.principal.ip, %<data_table_name>.<column_name>)

re.regex($e.principal.hostname, %<data_table_name>.<column_name>)

列ベースの比較に CIDR 型または regex 型のデータテーブル列を使用するには、次の構文を使用します。

$e.principal.ip in cidr %cidr_data_table.column_name

$e.principal.hostname in regex %regex_data_table.column_name

CIDR または正規表現のデータ型のデータテーブルの列を比較する場合、cidr キーワードと regex キーワードは省略可能です。not 演算子はデータテーブルでも使用できます。次のクエリの例では、IP アドレス（$e.principal.ip）が cidr_data_table の benign_ip 列にリストされている CIDR 範囲のいずれとも一致しないエントリを除外します。

not $e.principal.ip in %data_table.benign_ip

データテーブルを複数列の参照リストとして使用する

データテーブルは、複数列の参照リストとして使用できます。参照リストは 1 つのディメンション（1 つの列）のデータにアクセスできますが、データテーブルは複数の列に対応しているため、複数のディメンションにわたってデータをフィルタしてアクセスできます。

列ベースの比較に in キーワードを使用して UDM イベントをデータテーブルにリンクすると、特定の UDM フィールドの値をデータテーブルの単一の列の値と照合できます。

次の例では、badApps データテーブルに hostname と ip の 2 つの列が含まれています。クエリは、両方の値（UDM フィールドに基づく値とデータテーブルに基づく値の両方が文字列データ型）を個別に照合します。

ルールの例:

rule udm_in_data_table {
meta:
  description = "Use data table as multicolumn reference list"
events:
$e.metadata.event_type = "NETWORK_CONNECTION"
$e.security_result.action = "ALLOW"
$e.target.asset.asset_id = $assetid
     
// Event hostname matches at least one value in table column hostname.
$e.target.hostname in %badApps.hostname
    
// Event IP matches at least one value in table column ip.
$e.target.ip in %badApps.ip
match:
$assetid over 1h

condition:
$e
}

検索の例:

events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.security_result.action = "ALLOW"
    $e.target.asset.asset_id = $assetid
  
    // Event hostname matches at least one value in table column hostname.
    $e.target.hostname in %badApps.hostname
     
    // Event IP matches at least one value in table column ip.
    $e.target.ip in %badApps.ip

データテーブルを UDM イベントまたはエンティティに結合する

等価演算子と比較演算子（=, !=, >, >=, <, <=）を使用して UDM イベントをデータテーブルにリンクし、行ベースの比較を行うことができます。このアプローチでは、UDM イベントの値とデータテーブルの行を照合して、データをフィルタできます。複数の比較ステートメントを使用している場合、すべてのフィールドまたは条件が同じデータテーブル行で一致する必要があります。

クエリで演算子（not, !=, >, >=, <, <= など）を使用するには、UDM フィールドとデータテーブルの行の間に join 条件を 1 つ以上含める必要があります。Google SecOps は、データテーブル join を含むルールをマルチイベント ルールとして扱います。そのため、対応する match セクションをルール定義に含める必要があります。

結合が行われると、リンクされたデータテーブルの行が検索に表示されます。詳細については、検索でデータテーブルの行を表示するをご覧ください。

次の例では、string 型のデータテーブル列を使用します。この YARA-L クエリは、user ID がテーブルに存在することを確認することで、ユーザー ログイン イベントが example_table の行と一致するかどうかをチェックします。ルールをトリガーするには、両方の条件がデータテーブルの同じ行で一致する必要があります。

// Check if a user exists in a data table and that the user is active for all user login events.

ルールの例:

rule udm_join_data_table {
meta:
    description = "Join data table with UDM event"
events:
$e.metadata.event_type = "USER_LOGIN"
$e.security_result.action = "ALLOW"
$e.principal.user.userid = $userid

// Event must match at least 1 row in the table where the uid in the table
// row is the userid on the event and the active date in the same table
// row is before the event timestamp
%example_table.uid = $userid
$e.principal.hostname = %example_table.hostname

match:
$userid over 1h

condition:
$e
}

検索の例:

events:
$e.metadata.event_type = "USER_LOGIN"
$e.security_result.action = "ALLOW"
$e.principal.user.userid = $userid

// Event must match at least 1 row in the table where the uid in the table
// row is the userid on the event and the active date in the same table
// row is before the event timestamp
%example_table.uid = $userid
$e.principal.hostname = %example_table.hostname

次の例は、データテーブルと UDM イベントデータがどのように連携するかを示しています。上記の YARA-L クエリのロジックに基づき、user ID 32452 を持つユーザーは、システムからのユーザーの hostname として検出され、データテーブルの hostname と一致します。

YARA-L クエリの結果をデータテーブルに書き込む

YARA-L クエリの結果をデータテーブルに書き込むことができます。この機能を使用すると、Google SecOps データからデータテーブルを作成し、これらのテーブルを使用して他のデータをフィルタして強化できます。

YARA-L クエリの書き込み構文は、次の目的で使用できます。

• データテーブルにクエリ結果を書き込むための YARA-L 構文を定義します。

• 脅威インテリジェンス、インシデント対応、その他のセキュリティ ユースケースにデータテーブルを使用します。

• データは YARA-L の構文と規則に準拠している必要があります。

YARA-L を使用して検出とアラートをデータテーブルに書き込む

YARA-L クエリを使用して、検出とアラートをデータテーブルに送信できます。

write_row 関数を使用すると、ルールから得られた結果を使用して、データテーブルの行をデータテーブル内の対応するキーで上書きできます。キーがテーブルに見つからない場合は、代わりに新しい行を追加します。

YARA-L クエリのエクスポート セクションで write_row 関数を指定します。データテーブルへのデータの書き込みは、クエリの最終アクションである必要があります。これにより、結果変数がデータテーブルに書き込まれます。

export:
  %<data_table_name>.write_row(
  data_table_column_x_name: <value>,
  data_table_column_y_name: <value>,
  ...,
  ...,
  data_table_column_z_name: <value>
)
// depending on the key column(s), the rows will be updated for existing keys 
and appended for new keys

YARA-L を使用してデータテーブルを変更する

次の例は、YARA-L を使用してデータテーブルを変更する方法を示しています。

TableName: ip_user_domain_table（主キーのキー列は作成時に定義されます）

* は主キーを示します。

次のクエリは、principal.ip、principal.user.employee_id、target.domain の一意の組み合わせを取得します。target.domain の普及率に基づいて結果をフィルタします。

events:
    $e.principal.ip = $principal_ip
    $e.principal.user.employee_id = $principal_user_employee_id
    $e.target.domain.name = $target_domain
    $e.target.domain.prevalence.day_count < 5

// To run this query as a rule, add Condition Section here 
// condition:$e

クエリ結果:

例: write_row を使用してクエリ出力をデータテーブルに書き込む

ルールの例:

rule udm_write_data_table {
meta:
    description = "Writeto data table"
events:
  $e.principal.user.employee_id = $principal_user_employee_id
  $e.target.domain.name = $target_domain
  $e.target.domain.prevalence.day_count < 5

outcome:
  $hostname = $target_domain
  $principal_emp_id = $principal_user_employee_id
 
condition:
  $e

export:
  %ips_with_hostnames.write_row(
      employeeid:$principal_emp_id,
      hostname:$hostname
  )
}

検索の例:

events:
  $e.principal.user.employee_id = $principal_user_employee_id
  $e.target.domain.name = $target_domain
  $e.target.domain.prevalence.day_count < 5

outcome:
  $hostname = $target_domain
  $principal_emp_id = $principal_user_employee_id

export:
  %ips_with_hostnames.write_row(
      employeeid:$principal_emp_id,
      hostname:$hostname
  )

例: write_row の理解

次の例では、user と ip が主キーとして使用されています。検出テーブルに保持される各検出により、クエリのエクスポート セクションで関数呼び出しが 1 回評価されます。

ルールの例:

rule udm_write_data_table {
meta:
    description = "Write data table"
events:
    $e.metadata.event_type = "USER_LOGIN"
    all $e.security_result.action != "BLOCK"
    all $e.security_result.action != "UNKNOWN_ACTION"

    $user = $e.principal.user.userid
    $ip = $e.target.ip
    $ts = $e.metadata.event_timestamp.seconds

match:
    $user, $ip over 1h

outcome:
    $first_seen = min($ts)

condition:
    $e

export:
    %successful_logins.write_row(user:$user, ip:$ip)
}

検索の例:

events:
    $e.metadata.event_type = "USER_LOGIN"
    all $e.security_result.action != "BLOCK"
    all $e.security_result.action != "UNKNOWN_ACTION"

    $ts = $e.metadata.event_timestamp.seconds

outcome:
    $user = $e.principal.user.userid
    $ip = $e.target.ip[0]

export:
    %successful_logins.write_row(user:$user, ip:$ip)

イベントデータは次のとおりです。

metadata: {
  event_type: USER_LOGIN
  event_timestamp: { seconds: 1283299200 }
}
principal: {
  user: {
    userid: "charlie"
  }
}
target: {
  ip: ["192.0.2.135", "192.0.2.136"]
}
security_result: {
  action: ALLOW
}

このクエリをルールとして実行すると、次の検出が返されます。

データテーブルには次の情報が含まれています。

次の検索クエリは、検索で提供される、データテーブルへのスカラー値の書き込みのサポートを示しています。

events:
    $e.metadata.event_type = "NETWORK_CONNECTION"

export:
  %summary_table.write_row(col_name: $e.metadata.product_name, Vendor_name: $e.metadata.vendor_name)

データテーブルでエンティティ グラフを拡充する

データテーブルを使用すると、エンティティ グラフに表示されるエンティティをルールから追加、削除、置換できます。ルール setup セクションの関数を使用して、events セクションで参照されるエンティティ イベントからエンティティを削除するために、データテーブルをどのように結合、追加、使用するかを指定します。

次のルール テンプレートを使用して、エンティティ グラフを変更できます。

rule entity_graph_template {

  meta:
    ...

  setup:
    // import the data table into entity graph
    <enrichment_keyword> <join_condition>

  events:
    ...

  match:
    ...

  condition:
    ...
}

次の YARA-L 2.0 関数を使用して、データテーブルでエンティティ グラフを強化できます。

• graph_override: 結合条件に一致するエンティティ グラフの行を、データテーブルのデータで上書きします。

  次に例を示します。

  [graph_override](?tab=t.0#heading=h.v0fps7eke1if)

• graph_append: データテーブルの行をエンティティ グラフの行に追加します。graph_append オペレーションでは、結合条件ではなく、データテーブル変数とエンティティ イベント変数を含む配列が必要です。

  次の例では、$g1 はエンティティ グラフ変数で、example_table はデータテーブルです。

  graph_append [$g1, %example_table]

  append 関数の場合、エンティティを検証するために、データテーブルに次の列を含める必要があります。

  • start_time（metadata.interval.start_time.seconds にマッピング）

  • end_time（metadata.interval.end_time.seconds にマッピング）

  ウェブ インターフェースを使用して、データテーブルの列をメタデータ フィールドにマッピングすることはできません。append のユースケースでは、Chronicle API（https://cloud.google.com/chronicle/docs/reference/rest/v1alpha/projects.locations.instances.dataTables/create）を使用してデータテーブルを作成する必要があります。

• graph_exclude: join 条件に一致するエンティティ グラフの行を削除します。

  次に例を示します。

  [graph_exclude](?tab=t.0#heading=h.o0qbb5paki6g)

結合条件は、データテーブルの列とエンティティ グラフのフィールド間の等式表現である必要があります。graph_override 関数と graph_exclude 関数の場合、データテーブルにアクセスする構文は次のとおりです。

<data_table_name>.<column_name>

イベント セクションの <entity_variable> に指定されたフィルタは、データテーブルで拡張された後に適用されます。

エンティティ グラフ内のエンティティがデータテーブル内のエンティティで拡充されたら、エンティティ グラフ内のエンティティ変数を UDM エンティティに結合する必要があります。

データテーブルのデータでエンティティ グラフをオーバーライドする

graph_override 関数を使用すると、エンティティ グラフとデータテーブルの両方に存在するフィールドが、データテーブルのフィールドに置き換えられます。エンティティ グラフに存在し、データテーブルに存在しないフィールドは変更されません。エンティティ グラフには存在しないが、データテーブルには存在するフィールドが含まれます。

マッピングされたデータテーブルの列のみが、エンティティ グラフの列をオーバーライドします。マッピングされていない列は、データテーブルが結合されているエンティティ グラフの additional フィールドに追加されます。

例: 単一結合で一致させる

次の例では、データテーブルの列とエンティティ グラフのフィールド（$g1.graph.entity.ip = %example_table.my_ip）の結合条件に一致するエンティティ グラフの行が、データテーブルによってオーバーライドされます。

rule rule_override {
  meta:
    description = "Override entity context with data table before joining with UDM event"

  setup:
    //Rows in the entity graph that match the join condition are overridden by the data table
    graph_override ($g1.graph.entity.ip = %example_table.my_ip)

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.security_result.action = "ALLOW"

    // Filter will be applied after graph is overridden by data table
    $g1.graph.entity.hostname = "ftp01"

    // Accessing unmapped columns
    $g1.graph.additional.fields["Owner"] = "alice"

    // Joining the UDM event with the enriched entity graph
    $e.target.ip = $iocip
    $g1.graph.entity.ip = $iocip

  match:
    $iocip over 1h

  condition:
    $e and $g1
}

データテーブルのマッピングされていない列（「Owner」など）を使用するには、$g1.graph.entity.owner = "alice" is $g1.graph.additional.fields["Owner"] = "alice" の同等のステートメントを使用します。これは、データテーブルのマップされていないすべての列がエンティティ グラフ ($g1) の additional フィールドに入るためです。

次の表は、データテーブルの IP フィールドがエンティティ グラフの IP フィールドと一致する場合に、エンティティ グラフの行が拡充されるオーバーライド オペレーションを示しています。

例: 複数の結合で一致する

次の例では、複数の結合条件（$g1.graph.entity.ip = %example_table.my_ip と $g1.graph.entity.hostname = %example_table.my_hostname）に一致するエンティティ グラフの行は、データテーブルによってオーバーライドされます。

rule rule_override {
meta:
    description = "Override Entity context with Data Table before joining with UDM event"
setup:
  // example with more than one condition
  graph_override ($g1.graph.entity.ip = %example_table.my_ip and
  $g1.graph.entity.hostname = %example_table.my_hostname) 
events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"

  // Filter will be applied after graph is overridden by data table
  $g1.graph.entity.hostname = "ftp01"

  // joining the UDM event with the enriched entity graph
  $e.target.ip = $iocip
  $g1.graph.entity.ip = $iocip

match:
  $iocip over 1h

condition:
  $e and $g1
}

次の表は、データテーブルの IP フィールドとホスト名フィールドの両方がエンティティ グラフの IP フィールドとホスト名フィールドに一致する場合に、エンティティ グラフの行が拡充されるオーバーライド オペレーションを示しています。

データテーブルのデータをエンティティ グラフに追加する

graph_append 関数を使用する場合、結合条件は必要ありません。

次の例では、データテーブルのすべての行がエンティティ グラフの行に追加されます。

rule rule_append {
meta:
  description = "Data table append entity"
   
setup:
  graph_append [$g1, %example_table]

events:
    // filter UDM events
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"

  // Join the filtered UDM events with the enriched graph
  $e.target.ip = $iocip
  $g1.graph.entity.ip = $iocip

match:
  $iocip over 1h

condition:
  $e and $g1
}

次の例の表は、データテーブルの行がエンティティ グラフの行に追加される追加オペレーションを示しています。

graph_exclude を使用してエンティティ グラフから行を削除する

graph_exclude 関数を使用すると、結合条件に一致するエンティティ グラフの行がエンティティ グラフから削除されます。

次の例では、指定された結合条件（データテーブルの列とエンティティ グラフのフィールドの間）に一致するエンティティ グラフ内のすべての行が削除されます。データテーブルの行はエンティティ グラフに追加されません。

rule rule_exclude {

    meta:
    setup:
      graph_exclude ($g1.graph.entity.ip = %example_table.ip)

    events:
        $e.metadata.event_type = "NETWORK_CONNECTION"
        $e.security_result.action = "ALLOW"
        $e.target.ip = $iocip
        $g1.graph.entity.ip = $iocip

    match:
        $iocip over 1h

    condition:
        $e and $g1
}

次の表は、データテーブルの IP フィールドと一致するエンティティ グラフの行が削除される除外オペレーションを示しています。

制限事項

• Google SecOps アカウントのデータテーブルの最大数: 1,000。

• アップロードでサポートされているファイル形式は CSV のみです。

• クエリで参照リストを参照する場合の in ステートメントの数に関する上限は、データテーブルの in ステートメントにも適用されます。

• クエリ内の in ステートメントの最大数: 10

• String データ型と Number データ型の列のクエリ内の in ステートメントの最大数: 7

• 正規表現演算子を含む in ステートメントの最大数: 4

• CIDR 演算子を含む in ステートメントの最大数: 2

• データテーブルあたりの最大列数: 1,000。

• データテーブルあたりの最大行数: 1,000 万行。

• アカウント内のデータテーブル全体のデータ容量の最大合計制限: 1 TB。

• テキスト エディタ ビューとテーブル エディタ ビューのデータテーブルの行のウェブページでの最大表示上限: 10,000 行

• ウェブページの新しいデータテーブルにファイルをアップロードする際の最大行数: 10,000 行

• API からのデータテーブル作成の最大ファイル アップロード サイズの上限: 1 GB

• 設定セクションではプレースホルダを使用できません。

• データ型が string に設定されているデータテーブルのマッピングされていない列は、UDM イベントまたは UDM エンティティの文字列フィールドとのみ結合できます。

• CIDR または正規表現には、データ型が cidr または regex に設定されたデータテーブル内のマッピングされていない列のみを使用します。

• データテーブルのルックアップ: 正規表現のワイルドカードはサポートされていません。検索語句は 100 文字までに制限されています。

結合

• イベントでデータテーブル結合を使用している場合、検出のすべてのイベント サンプルの取得はサポートされていません。

• エンティティや UDM とは異なり、データテーブルはプレースホルダをサポートしていません。つまり、以下の行為は禁止されています。

  • 1 つのフィルタセットをデータテーブルに適用し、UDM エンティティと結合します。

  • 同じデータテーブルに別のフィルタセットを適用しながら、別の UDM プレースホルダと結合します。

  たとえば、my_hostname、org、my_email の 3 つの列を含む dt という名前のデータテーブルがあり、次のルールが適用されているとします。

  events:
  $e1.principal.hostname =  %dt.my_hostname
  %dt.org ="hr"
  
  $e2.principal.email =  %dt.my_email
  %dt.org !="hr"
  

データテーブルのすべてのフィルタが最初に適用され、データテーブルからフィルタされた行が UDM と結合されます。この場合、データテーブル dt の 2 つのフィルタが互いに矛盾しているため（%dt.org ="hr" and %dt.org !="hr"）、空のデータテーブルが e1 および e2 と結合されます。

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

ルールで使用する場合、データテーブルには次の制限が適用されます。

実行頻度

データテーブルを含むルールでは、リアルタイムの実行頻度はサポートされていません。

データテーブルへの出力

• any 修飾子と all 修飾子は、データテーブルの繰り返しフィールド列ではサポートされていません。

• データテーブルの繰り返しフィールド列では、配列インデックス作成はサポートされていません。

• 結果変数はデータテーブルにのみエクスポートできます。イベントパスやデータテーブルの列を直接エクスポートすることはできません。

• 列リストには、データテーブルの主キー列を含める必要があります。

• 結果は 20 個まで設定できます。

• データテーブルが存在しない場合は、指定された順序で、すべての列のデフォルトの文字列データ型を使用して新しいテーブルが作成されます。

• 一度にデータテーブルに書き込むことができるルールは 1 つだけです。別のルールがすでに書き込んでいるデータテーブルにルールが書き込もうとすると、ルールのコンパイルが失敗します。

• データテーブルのコンシューマー ルールが開始する前に、プロデューサー ルールがデータテーブルに行を追加できるとは限りません。

• ルールには、結果の行数の上限があります。結果と永続データには 10,000 行の上限が適用されます。データテーブルにも同じ上限が適用されます。1 回のルール実行でデータテーブルに出力できる行数は最大 10,000 行です。

• 同じ主キーを持つ行がデータテーブルにすでに存在する場合、主キー以外の列は新しい値に置き換えられます。

データテーブルからのエンティティの拡充

• 1 つのエンティティ グラフ変数に適用できる拡充オペレーションは 1 つだけです（override、append、exclude のいずれか）。

• 各拡充オペレーションは、1 つのデータテーブルのみを使用して実行できます。

• YARA-L ルールの setup セクションでは、任意のタイプのエンリッチ オペレーションを最大 2 つ定義できます。

次の例では、オーバーライド オペレーションがエンティティ グラフ変数 $g1 に適用され、append オペレーションがエンティティ グラフ変数 $g2 に適用されます。

    setup:
    graph_override($g1.graph.entity.user.userid = %table1.myids)
    graph_append [$g2, %table1]

上記の例では、同じデータテーブル（table1）を使用して、異なるエンティティ グラフを強化しています。次のように、さまざまなデータテーブルを使用して、さまざまなエンティティ グラフを強化することもできます。

    setup:
    graph_override($g1.graph.entity.user.userid = %table1.myids)
    graph_append [$g2, %table2]

検索でデータテーブルを使用する

検索で使用する場合、データテーブルには次の制限が適用されます。

• Chronicle API を使用してデータテーブルで検索クエリを実行することはできません。検索クエリはウェブ インターフェースからのみ実行できます。

• 1 回のクエリ実行でデータテーブルに出力できる行数は最大 100 万行、または 1 GB のいずれか早い方です。

• 検索結果をデータテーブルに出力する際、イベント行が 5 MB を超えるとスキップされます。

• 検索ではエンティティの拡充はサポートされていません。

• データテーブルは、顧客管理の暗号鍵（CMEK）を使用しているお客様には対応していません。

• 書き込みは、お客様 1 人あたり 1 分あたり 6 回に制限されます。

• API サポートは利用できません。

• 統計クエリは、データテーブル結合ではサポートされていません。

• データテーブルとデータテーブル結合は、エンティティではなく UDM イベントでのみサポートされます。

  サポート対象: %datatable1.column1 = %datatable2.column1 サポート対象外: graph.entity.hostname = %sample.test

• export セクションの統計クエリに match 変数を含めることはできません。

  たとえば、以下はサポートされていません。

  match:
      principal.hostname
  export:
      %sample.write_row(
      row: principal.hostname
    )

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