エンティティ コンテキスト グラフ（ECG）の使用

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

このドキュメントでは、エンティティ コンテキスト グラフ（ECG）の概要について説明します。データソース、処理パイプライン、ルールと検索でのアプリケーションについて取り上げます。ECG は、検出ルール、検索、ダッシュボードで高度な脅威の検出、調査、脅威ハンティングに不可欠なコンテキストを提供するコア エンティティ データモデルです。ECG 処理パイプラインは、各 Google SecOps 環境のコンテキスト情報を統合します。

ECG は、エンティティの概要指標も計算します。これには、普及率（特定のエンティティが UDM データで他のエンティティと比較してどのくらいの頻度で発生するか）や、エンティティの first-seen-time と last-seen-time などがあります。また、Google Threat Intelligence（GTI）、セーフ ブラウジング、WHOIS、VirusTotal データなどの主要なエンリッチメント ソースとセキュリティ侵害インジケーター（IOC）ソースも特定します。

ECG は UDM イベントを使用して次の処理を行います。

  • 内部エンティティ（アセットとユーザー）と外部エンティティ（IOC）の、強化され、関連付けられ、包括的なビューを構築します。
  • これらのエンティティ間の関係を特定します。

心電図のデータソース

心電図パイプラインは、次のソースのデータを組み合わせています。

コンテキスト ソース ソース 説明
エンティティ コンテキスト お客様提供 Google SecOps は、ユーザーやアセットに関する信頼できる詳細情報などの構造化された組織データを外部システムから直接取り込みます。これらのソースには、ID プロバイダ（IDP）、構成管理データベース（CMDB）システム（ServiceNow CMDB、Duo User Context など）、脆弱性の管理システムなどがあります。
派生コンテキスト Google SecOps によって生成された Google SecOps は、取り込まれたアクティビティの分析に基づいて統計データを生成します。環境内のさまざまなソース（Windows AD、Azure AD、Okta、 Google Cloud、IAM など）のイベントとエンティティを拡充します。
例:
グローバル コンテキスト Google ソース グローバル ソースは、内部および外部の脅威インテリジェンスと評判データを提供します。
例:

心電図データ処理パイプライン

心電図データ処理パイプラインは、各エンティティの信頼性の高い詳細なプロファイルを作成します。これは、複数のオリジン（ID プロバイダ、構成管理データベース（CMDB）、脅威インテリジェンス フィード、派生コンテキストなど）のコンテキストを単一の統合エンティティ プロファイルに統合することで実現されます。ECG の統合により、次のことが可能になります。

  • 心電図に新しい接続、プロパティ、関係を追加する。
  • 派生コンテキストの作成と更新。

プロセス全体では、まず UDM エイリアスとエンリッチメントを使用して未加工のセキュリティ イベントを UDM 構造に正規化し、次にこのイベントデータをさまざまなコンテキスト ソースと統合して、リッチなエンティティ プロファイルを作成します。

UDM のエイリアスと ECG の統合

まず、UDM エイリアスとエンリッチメントのパイプラインが未加工のセキュリティ イベントを取り込み、UDM 構造に正規化します。

時間指定エンティティと時間指定なしエンティティ

ECG は、時間依存（時間的）エンティティと時間非依存（非時間的）エンティティの両方を構築します。時間指定エンティティは、指定されたルールと検索の時間範囲内で評価されます。Timeless エンティティは、検索またはルールの期間を考慮せずに評価されます。

心電図の merge-key

ECG は、さまざまなデータソースで共通のキー識別子を照合して、コンテキスト レコードを統合します。これらの識別子の例としては、hostname、MAC address、user ID、email address などがあります。ECG は、これらの値のいずれかで一致するレコードを統合して、エンティティの包括的で充実したビューを構築します。

ECG エイリアスは、次の UDM フィールドをマージキーとして使用します。

  • Asset
    • entity.asset.product_object_id
    • entity.asset.hostname
    • entity.asset.asset_id
    • entity.asset.mac
  • User
    • entity.user.product_object_id
    • entity.user.userid
    • entity.user.windows_sid
    • entity.user.email_addresses
    • entity.user.employee_id
  • Resource
    • entity.resource.product_object_id
    • entity.resource.name
  • Group
    • entity.group.product_object_id
    • entity.group.email_addresses
    • entity.group.windows_sid

