はじめのProfessional Security Operations Engineer 認定取得講座⑬Google SecOpsのユーザーエンリッチメントとエイリアス解決、Google SecOpsのプロセスエンリッチメントとPSPIを解説、Google SecOpsのVirusTotal連携とアーティファクトエンリッチメントを解説します！

クラウド

Google Security Operations（Google SecOps）では、ログに含まれるユーザーやプロセス、ファイルハッシュなどの情報にコンテキストを付加する「エンリッチメント」が、セキュリティ調査や検出において重要な役割を果たします。特にプロセス情報については、単に実行されたプロセスを確認するだけでなく、親プロセスとの関係を正確に把握することで、攻撃者がどのような実行経路をたどったのかを追跡できます。

本記事では、OSのPIDだけでは発生し得るPID再利用の問題を取り上げ、EDRが提供するPSPI（Product Specific Process ID）がどのようにプロセスの一意性を補完するのかを解説します。さらに、Google SecOpsのUDMにおけるPSPIの格納先や、CBNによるプロセス情報のマッピング方法について紹介します。

Professional Security Operations Engineer（PSOE）認定試験の対策としても、プロセスエンリッチメントとPSPIの役割を整理して理解しておきましょう。

是非、最後までご覧いただけると嬉しいです。

Google SecOpsのユーザーエンリッチメントとエイリアス解決

Google Security Operations（Google SecOps）では、ログイベント単体（IPアドレスやユーザー名のみ）に対して、組織のActive DirectoryやIdP（Cloud Identity / Okta等）から取得したコンテキスト情報（部署、役職、SID、メールアドレス等）を自動的に結合する「ユーザーエンリッチメント（User Enrichment）」機能が提供されています。

Professional Security Operations Engineer（PSOE）認定試験では、エンティティデータ（ユーザーコンテキスト）とイベントログを結びつける際の解決優先順位およびエイリアシング（Aliasing）による上書きルールの技術仕様を正しく理解しておくことが求められます。本記事では、その解決ロジックと設計上のポイントを解剖します。

1. ユーザーエンリッチメントの概要とメリット

ユーザーエンリッチメントは、イベントログに含まれるユーザー識別子（ユーザー名、メールアドレス等）をキーとして、Google SecOpsのエンティティグラフ（Entity Graph）に格納された最新のユーザーコンテキストデータを動的に結合（マージ）する処理です。

  • コンテキストの自動付与：単なる「j_doe」というログデータに対し、氏名、メールアドレス、所属部署、役職、SID、セキュリティグループなどの詳細属性を自動的に紐付けます。
  • 相関分析の高速化：ユーザーが複数の異なる識別子（Active DirectoryのSAMAccountName、Google WorkspaceのEmail、社員ID等）でアクティビティを行っても、同一人物として紐付けて調査できます。

2. アイデンティティ解決の優先順位ルール

Google SecOpsがイベントログ内の識別子とユーザーエンティティを紐付ける際、曖昧さを排除するために厳密な決定論的優先順位（Resolution Priority）が適用されます。

複数の識別子が存在する場合、パイプラインは以下の順序で一致を評価します：

  1. 最優先：EMAIL（メールアドレス）
    • 最も一意性が高く信頼できる識別子として扱われます（例：john.doe@example.com）。
  2. 第2優先：SID（Active Directory セキュリティ識別子）
    • Windowsドメイン環境等で一意なアカウント識別子（例：S-1-5-21-...）。
  3. 第3優先：USER_ID / SAMAccountName（ユーザーID / アカウント名）
    • システム固有のログインID（例: jdoe）。
  4. 最下位：EMPLOYEE_ID（社員番号）
    • 人事システム等で使用される識別キー。

この優先順位に従い、上位の識別子で一致が検出された場合、下位の識別子における矛盾や重複よりも上位の一致が優先してマッピングに使用されます。

3. CBNパイプラインとエイリアス解決（Aliasing）メカニズム