特定のエンティティ タイプ（ファイル、URL、ドメイン）の統合

ECG は、merge-keys に加えて、次の固有の識別子を使用して特定のエンティティ タイプ（ファイル、URL、ドメイン）のコンテキストを統合します。

  • File

    • entity.file.md5
    • entity.file.sha1
    • entity.file.sha256
    • （entity.file.product_object_id が提供されている場合はそれも含む）

  • URL

    • entity.url.url
    • （entity.url.product_object_id が提供されている場合はそれも含む）

  • Domain

    • entity.domain.domain
    • （entity.domain.product_object_id が提供されている場合はそれも含む）

ECG は、File、URL、または Domain のエンティティ コンテキスト レコードを、両方のレコードに存在する一意の識別子がすべて一致する場合にのみ、別のレコードと統合します。

たとえば、ECG が 2 つの File エンティティ コンテキストを統合対象と見なしている場合:

  • 両方に md5 ハッシュがある場合、ECG ではそれらが一致している必要があります。
  • 一方に md5 があり、もう一方に sha256 がある場合、心電図はハッシュに基づいてそれらを統合しません。
  • product_object_id が指定されている場合、比較対象の 2 つのレコードの両方に心電図が含まれている場合は、コンテンツ ベースの識別子（md5、url、domain など）に加えて、心電図も一致する必要があります。

つまり、これらのタイプでは、指定された product_object_id に加えて、entity.file.md5、entity.url.url、entity.domain.domain などのフィールドが存在し、マージ プロセスで一致する必要があります。

競合の解決

統合プロセス中に、フィールドの値が競合している場合、ECG は開始時間が最も新しい値を選択してエンティティを更新します。ECG がエンティティ属性を新しい値で更新すると、その前の値が有効だった期間の検索結果には、その前の値が保持されます。そのため、属性が変更された期間を対象とする検索クエリでは、そのエンティティに対して複数のエンティティ コンテキストが返されることがあります。

重複除去と時間間隔

共通の結合エンティティを作成するために、ECG は重複除去によって冗長データを削除します。重複は、さまざまなコンテキスト ソースにわたってエンティティの関連するすべての一意の識別子を照合することで識別されます。正確なタイムスタンプを照合するのではなく、時間間隔を生成します。

たとえば、タイムスタンプが t1 と t2 の 2 つのエンティティ e1 と e2 について考えます。e1 と e2 がそれ以外で同一の場合、ECG は次のフィールドのタイムスタンプの違いを無視して重複除去します。

  • collected_timestamp
  • creation_timestamp
  • interval

ルックバック ウィンドウ

心電図は、5 日間のルックバック ウィンドウでエンティティ コンテキスト データを作成します。このプロセスは、遅れて到着するデータを処理し、エンティティ コンテキスト データの暗黙的な有効期間を確立するのに役立ちます。

ECG は、コンテキスト データ（assets、users、resources、groups）とセキュリティ侵害インジケーター（IOC）を区別します。

例: 心電図の統合によるユーザーデータの統合

たとえば、Google SecOps は、Okta、Azure AD、脆弱性スキャナの 3 つのソースから jdoe のユーザーデータを取り込みます。ECG は、一致する識別子（jdoe@example.com など）に基づいて、これらの 3 つのレコードを統合します。これにより、ECG に 1 つの統合された jdoe ユーザー エンティティが作成され、3 つのソースすべての属性が含まれます。

重要なエンティティとイベントのコンテキスト ECG データソース

Google SecOps では、エンティティの作成と更新にいくつかの特定のデータソースが必要です。

重要なエンティティ コンテキストの心電図データソース

環境のユーザーとアセットの信頼できるデータソースは、エンティティ データモデルを構築するための最も重要なログデータを提供します。次に例を示します。

カテゴリ 重要なデータソース エンティティが入力された
ID とアクセスの管理 Active Directory、Azure AD、Okta、 Google Cloud Identity user、
group
アセット インベントリ CMDB、JAMF、Microsoft Intune asset
脅威インテリジェンス カスタム フィードまたはサードパーティ フィード、Google Threat Intelligence（GTI） ip_address、
domain_name、
file