Google SecOps内部のCBN（Code-Based Normalization）パーサーおよびエンリッチメントパイプラインでは、エイリアスフィールドの処理に特別な上書きロジックが存在します。

  • エイリアスフィールド（entity.user.user_displayName 等）の処理：パース処理の過程で、生ログから抽出された直接のユーザー名フィールドが存在していても、エンリッチメントパイプラインによって参照されたエンティティデータ（IdP等から収集した最新属性）が存在する場合、パース済みの既定フィールドがエイリアスデータによって優先的に補完・上書きされます。
  • リアルタイム性とデータ統合：エンティティ情報は定期的にIdPやDirectoryソースから同期（Ingest）され、履歴イベントに対しても過去の特定時点での属性（Timelined Entity State）を参照して正確にエンリッチメントが行われます。

4. 試験対策および設計上の考慮点

PSOE認定試験およびSOC運用設計では、以下のポイントを把握しておくことが重要です。

  • ログソース側での識別子正規化：パーサー（CBN）作成時、生ログから抽出したユーザー情報を可能な限り principal.user.email_addresses や principal.user.userid などの適切なUDMフィールドにマッピングしておくことで、エンリッチメントの解決精度が最大化されます。
  • IdPデータ連携の完全性：Cloud IdentityやOkta、Active Directoryからのエンティティデータ（USER entity）取り込みが停止すると、エンリッチメントが適用されず、UDM検索やYARA-Lルールでの属性参照（$event.principal.user.attribute 等）が不発になるため、エンティティパイプラインの正常性監視（サイレントソース検知等）が不可欠です。

Google SecOpsのユーザーエンリッチメントとエイリアス解決のまとめ

Google SecOpsのユーザーエンリッチメントは、ログのユーザー識別子とエンティティ情報を結び付け、調査や検知に必要なコンテキストを付加する機能です。ユーザーを特定する際には、EMAIL、SID、USER_ID、EMPLOYEE_IDなどの識別子が利用され、解決時の優先順位を理解することが重要です。

また、エイリアスによって複数の識別子を同一ユーザーとして関連付け、異なるシステム間のユーザー情報を統合できます。正確なエンリッチメントには、ログ側のユーザー情報を適切なUDMフィールドへマッピングし、エンティティデータを継続的に取り込むことが重要です。

PSOE試験対策として、User Enrichmentの目的、ユーザー識別子の解決、エイリアスの役割を整理して理解しておきましょう。

Google SecOpsのプロセスエンリッチメントとPSPIを解説

セキュリティ運用センター（SOC）において、エンドポイントの脅威調査（Endpoint Investigation）を行う際、単なる「どのコマンドが実行されたか」という点だけでなく、「どのプロセスが親となり、どのような実行ツリー（Process Tree）を経て悪意あるアクションに至ったか」を把握することは攻撃の全体像解明に不可欠です。

Google Security Operationsでは、取り込まれたログのプロセス情報を構造化・強化する「プロセスエンリッチメント（Process Enrichment）」と、EDRベンダー固有のユニークIDである「EDRプロセスID（PSPI：Product Specific Process ID）」を活用することで、正確な親子プロセスのマッピングとグラフィカルなプロセスツリーの再構築を実現します。

本記事では、Professional Security Operations Engineer認定試験対策および高度な検出エンジニアリング設計において重要となる、PSPIの概念とCBN（Code-Based Normalization）マッピング手法について深く解説します。

1. 従来のPIDマッピングにおける課題：PIDの再利用（PID Reuse）問題

WindowsやLinuxなどのオペレーティングシステムでは、プロセスが生成されるたびに数値のPID（Process ID）が割り当てられます。しかし、標準のPIDには以下の深刻な構造的課題が存在します。

  • PIDの再利用（PID Reuse）：OS内でプロセスが終了すると、そのPIDは新しく起動した別の全く無関係なプロセスに再割り当てされます。
  • 短時間でのハッシュ衝突に似た誤結合：ログのタイムスタンプのわずかなズレや大規模環境でのログ集約において、終了した悪意あるプロセスのPIDと、後から起動した正常なプロセスのPIDが混同され、誤った親子関係が構築されるリスクがあります。

単一のPIDやプロセス名だけでログを関連付けると、SOCアナリストの調査において「存在しない攻撃パス」を誤認したり、真の攻撃起源（Root Cause）を見失ったりする原因となります。

2. EDRプロセスID（PSPI）の概念とUDM構造