各カテゴリをサポートするパーサーを一覧表示するには:

  1. デフォルト パーサーのあるサポートされているログタイプに移動します。

  2. 検索バーにカテゴリを入力します（例:）。

    • アセット インベントリに関連するパーサーの場合は、「inventory」または「asset」と入力します。
    • ID とアクセス管理に関連するパーサーの場合は、identity と入力します。
    • 脅威インテリジェンスに関連するパーサーの場合は、「IOC」と入力します。

エンティティ プロファイリングのデータソースと重要な UDM フィールド

Google SecOps は、信頼できるエンティティ コンテキスト データソースと重要な UDM フィールドに基づいて、エンティティ プロファイルを強化します。

エンティティ タイプ データソース 重要な UDM フィールド（エイリアスとインデックス登録用）
プロセス エンドポイント ログは、堅牢なプロセス エイリアシングに不可欠な安定した識別子である PSPI（`principal.process.product_specific_process_id`）を提供します。
たとえば、CrowdStrike EDR（CS_EDR）や Windows Sysmon（WINDOWS_SYSMON）などがあります。		 source.process.product_specific_process_id
ユーザー これらのソースは、ユーザー属性と ID 情報を提供します。
たとえば、Duo エンティティ コンテキスト データ（DUO_CONTEXT）や Okta（OKTA）などです。		 source.user.userid、
source.user.email_address、
source.user.windows_sid、
source.user.product_object_id
アセットまたはエンドポイント これらのソースは、信頼できるアセット情報を提供します。
例: ServiceNow CMDB（SERVICENOW_CMDB）、Tanium Asset（TANIUM_ASSET）。		 source.ip、
source.hostname、
source.asset_id、
principal.asset.hostname
ファイルのハッシュ データ コンテンツの一意の「デジタル フィンガープリント」を提供し、データの完全性を検証します。 source.file.sha256、
source.file.sha1、
source.file.md5

重要なイベント コンテキスト データ UDM フィールド

Google SecOps には、いくつかの重要なイベント コンテキスト データ UDM フィールドが必要です。

  • 最も重要な UDM フィールドは、安定した識別子と関係インジケーター（principal.*、target.*、src_*、dst_* フィールド）として機能します。

  • Entity graph 機能領域に属する主要な UDM フィールドの一覧をご覧ください。

  • 包括的な ECG を構築するには、価値の高い識別子と関係データを提供するデータソースを優先します。次に例を示します。

    エンティティ タイプ 重要なデータソース エンティティの構築に不可欠な UDM フィールド
    アセット（ホスト） EDR と XDR、DNS と DHCP、ファイアウォール、 Google Cloud コンソールの監査ログ metadata.event_type、
    principal.asset.asset_id、
    principal.asset.hostname、
    principal.ip
    ユーザー ID プロバイダ（IdP）ログ、HR フィード（コンテキスト）、Cloud Identity ログ、メールゲートウェイ principal.user.userid、
    principal.user.email_addresses、
    target.user.userid、
    principal.ip
    ネットワーク ファイアウォール、VPN、DNS、VPC フローログ principal.ip、
    target.ip、
    src_ip、
    dst_ip、
    network.direction
    ファイルとプロセス EDR と XDR、アプリケーション ログ target.file.full_path、
    target.process.file.full_path、
    target.process.command_line

例

ECG は、これらの UDM フィールドを使用して、ルール、検索、ダッシュボードでエンティティ コンテキスト データと UDM イベントデータを結合します。

たとえば、「ブルート フォース」モニタリング ルールでユーザー コンテキスト データを結合して、関連するユーザーが「ドメイン管理者」グループにも属し、関連するアセットがドメイン コントローラである場合にのみアラートを生成できます。

events:
  $fail.metadata.event_type = "USER_LOGIN"
  $fail.metadata.vendor_name = "Microsoft"
  $fail.principal.hostname = $hostname
  $fail.target.user.userid = $target_user
  $fail.security_result.action = "BLOCK"
  $fail.metadata.product_event_type = "4625"
 
  $fail.metadata.event_timestamp.seconds < $success.metadata.event_timestamp.seconds
 
  $success.metadata.event_type = "USER_LOGIN"
  $success.metadata.vendor_name = "Microsoft"
  $success.target.user.userid = $target_user
  $success.principal.hostname = $hostname
  $success.security_result.action = "ALLOW"
  $success.metadata.product_event_type = "4624"
  $user.graph.entity.user.userid = $target_user
  $user.graph.metadata.entity_type = "USER"
  $user.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $user.graph.relations.entity.group.group_display_name = "Domain Admins"

  $asset.graph.entity.asset.hostname = $hostname
  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $asset.graph.relations.entity.group.group_display_name = "Domain Controllers"
 
match:
  $target_user, $hostname over 15m
condition:
  #fail > 4 and $success and $user and $asset

派生コンテキストの拡充

Google SecOps は、組織のイベントデータから、すべての名前空間の各エンティティに対して動的なイベント駆動型推論データを生成します。エイリアス情報、内部エンリッチメント プロセスからのデータ、セキュリティ イベント データを使用して、関係（asset が IP address に関連付けられているなど）を確立します。

このプロセスでは、エンティティ プロファイルを強化するために有用なコンテキストが追加されます。たとえば、次のような操作が可能です。

  • entity.file.sha256～file (hash) 個のエンティティ
  • (principal or target).ip_geo_artifact.location.country_or_region～network (geolocation) 個のエンティティ

Google SecOps は、取り込まれたアクティビティの複数の指標を分析して、コンテキスト情報でイベントを拡充します。重要なエンリッチメント関数を実行して、たとえば、普及率の統計情報などのエンティティの希少性指標や、first-seen-time や last-seen-time などの時間的指標を生成します。

普及率の統計情報

ECG パイプラインは、既存のデータと受信データを分析して、普及率の指標を計算し、派生コンテキスト フィールドとして保存します。これらの指標は、環境内の domain、file hash、IP address などのエンティティの数値の「人気度」値を表します。一般的に、人気の高いエンティティはリスクが低いため、この方法でまれなアクティビティや異常なアクティビティを特定できます。

Google SecOps はこれらの統計情報を定期的に更新し、別のエンティティ コンテキストに保存します。検出エンジンはこれらの値を使用できます。また、UDM クエリ構文を使用してこれらの値を検索することもできます。ただし、これらの値は他のエンティティの詳細とともにコンソールに表示されません。

検出エンジン ルールの作成時に、次のフィールドを使用できます。

エンティティ タイプ UDM フィールド
ドメイン entity.domain.prevalence.day_count
entity.domain.prevalence.day_max
entity.domain.prevalence.day_max_sub_domains
entity.domain.prevalence.rolling_max
entity.domain.prevalence.rolling_max_sub_domains
ファイル（ハッシュ） entity.file.prevalence.day_count
entity.file.prevalence.day_max
entity.file.prevalence.rolling_max
IP アドレス entity.artifact.prevalence.day_count
entity.artifact.prevalence.day_max
entity.artifact.prevalence.rolling_max

Google SecOps では、day_max と rolling_max の値が次のように計算されます。

  • day_max は、アーティファクトの 1 日における最大普及率スコアを表します（1 日は UTC の午前 12 時 00 分 00 秒～午後 11 時 59 分 59 秒として定義されます）。
  • rolling_max は、過去 10 日間のアーティファクトの 1 日あたりの普及率スコアの最大値（day_max）を表します。
  • day_count は rolling_max の計算に使用されます。値は常に 10 です。

これらの値が domain に対して計算される場合、day_max と day_max_sub_domains の違い（および rolling_max と rolling_max_sub_domains）は次のようになります。

  • rolling_max と day_max は、特定のドメイン（サブドメインを除く）にアクセスする 1 日あたりの一意の内部 IP アドレスの数を表します。
  • rolling_max_sub_domains と day_max_sub_domains は、特定のドメイン（サブドメインを含む）にアクセスする一意の内部 IP アドレスの数を表します。

Google SecOps は、新しく取り込まれたエンティティ データを使用して普及率の統計情報を計算します。Google SecOps は、以前に取り込まれたデータに対して遡及的に計算を実行しません。Google SecOps が統計情報を計算して保存するまで、約 36 時間かかります。

例

ECG パイプラインでは、関連するコンテキスト データをルールまたは検索に結合するために、これらの UDM フィールドが必要です。心電図関連のすべてのデータを UDM イベントデータに明示的に結合する必要があります。

たとえば、心電図の prevalence データを使用して、セキュリティ ログ内の「まれな」ドメインへの接続を特定できます。

    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name != ""
    $dns.network.dns.questions.name = $domain
    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 3

  match:
    $domain over 5m
  condition:
    $dns and $prevalence