このPID再利用問題を解決するために、CrowdStrike、Microsoft Defender for Endpoint、SentinelOneなどの主要EDR製品は、プロセスごとにグローバルに一意なプロセス識別子（GUID / PSPI）を発行しています。

PSPIの生成ロジック

PSPIは一般的に、「ホスト一意ID ＋ プロセス作成タイムスタンプ ＋ OSのPID」 などを組み合わせた暗号学的・論理的に一意な文字列です。これにより、OS再起動後や長時間経過後であっても、特定のプロセス実行インスタンスを一意に特定可能です。

UDM（統合データモデル）における表記構造

Google SecOpsのUDMでは、プロセスオブジェクトの中にPSPIを格納するための専用フィールドが定義されています。

  • 実行プロセス（Principal / Target Process）：principal.process.product_specific_process_id または target.process.product_specific_process_id
  • 親プロセス（Parent Process）：principal.process.parent_process.product_specific_process_id

3. CBN（Code-Based Normalization）での親子プロセスマッピング設計

サードパーティEDRからの生ログをGoogle SecOpsに取り込む際、CBNパーサー（またはパーサー拡張機能）において生ログ内のGUID / PSPIを適切に抽出し、UDMのプロセスフィールドに割り当てる必要があります。

CBNにおけるマッピング記述例（概念）

以下は、EDRから送信されたJSONログからプロセスおよび親プロセスのPSPIを抽出し、UDM構造へ正規化するCBNロジックの概要です。

filter {
  # ①フィールドの事前初期化（ベストプラクティス）
  mutate {
    replace => {
      "event.idm.read_only_udm.principal.process.pid"
      "event.idm.read_only_udm.principal.process.product_specific_process_id"
      "event.idm.read_only_udm.principal.process.parent_process.pid"
      "event.idm.read_only_udm.principal.process.parent_process.product_specific_process_id"
      "event.idm.read_only_udm.principal.process.file.full_path"
      "event.idm.read_only_udm.principal.process.command_line"
    }
  }

  # ②JSONパース（on_error でパース失敗を捕捉）
  json {
    source   => "message"
    target   => "edr_event"
    on_error => "json_parse_error"
  }

  if ![json_parse_error] {

    # ③フィールドマッピング
    mutate {
      replace => {
        "event.idm.read_only_udm.principal.process.pid" =>
            "%{[edr_event][TargetProcessId]}"

        "event.idm.read_only_udm.principal.process.product_specific_process_id" =>
            "SYSMON:%{[edr_event][TargetProcessGUID]}"

        "event.idm.read_only_udm.principal.process.parent_process.pid" =>
            "%{[edr_event][ParentProcessId]}"

        "event.idm.read_only_udm.principal.process.parent_process.product_specific_process_id" =>
            "SYSMON:%{[edr_event][ParentProcessGUID]}"

        "event.idm.read_only_udm.principal.process.file.full_path" =>
            "%{[edr_event][Image]}"

        "event.idm.read_only_udm.principal.process.command_line" =>
            "%{[edr_event][CommandLine]}"
      }
      on_error => "mutate_error"
    }

    # ④pid は uint32 型のため整数に変換
    if [event.idm.read_only_udm.principal.process.pid] != "" {
      mutate {
        convert => {
          "event.idm.read_only_udm.principal.process.pid" => "integer"
        }
        on_error => "pid_convert_error"
      }
    }

    if [event.idm.read_only_udm.principal.process.parent_process.pid] != "" {
      mutate {
        convert => {
          "event.idm.read_only_udm.principal.process.parent_process.pid" => "integer"
        }
        on_error => "parent_pid_convert_error"
      }
    }
  }
}

この正規化設計により、イベント発生時の単一プロセス情報だけでなく、その上位に位置する親プロセスのメタデータがUDMレベルで厳密に紐付けられます。

4. プロセスツリー再構築とTIN（トリアージ・調査エージェント）での活用