エンティティの最初と最後の検出時刻

Google SecOps は受信データを分析し、次の重要なフィールドでエンティティ コンテキスト レコードを拡充します。

  • first-seen-time: エンティティが環境で最初に検出された日時。
  • last-seen-time: 最新のモニタリングの日時。

これらの派生フィールドを使用すると、domain、file hash、asset、user、IP address エンティティ間のアクティビティを関連付けることができます。

これらの値は、次の UDM フィールドに格納されます。

エンティティ タイプ UDM フィールド
ドメイン entity.domain.first_seen_time
entity.domain.last_seen_time
ファイル（ハッシュ） entity.file.first_seen_time
entity.file.last_seen_time
IP アドレス entity.artifact.first_seen_time
entity.artifact.last_seen_time
アセット entity.asset.first_seen_time
ユーザー entity.user.first_seen_time

最初と最後の検出時刻の計算の例外:

  • asset エンティティと user エンティティの場合、Google SecOps は first_seen_time フィールドのみを入力し、last_seen_time フィールドは入力しません。
  • Google SecOps は、個々の Namespace 内の各エンティティの統計情報を計算しません。
  • Google SecOps は、これらの統計情報を BigQuery の Google SecOps events スキーマにエクスポートしません。
  • Google SecOps は、group や resource などの他のエンティティ タイプに対してこれらの値を計算しません。

グローバル コンテキストの拡充

これらのソースには、内部およびサードパーティのグローバル ソースからの外部脅威インテリジェンスと評判データが含まれます。

Google Threat Intelligence データを取得する

Google SecOps は、Google Threat Intelligence（GTI）データソースからデータを取り込み、環境内のアクティビティの調査に使用できるコンテキスト情報を提供します。

次のデータソースに対してクエリを実行します。

  • GTI Tor 出口ノード: 既知の Tor 出口ノードの IP アドレス。
  • GTI Benign Binaries: オペレーティング システムの元のディストリビューションの一部であるか、公式のオペレーティング システムのパッチによって更新されたファイル。最初のエントリ ベクトルに焦点を当てているものなど、環境寄生型攻撃に一般的に見られる攻撃を通じて悪用された一部の公式のオペレーティング システムのバイナリは、このデータソースから除外されます。
  • GTI リモート アクセスツール: 悪意のあるアクターが頻繁に使用するファイル通常、これらのツールは正規のアプリケーションであり、悪用されて不正使用されたシステムにリモートで接続されることがあります。

コンテキスト データはエンティティとしてグローバルに保存されます。検出エンジンのルールを使用してデータをクエリできます。これらのグローバル エンティティをクエリするには、ルールに次の UDM フィールドと値を含めます。

  • graph.metadata.vendor_name = Google Threat Intelligence
  • graph.metadata.product_name = GTI Feed

時間指定された対時間制限のない Google Threat Intelligence データソース

Google Threat Intelligence のデータソースには、時間指定または時間制限のないのいずれかのタイプがあります。

timed データソースの各エントリには、関連付けられた時間範囲があります。たとえば、Google SecOps が 1 日目に検出を生成した場合、将来の任意の日に行われる Retro Hunt 中に 1 日目のために同じ検出が生成されると想定されます。

時間制限のないデータソースには、最新のデータセットのみを考慮する必要があるため、関連付けられた時間範囲はありません。これらのデータソースは通常、ファイル ハッシュなど、変更されることが想定されていないデータに使用されます。Google SecOps で 1 日目に検出が生成されなかった場合でも、2 日目の Retro Hunt 中に、タイムレス データソースに新しいエントリが追加されていれば、1 日目の検出が生成されることがあります。

Tor 出口ノードの IP アドレスに関するデータ

Google SecOps は、Tor 出口ノードと呼ばれる IP アドレスを取り込み、保存します。Tor 出口ノードは、Tor ネットワークからトラフィックが送信されるポイントです。このデータは時間指定されています。

Google SecOps は、このデータソースから取り込まれた情報を次の UDM フィールドに格納します。