PSPIに基づく高精度なプロセスマッピングは、検出エンジニアリングおよびAI自動調査において真価を発揮します。

  1. TIN（トリアージ・調査エージェント）による自律調査：Google SecOpsに搭載されたAIエージェントTINは、アラート発生時にプロセスツリーの自動再構築（Process Tree Reconstruction）を行います。UDM内にPSPIが正しくマッピングされている場合、TINは曖昧さなく瞬時に「wmiprvse.exe → cmd.exe → powershell.exe（EncodedCommand）」といった攻撃者の実行階層を可視化・分析します。
  2. YARA-L 2.0ルールの精度向上：YARA-Lの相関ルール（matchセクション）において、$process_guid（PSPI）を結合キーとして指定することで、同一プロセスインスタンス内で発生した複数の不審イベント（例: 特定プロセスによるレジストリ変更とネットワーク外部接続）を誤検知（False Positive）なく相関検知できます。

5. PSOE試験および実運用における設計上のベストプラクティス

  • 標準PIDよりPSPIを優先した正規化方針：パーサー設計時は、OSのPIDマッピング（process.pid）を維持しつつも、エンリッチメントや追跡のキーとして product_specific_process_id を必ず設定する設計とします。
  • EDRエージェントのログレベル最適化：EDR側で親プロセスGUIDの出力が有効化されているかを確認します。一部の軽量ログ設定では親プロセスのGUIDが省略されることがあるため、ログ取り込み仕様の事前評価が必要です。

Google SecOpsのプロセスエンリッチメントとPSPIを解説のまとめ

プロセスエンリッチメントは、プロセス情報を強化し、親子関係を含めた実行コンテキストを把握するための重要な仕組みです。OSのPIDはプロセス終了後に再利用される可能性があるため、EDRが提供するPSPI（Product Specific Process ID）を活用することで、プロセスの実行インスタンスをより正確に追跡できます。

Google SecOpsでは、PSPIをUDMのプロセスフィールドへ適切にマッピングすることで、親子プロセスの関係を正確に構築できます。さらに、CBNによるプロセス情報の正規化は、検出ルールやインシデント調査におけるプロセス情報の活用につながります。

PSOE試験対策としても、PSPIの役割とUDMにおけるプロセス情報のマッピングを理解しておくことが重要です。

Google SecOpsのVirusTotal連携とアーティファクトエンリッチメントを解説

Google Security Operationsでは、Google Threat Intelligence（GTI）や VirusTotal（VT）v3 API との強力な統合機能を提供しています。ログがプラットフォームに取り込まれると、そこに含まれる各種アーティファクト（ファイルハッシュ、IPアドレス、ドメイン、URL）に対して自動的に脅威インテリジェンスが照合・付与（Enrichment）されます。

Professional Security Operations Engineer認定試験および実用的な SOC 運用設計においては、この自動エンリッチメントパイプラインがどのような優先順位と内部ロジックでアーティファクトを評価しているかを正確に理解しておくことが求められます。本記事では、特にファイルハッシュの優先判定順序とアーティファクト拡充の仕様を深掘りして解説します。

1. VirusTotal v3 統合と自動エンリッチメント（Enrichment）の概要

Google SecOps に送信されたログは、パースおよび UDM（統合データモデル）への正規化を経て、エンリッチメントパイプラインを通過します。VirusTotal v3 統合を介して、ログ内に存在するファイルや通信先エンティティに対する最新のレピュテーション情報、検知数、マルウェア分類などがリアルタイムに付与されます。

この処理により、アナリストが手動でサードパーティの脅威情報サイトを調査することなく、ログを取り込んだ瞬間に危険度（Verdict）を即座に特定できる環境が整います。

2. ファイルハッシュ優先判定順序の仕様

ログイベント内に同一ファイルの複数のハッシュ値（SHA256、SHA1、MD5）が記録されている場合、Google SecOps は無差別にすべてのハッシュで VirusTotal API クエリを発行するわけではありません。API 呼び出しの効率化と判定精度の最大化のため、厳密な優先順位に従って単一のプライマリハッシュを選択し、クエリを実行します。

判定順序の優先位階

  1. 最優先：SHA256
    • ハッシュ衝突のリスクが極めて低く、世界的に標準的な識別子として扱われるため最優先で評価に使用されます。
  2. 第2優先：SHA1
    • SHA256 がログに含まれていない場合、代替として SHA1 が使用されます。
  3. 最下位：MD5
    • SHA256 も SHA1 も存在しない場合にのみ使用されます。MD5 はハッシュ衝突の可能性が存在するため、他ハッシュが利用可能な場合は優先度が下がります。