UDM フィールド 説明
<variable_name>.graph.metadata.vendor_name 値 Google Threat Intelligence を保存します。
<variable_name>.graph.metadata.product_name 値 GTI Feed を保存します。
<variable_name>.graph.metadata.threat.threat_feed_name 値 Tor Exit Nodes を保存します。
<variable_name>.graph.entity.artifact.ip GTI データソースから取り込まれた IP アドレスを保存します。
検索の例
graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"

良性のオペレーティング システム ファイルに関するデータ

Google SecOps は、GTI Benign Binaries データソースからファイル ハッシュを取り込んで保存します。Google SecOps は、このデータソースから取り込まれた情報を次の UDM フィールドに格納します。安全なバイナリのデータは時間制限がありません。

UDM フィールド 説明
<variable_name>.graph.metadata.vendor_name 値 Google Threat Intelligence を保存します。
<variable_name>.graph.metadata.product_name 値 GTI Feed を保存します。
<variable_name>.graph.metadata.threat.threat_feed_name 値 Benign Binaries を保存します。
<variable_name>.graph.entity.file.sha256 ファイルの SHA256 ハッシュ値を保存します。
<variable_name>.graph.entity.file.sha1 ファイルの SHA-1 ハッシュ値を保存します。
<variable_name>.graph.entity.file.md5 ファイルの MD5 ハッシュ値を保存します。
検索の例
graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Benign Binaries"

リモート アクセス ツールに関するデータ

リモート アクセスツールには、悪意のあるアクターが頻繁に使用する、VNC クライアントなどの既知のリモート アクセス ツールのファイル ハッシュが含まれています。通常、これらのツールは正規のアプリケーションであり、悪用されて不正使用されたシステムにリモートで接続されることがあります。Google SecOps は、このデータソースから取り込まれた情報を次の UDM フィールドに格納します。リモート アクセス ツールのデータは時間制限なしです。

UDM フィールド 説明
<variable_name>.graph.metadata.vendor_name 値 Google Threat Intelligence を保存します。
<variable_name>.graph.metadata.product_name 値 GTI Feed を保存します。
<variable_name>.graph.metadata.threat.threat_feed_name 値 Remote Access Tools を保存します。
<variable_name>.graph.entity.file.sha256 ファイルの SHA256 ハッシュ値を保存します。
<variable_name>.graph.entity.file.sha1 ファイルの SHA-1 ハッシュ値を保存します。
<variable_name>.graph.entity.file.md5 ファイルの MD5 ハッシュ値を保存します。
検索の例
graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Remote Access Tools"

セーフ ブラウジングの脅威リストの情報を使用してエンティティを拡充する

Google SecOps は、ファイル ハッシュに関連するデータをセーフ ブラウジングから取り込みます。Google SecOps は、各ファイルのデータをエンティティとして保存し、ファイルに関する追加コンテキストを提供します。このエンティティ コンテキスト データをクエリしてコンテキストに応じた分析を構築する検出エンジンルールを作成できます。

Google SecOps は、エンティティ コンテキスト レコードに次の情報を保存します。

UDM フィールド 説明
entity.metadata.product_entity_id エンティティの一意の識別子。
entity.metadata.entity_type この値は FILE で、エンティティがファイルを表していることを示します。
entity.metadata.collected_timestamp エンティティが確認された日時、またはイベントが発生した日時。
entity.metadata.interval このデータが有効である開始時間と終了時間を保存します。脅威リストのコンテンツは時間の経過とともに変化するため、start_time と end_time には、エンティティに関するデータが有効な期間が反映されます。たとえば、start_time と end_time の間にファイル ハッシュに悪意があるか、または疑わしいことが確認されました。
entity.metadata.threat.category Google SecOps の SecurityCategory が次のいずれかの値に設定されています。
  • SOFTWARE_MALICIOUS: 脅威がマルウェアに関連していることを示します。
  • SOFTWARE_PUA: 脅威が望ましくないソフトウェアに関連していることを示します。
entity.metadata.threat.severity これは Google SecOps の ProductSeverity です。値が CRITICAL の場合、アーティファクトに悪意があることを示します。値が指定されていない場合、アーティファクトに悪意があることを示す十分な信頼性がありません。
entity.metadata.product_name 値 Google Safe Browsing を保存します。
entity.file.sha256 ファイルの SHA256 ハッシュ値。

ルールの例