【ログ内のハッシュ評価フロー】
[ ログイベント受信 ]
      │
      ├── SHA256 が存在するか？ ──(Yes)──> SHA256 をクエリキーとして使用
      │        │(No)
      ├── SHA1 が存在するか？ ────(Yes)──> SHA1 をクエリキーとして使用
      │        │(No)
      └── MD5 が存在するか？ ─────(Yes)──> MD5 をクエリキーとして使用

3. IP・ドメイン・URL アーティファクトとの並行処理仕様

ファイルハッシュの優先選択が行われる一方で、ログ内に含まれるネットワーク系アーティファクト（IPアドレス、ドメイン名、URL）は、ファイルハッシュの検索結果を待つことなく独立して並行（非同期）に VT v3 / GTI と照合されます。

  • ファイルハッシュ：上記の優先順序（SHA256 > SHA1 > MD5）で特定された 1 つのハッシュ値を照合。
  • IP / ドメイン / URL：ログ内の各フィールド（target.ip、target.hostname、target.url など）から抽出され、ファイルハッシュと並行してインテリジェンスデータベースと突合。

この並行処理設計により、ファイル判定とネットワーク判定が短時間で完了し、インジェスチョン遅延を発生させずに高度なコンテキストの拡充が可能となります。

4. UDM へのマッピングと YARA-L ルールでの活用

VirusTotal v3 から取得された解析結果（脅威判定、検知エンジン数、判定カテゴリ等）は、UDM 内の security_result コンテクスト構造体へと自動マッピングされます。

  • security_result.threat_verdict: MALICIOUS（悪意あり）、SUSPICIOUS（不審）、BENIGN（安全）などの統合ステータスがセットされます。
  • security_result.threat_name: 検知されたマルウェアファミリー名や脅威分類が記録されます。

これにより、YARA-L 2.0 検出ルールにおいて、外部インテリジェンスの判定結果を直接条件式に組み込むことが容易になります。

rule virustotal_malicious_file_execution {
  meta:
    description = "VirusTotalで悪意ありと判定されたファイルの実行を検知"
    severity = "CRITICAL"

  events:
    $event.metadata.event_type = "PROCESS_LAUNCH"
    // VirusTotal v3のエンリッチメント結果を参照
    $event.security_result.threat_verdict = "MALICIOUS"

  condition:
    $event
}

Google SecOpsのVirusTotal連携とアーティファクトエンリッチメントを解説のまとめ

Google SecOpsでは、VirusTotal v3やGoogle Threat Intelligence（GTI）との連携によって、ログに含まれるファイルハッシュやIPアドレス、ドメイン、URLなどのアーティファクトをエンリッチメントできます。ファイルハッシュについては、SHA256、SHA1、MD5の優先順位に基づいて照合対象が選択される点が重要です。

また、ネットワーク系アーティファクトはファイルハッシュとは独立して処理され、取得した脅威インテリジェンス情報がUDMのセキュリティコンテキストに反映されます。これらの仕組みを理解することで、外部脅威インテリジェンスを活用した検出ルールの設計やSOCでの調査に役立てられます。

PSOE試験対策としても、アーティファクトエンリッチメントの対象や処理の仕組みを理解しておきましょう。

まとめ

今回は、下記３点について説明しました。

  1. Google SecOpsのユーザーエンリッチメントとエイリアス解決
  2. Google SecOpsのプロセスエンリッチメントとPSPIを解説
  3. Google SecOpsのVirusTotal連携とアーティファクトエンリッチメントを解説

Google SecOpsのプロセスエンリッチメントでは、プロセスに関する情報を強化し、親子関係を含めた実行コンテキストを把握することが重要です。

OSのPIDは再利用される可能性があるため、EDRが提供するPSPIを利用することで、特定のプロセス実行インスタンスをより正確に識別できます。CBNでは、EDRから取得したプロセスIDやPSPI、親プロセスの情報などをUDMの適切なフィールドへマッピングする必要があります。正しく正規化されたプロセス情報は、プロセスツリーを利用した脅威調査や検出ルールの設計に活用できます。

PSOE試験対策として、PSPIの目的とUDMにおけるプロセス情報のマッピングを押さえておきましょう。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログ！

スポンサーリンク
タイトルとURLをコピーしました