events:
    // find a process launch event, match on hostname
    $execution.metadata.event_type = "PROCESS_LAUNCH"
    $execution.target.process.file.sha256 != ""
    $execution.principal.hostname = $hostname

    // join execution event with Safe Browsing graph
    $sb.graph.entity.file.sha256 = $execution.target.process.file.sha256

    // look for files deemed malicious
    $sb.graph.metadata.entity_type = "FILE"
    $sb.graph.metadata.threat.severity = "CRITICAL"
    $sb.graph.metadata.product_name = "Google Safe Browsing"

  match:
    $hostname over 5m

  condition:
    $execution and $sb

WHOIS データを使用してエンティティを拡充する

Google SecOps は、時間依存データと時間非依存データの両方を使用して、重要な機能である WHOIS データのデータ拡充を毎日実行します。

デバイスデータの取り込み中に、Google SecOps は WHOIS データに対してドメインを評価します。ドメインが一致すると、Google SecOps は関連する WHOIS データをドメインのエンティティ レコードに保存します。entity.metadata.entity_type = DOMAIN_NAME を含むエンティティごとに、Google SecOps は WHOIS 情報でレコードを拡充します。

Google SecOps は、次のフィールドに WHOIS 拡充データを入力します。

  • entity.domain.admin.attribute.labels
  • entity.domain.audit_update_time
  • entity.domain.billing.attribute.labels
  • entity.domain.billing.office_address.country_or_region
  • entity.domain.contact_email
  • entity.domain.creation_time
  • entity.domain.expiration_time
  • entity.domain.iana_registrar_id
  • entity.domain.name_server
  • entity.domain.private_registration
  • entity.domain.registrant.company_name
  • entity.domain.registrant.office_address.state
  • entity.domain.registrant.office_address.country_or_region
  • entity.domain.registrant.email_addresses
  • entity.domain.registrant.user_display_name
  • entity.domain.registrar
  • entity.domain.registry_data_raw_text
  • entity.domain.status
  • entity.domain.tech.attribute.labels
  • entity.domain.update_time
  • entity.domain.whois_record_raw_text
  • entity.domain.whois_server
  • entity.domain.zone

Google SecOps は、global context WHOIS レコードの registrant、creation、expiration time データを使用して domain エンティティ（entity.metadata.entity_type = "DOMAIN_NAME"）を拡充します。

これらのフィールドの説明については、統合データモデルのフィールド リストのドキュメントをご覧ください。

検索の例

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
graph.entity.domain.registry_data_raw_text != b""

ベスト プラクティス: グローバル コンテキストで強化されたデータソースを特定する

ルールのパフォーマンスを向上させるには、グローバル コンテキストの拡充ソースのデータを使用するフィルタをルールに含めます。このフィルタは、特定のリッチ化タイプまたはソースを識別する必要があります。

次のフィルタ パラメータは、拡充のタイプまたはソースを識別します。entity_type、product_name、vendor_name。

たとえば、WHOIS データを結合するルールの events セクションに次のフィルタ フィールドを含めます。

$enrichment.graph.metadata.entity_type = "DOMAIN_NAME"
$enrichment.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
$enrichment.graph.metadata.vendor_name = "WHOIS"

心電図のベスト プラクティス

コンテキスト拡充されたデータを使用する場合は、次の ECG のベスト プラクティスを考慮してください。

  • エンティティ データに間隔を追加しないでください。代わりに、心電図パイプラインで作成します。特に指定しない限り、Google SecOps は重複除去中に間隔を生成します。
  • 間隔を指定すると、Google SecOps は同一のイベントのみを重複除去し、最新のエンティティを保持します。
  • ライブルールとレトロハントが想定どおりに機能するようにするには、エンティティを少なくとも 1 日 1 回取り込む必要があります。
  • エンティティを毎日取り込まず、2 日以上に 1 回だけ取り込む場合でも、ライブルールは想定どおりに機能する可能性があります。ただし、レトロハントでは一部のイベント コンテキストが失われる可能性があります。
  • 同じエンティティを 1 日に複数回取り込むと、Google SecOps はそれらを 1 つのエンティティに重複除去します。
  • 1 日分のイベントデータがない場合、Google SecOps は前日のデータを一時的に使用して、ライブルールが正しく機能するようにします。

Google SecOps サービスの一般的な上限の詳細については、サービスの上限をご覧ください。

関連する外部コンテンツ

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