G-gen の武井です。当記事では、Google Cloud が提供するセキュリティ運用プラットフォームである Google SecOps を徹底解説します。

Google SecOps とは

概要

Google Security Operations（以下、Google SecOps、旧称 Chronicle）は、SIEM、SOAR、脅威インテリジェンス、AI（Gemini）を統合した Google Cloud のセキュリティ運用プラットフォームです。

従来のセキュリティ運用では、ログの収集・検索、検知ルールの管理、インシデントの調査や対応といったプロセスがそれぞれの製品・ツールごとに分かれており、運用面に課題がありました。

Google SecOps はこれらを一つのクラウドネイティブな基盤上で統合し、ログ分析 > 脅威検知 > 調査 > 自動対応を一気通貫で実現します。

Google の大規模インフラが可能にするスケーラビリティ、Mandiant / VirusTotal などを含む豊富な脅威インテリジェンス、そして Gemini による自然言語での運用支援により、これまで専門知識や人材に依存していた作業を効率化できるのが大きな特徴です。

参考 : Google SecOps overview

主な特徴

Google SecOps の主な特徴は以下の通りです。

特徴	説明
スケーラブル	ペタバイト級のログ検索や数万件規模のルール実行に対応し、大規模環境でも高性能を維持
料金体系	ログデータ量（GB/年）を基本軸としたシンプルな料金体系
Gemini による運用支援	自然言語での質問やアウトプットの生成が可能で、専門知識がなくても効率的な運用が可能
脅威インテリジェンス	Google Threat Intelligence に加え Mandiant や VirusTotal の知見を活用し、最新の攻撃や Indicators of Compromise（IoC、侵害の兆候）を迅速に検知
SOAR 機能	アラート管理から Playbooks による自動対応まで一貫して提供し、SOC 運用を効率化

主な機能

Google SecOps の主な機能は以下の通りです

機能	説明
Investigation （調査）	ログやエンティティ（ユーザー・端末・IPなどの対象）を検索し、不審な挙動を調べる
Detection （検知）	ルール、IoC、UEBA（行動分析）に基づきアラートを生成
Cases （管理）	複数のアラートを「ケース」として集約管理（＝インシデント対応の単位）
Response （対応）	Playbooks でアラート通知後の対応を自動化
Dashboards （可視化）	検知状況をダッシュボードやレポートで把握
Marketplace （拡張）	検出ルールや Playbooks を追加拡張
API （設定）	UI に加えプログラマブルな設定、自動化、外部連携が可能

エディションと料金体系

Google SecOps には Standard、Enterprise、Enterprise Plus の3エディションがあり、いずれのエディションにおいても取り込んだログデータ量（GB単位/年）が基本的な料金軸です。

Standard エディションでは Gemini AI や Google Threat Intelligence が使用できないため、基本的には Enterprise もしくは Enterprise Plus エディションが推奨されます。

BigQuery UDM ストレージは SIEM と SOAR のデータを BigQuery にエクスポートするための、Enterprise Plus エディションのみが利用可能な機能となります。

機能	Standard	Enterprise	Enterprise Plus
SIEM / SOAR の基本機能	〇	〇	〇
Curated Detections（Google 提供の検出ルール）	–	〇	〇
UEBA（ユーザーとエンティティの行動分析）	–	〇	〇
Gemini AI による運用支援	–	〇	〇
Google Threat Intelligence	–	〇	〇
Mandiant / VirusTotal との統合	–	–	〇
BigQuery UDM ストレージ	–	–	〇

参考：料金

Google SecOps は Google Cloud と統合されていますが、オーダー方法などが他の Google Cloud プロダクトとは異なる特殊なプロダクトです。オーダーや料金等に関する詳細については、Google または販売パートナーのセールス担当者にお問い合わせください。

用語と機能

Security Information and Event Management（SIEM）

組織内の様々な IT システムリソース・機器、アプリケーションから、膨大な量のログやデータが日々出力されています。これらのログには、IT リソースに対する攻撃の痕跡や兆候も記録されていますが、単純に1つ1つのログを閲覧するだけでは気付くことが出来ません。

Security Information and Event Management（SIEM）はこれら大量のログを一元的に収集し、リアルタイムに相関分析し、攻撃や脅威の兆候、つまり不審なアクティビティや攻撃のパターンを自動的に検出するソリューションです。

SIEM により、セキュリティ運用者は全体像の把握が容易になり、運用の効率を飛躍的に向上させることができます。

参考：Google Security Operations SIEM overview

Security Orchestration, Automation, and Response（SOAR）

Security Orchestration, Automation, and Response は「セキュリティオーケストレーション、自動化、レスポンス」を意味しており、通常は SOAR と略されて呼称されます。SOAR は、SIEM によって脅威が検知された後の対応プロセスを自動化・効率化するためのソリューションです。

参考：Google Security Operations SOAR Overview

インシデントが発生した際、アナリストは影響範囲の調査、関連情報の収集、隔離措置、関係者への報告など、多くの手作業に追われます。SOAR は、これらの定型的な作業を Playbooks（プレイブック）と呼ばれる一連のワークフローとして定義し、自動で実行させることができます。

例として、以下のような作業を Playbooks により自動化できます。

疑わしい IP アドレスやドメインのレピュテーション（評判）を外部の脅威インテリジェンスサービスに問い合わせる
不審なファイルが見つかった場合、サンドボックス環境で実行してその挙動を分析する
感染が疑われるエンドポイントをネットワークから自動的に隔離する
担当者へ Slack やメールで通知し、JIRA などのチケット管理システムにインシデントを起票する

Cloud-Native Application Protection Platforms（CNAPP）

Cloud-Native Application Protection Platforms（CNAPP）とは、クラウドネイティブアプリケーションの環境全体を保護するために設計された、統合的なセキュリティプラットフォームのことを指します。

従来のセキュリティ対策は仮想マシン（VM）が中心でした。しかし、コンテナやサーバーレスが中心となるクラウドネイティブ環境では、開発から本番稼働までのライフサイクル全体でセキュリティを確保する必要があります。CNAPP は、これまで別々のツールだった以下の機能を、1つのプラットフォームに統合します。

ツール名	説明
CSPM（Cloud Security Posture Management）	クラウドの設定ミスや脆弱性を検出し、コンプライアンスを維持
CWPP（Cloud Workload Protection Platform）	コンテナやサーバーレスファンクションなど、実行中のワークロードを保護
CIEM（Cloud Infrastructure Entitlement Management）	過剰な権限を持つ IAM ユーザーやサービスアカウントを検出

Security Command Center

Google Cloud では、Security Command Center（SCC）が CNAPP としての役割を担い、Google Cloud 環境のアセットを自動的に検出し、潜在的なリスクや脅威を可視化します。

主な機能は以下の通りです。

不審な API コールやマルウェア、暗号通貨マイニングなどの脅威をリアルタイムで検出する
VM やコンテナイメージに存在する OS の脆弱性をスキャンし、優先順位をつけて管理・報告する
「ストレージバケットが意図せず公開されている」「ファイアウォールルールが緩すぎる」といった設定上の問題を特定・可視化する
CIS ベンチマークなどの業界標準に準拠しているかを継続的に評価する

SCC で検知した脆弱性や設定ミス、脅威イベントを Google SecOps に取り込むことで、検知後の対応を自動化することも可能です。

また、Enterprise ティアを利用している場合は Google SecOps の一部機能（ケースやアラートの管理、Playbooks など）を SCC の拡張機能として利用することもできます。

Security Command Center は、Google SecOps とは別プロダクトとして位置づけられており、Google Cloud の中でスタンドアロンのプロダクトとしても使用できます。Security Command Center についての詳細は、以下の記事も参照してください。

blog.g-gen.co.jp

Mandiant と Google Threat Intelligence（GTI）

Google は独自の脅威インテリジェンスデータベースとして Google Threat Intelligence（GTI）を運用しています。Google SecOps はこの GTI と連携し、組織内に存在する既知の脅威をリアルタイムで検知します。

参考 : Google Threat Intelligence - 攻撃者を把握 | Google Cloud

一方で攻撃側も日々新しい手法やツールを考案し、既存のナレッジで検出できない攻撃を仕掛けてきます。これに対応するために、Google のセキュリティチームが世界中のネットワークを監視しています。Mandiant サイバーセキュリティコンサルティングもそのうちの一つであり、GTI の運用だけでなく、顧客に対するセキュリティコンサルティングサービスを提供しています。

参考 : Mandiant サイバーセキュリティコンサルティング | Google Cloud

VirusTotal

VirusTotal は、指定されたファイルや URL がマルウェアで汚染されていないかを確認することができるウェブサービスです。また、セキュリティ研究者向けの機能や、エンタープライズ向けの有償サービスも提供しています。

Google SecOps は VirusTotal と連携しており、SecOps が発見した IoC を VirusTotal で確認・可視化することなどが可能です。

参考 : VirusTotal
参考 : VirusTotal の情報を表示する | Google Security Operations | Google Cloud

Gemini

Google SecOps には、Google の生成 AI「Gemini」が統合されており、セキュリティ運用にかかる負担を大幅に軽減できます。

後述する検索クエリの作成、脅威検出ルールや Playbooks の設計、アラートの根本原因調査など、専門知識に依存する作業を自然言語で支援し、人手での試行錯誤やそれに伴う工数を削減します。

参考：Use Gemini in Chronicle SecOps

データ取り込み（SIEM）

概要

Google SecOps は、Google Cloud や Google Workspace に加え、数多くの外部製品との連携が可能です。

そのため、分散していたログ管理を Google SecOps に集約し、単一のビューで相関的な分析と脅威検知ができます。

参考：Google SecOps ログの取り込み

Google SecOps のログ取り込みには以下のような方法があります。

名称	説明
直接取り込み	Google Cloud や Google Workspace から直接 SecOps にログを挿入
データフィード	Amazon S3 やサードパーティ API などから SecOps にログを挿入
Cloud Run functions	Google 提供の Python スクリプトから SecOps にログを挿入
Forwarders	Linux / Windows Server 等にインストールするエージェント
Bindplane	Linux / Windows Server 等にインストールするエージェント
Ingestion APIs	Google SecOps が用意するデータ取り込み用 API

直接取り込み

Google Cloud および Google Workspace に関するログデータは、Cloud コンソールや Google SecOps 専用の管理コンソール（以下、SecOps UI）から直接取り込めます。

Cloud Logging のログ
Cloud Asset のメタデータ
Security Command Center の検出結果
Google Workspace アクティビティログ

直接取り込みによるログ連携はシンプルな操作で完結します。詳細は以下をご確認ください。

データフィード

Google SecOps では、AWS、Azure、その他 SaaS など、Google Cloud 以外の環境のログデータを取り込む仕組みとしてデータフィード機能があります。

SecOps UI もしくは Feed Management API を用いて、ログソース（Amazon S3、Cloud Storage、Pub/Sub、Webhook など）を指定し、各種ログを SecOps に取り込む設定を行います。

ソースタイプ	概要
ストレージ	Google Cloud、AWS、Azure のクラウドストレージバケットに保存されたログデータを定期的に取得
Amazon SQS	S3 バケットの通知をキュー経由で受信し、ログデータを取得（リアルタイムかつ安定的に取り込み）
ストリーミング	Amazon Data Firehose、Cloud Pub/Sub、Webhook などを経由し、SIEM の HTTPS エンドポイントにログデータをストリーミングでプッシュ
サードパーティ API	CrowdStrike、SentinelOne、Palo Alto など、外部 SaaS から API 経由でログデータを取得

参考：フィード管理の概要

Cloud Run functions

データフィードに対応していない SaaS のログデータの取り込みや、取り込み前にログデータを整形・フィルタリングしたい場合、Cloud Run functions を使用してログデータを取り込めます。

Box や Trend Micro など、一部の SaaS については Google が作成した Python スクリプト（Cloud Run functions でデプロイする前提のコード）が提供されています。

Pub/Sub を除くすべてのスクリプトは、ソースデバイスから定期的にデータを収集するように実装されています。

参考：Cloud Run functions としてデプロイされた取り込みスクリプトを使用する

Bindplane

概要

Linux や Windows といったクラウドやオンプレミス上のサーバーのログやテレメトリデータの取り込みには、Bindplane と呼ばれる収集エージェントが使用できます。

Bindplane では収集したデータを正規化したり、正規表現に一致するログを削除したりするなどのエンリッチメントが可能で、単なる収集エージェントというよりは、テレメトリパイプラインとして位置づけられています。

参考：Google SecOps で Bindplane を使用する

エディション

Google SecOps では Bindplane（Google エディション）が無料で利用できます。

さらに、Enterprise Plus エディションを契約しているの場合、上位互換にあたる Bindplane Enterprise（Google エディション）も無料で利用できます。

参考：Bindplane の Google エディション

以下の用途で Bindplane を使用する場合、Bindplane Enterprise が推奨されます。

大規模環境でのログデータ取り込み
正規表現以外の高度なフィルタリング機能を使用したログデータ加工
個人情報（PII）の秘匿化

構成要素

Bindplane は以下の3つに分類されます。

コンポーネント	役割
Server	Bindplane の管理サーバーで、Controller（エージェント）の集中管理を担う
Collector	旧称 Bindplane Agent、ログやテレメトリデータの転送を行うエージェント
Gateway	セキュリティ上の都合で直接データ転送ができない Collector に代わってデータを中継・転送するゲートウェイサーバー

参考：ゲートウェイコレクタをファイアウォールで保護する

Bindplane Server

Bindplane Server は Bindplane の管理コンソールです。

Bindplane を統括的に運用・管理するコンポーネントで、複数の Collector や Gateway の運用を一元管理するためには必須です。

主な機能	説明
集中管理	Collector や Gateway の起動/停止/再起動といった管理タスクの実行やステータス表示
モニタリング	Collector や Gateway の CPU 使用率、メモリ使用率、スループットなどの指標を追跡
アラート通知	Collector や Gateway がダウンした場合や指標のしきい値を超えた場合など、重要なイベントのアラートと通知
構成管理	Collector や Gateway の構成ファイルの編集、環境変数の設定などを適用
管理画面	Web UI からの操作・設定変更を提供

参考：Bindplane 管理コンソール

Collector や Gateway のデプロイパターン

Bindplane には、環境や用途に応じて、いくつかのデプロイパターンが用意されています。

参考：Bindplane エージェントのアーキテクチャ

パターン1：Bindplane Collector をフォワーダーとして機能させる方式

例：Linux サーバーやネットワーク機器などから Syslog を Bindplane Collector に集約し、Google（Google SecOps や Cloud Logging）にログを送信

パターン2：Bindplane Collector から直接送信する方式

例：Syslog 出力に対応していない Windows などの場合、Bindplane Collector をエージェントとして直接インストールし、Google にログを送信

パターン3：Bindplane Collector が複数の Google 送信先にログを送信する方式

例：Google SecOps と Cloud Logging の両方同時にログを送信（SecOps は分析用途、Logging は監査用途といった具合の使い分け）

パターン4：Bindplane Gataway 経由でログを転送する方式

例：セキュリティ上の都合で直接データ転送ができない環境において、Bindplane Gataway を介して Google にログを送信

Forwarders（非推奨）

Bindplane の他にも Forwarders と呼ばれる Google SecOps 純正の収集エージェントがありますが、対応するフォーマットに限りがあるなど、Bindplane と比べると性能面で劣ります。

Forwarders は2027年1月に提供が終了する予定です。これらから Forwarders は非推奨であり、今後、収集エージェントを利用する場合は Bindplane が推奨されます。

参考：フォワーダーをインストールして構成する
参考：Feature deprecations

Ingestion API

Ingestion API は、収集エージェントを使用せずに、アプリケーションやシステムから直接 Google SecOps にログデータを送信するための API インターフェイスです。

これにより、オンプレミス・クラウド・SaaS などの多様な環境から、プログラマブルに効率よくデータを取り込むことができます。

主な特徴	説明
エージェント不要	Bindplane や Forwarder を介さず、API 経由で直接 SecOps にログを送信
高い柔軟性	非構造化ログ、SecOps 向けに正規化した UDM ログを送信
重複排除	各ログに付与される一意のバッチ ID に基づき重複処理を防止

Ingestion API には、以下のような API メソッドが用意されています。

メソッド	説明
udmevents	UDM イベント（UDM 形式のログ）を送信
unstructuredlogentries	非構造化ログをそのまま送信し、Google SecOps 側で正規化
entities	ログ内のユーザー・端末・IP などをエンティティとして登録
logtypes	サポートされているログタイプのリストを取得

参考：Ingestion API

ログの正規化（SIEM）

パーサーと UDM

Google SecOps は多様な製品のログを取り込めますが、当然ながら各製品ごとログフォーマットは異なります。

Google SecOps では、各製品のログが SecOps に送られると、パーサー（parser）というコンポーネントで UDM（Unified Data Model）形式にパースされます。

これにより、異なる製品の異なるフォーマットのログが1つの形式に統一され、SecOps による分析や脅威検知に利用できるようになります。

以下はベンダーが異なる Firwall 製品のログを UDM で正規化したイメージです。

項目	ベンダー A のログ形式	ベンダー B のログ形式	UDM のログ形式
送信元 IP	src=1.2.3.4	srcip=10.3.4.5	principal.ip
宛先 IP	dst=2.3.4.5	dstip=20.3.4.5	target.ip
宛先 Port	dstPort=55323	dstport=443	target.port
アクション	deny	action="deny"	security_result.action

参考：統合データモデルの概要

UDM の構造

UDM は Google SecOps に取り込まれたログデータを統一的に扱うための共通スキーマ（データモデル）であり、大きく分けて次の2つの構成要素から成ります。

コンポーネント	説明
イベント	発生したセキュリティイベントやアクティビティの情報（ログの本体に相当）
エンティティ	イベントの主体（ユーザー・端末・IP 等）に関するコンテキスト（背景情報）

このようにイベントとエンティティの両方を定義することで、「誰が」「どこから」「何をしたか」を明確にし、脅威のトリアージや相関分析を効率的に行えるようになります。

参考：UDM の構造
参考：論理オブジェクト: イベントとエンティティ

UDM イベント

UDM イベントは、セキュリティ関連の出来事そのものを表し、例えば、「ユーザーがログインした」、「ファイルが削除された」、「ファイアウォールが通信を拒否した」といったアクションを、UDM の標準化されたフィールドで記述します。

イベントには以下のような情報が含まれます。

セクション	説明	主な項目例
Metadata	イベントに関連する一般的な情報。タイムスタンプや製品情報など、イベントのメタデータを保持	`event_timestamp`, `event_type`, `product_name`, `vendor_name` など
Nouns	アクティビティに関与したエンティティ（主体）。ユーザー、端末、プロセス、IP などが該当	`hostname`, `ip`, `mac`, `user`, `process` など
Security_result	イベント内で特定されたリスクや脅威、またはそれらを軽減するために取られた措置に関する情報	`rule_name`, `severity`, `action`, `threat_name` など
Network	イベントに含まれるネットワークの詳細情報（セッション ID、送受信バイト数など）	`session_id`, `direction`, `ip_protocol`, `sent_bytes`, `received_bytes` など

参考：UDM イベントの構造

UDM エンティティ

UDM エンティティは、イベントに関連する登場人物やオブジェクトに関する文脈情報を補足するものです。例えば、「攻撃元の IP」、「実行ユーザー」、「対象となる端末やアプリケーション」などが該当します。

UDM では、これらのエンティティを次のような役割に分類して整理します。

セクション	説明	主な項目例
Metadata	エンティティに関する一般的な情報や、エンティティを生成した製品情報を保持（収集タイムスタンプ、間隔、製品名などのメタデータを含む）	`product_entity_id`, `entity_type`, `product_name`, `vendor_name` など
Entity	このエンティティが表す名詞（noun）を定義します。ユーザー、アセット、ドメイン、IPアドレスなど、イベント内で識別される対象が該当	`asset`, `user`, `resource`, `namespace`, `labels` など
Relation	当該エンティティと他のエンティティとの関係性を示す	`relationship`, `entity`, `entity_type`, `direction` など

参考：UDM エンティティの構造

UDM フィールド

UDM イベントとエンティティの全フィールドについては以下のドキュメントに網羅されています。

参考：UDM field list

ただし、UDM のフィールド数は膨大なため、SecOps における主要なフィールドについては別途以下のドキュメントも用意されています。

例えば後述するデフォルトパーサーで取り込めないログタイプ（取り込み対象のデータソース）をカスタムパーサーで取り込む場合の指標としても使えます。

参考：Key UDM fields for parsers

デフォルトパーサー

デフォルトパーサー（事前構築済みパーサー）とは、オリジナルのログデータを UDM フィールドに変換するためのデータマッピングがあらかじめ組み込まれた、Google によって管理・提供されるパーサーのことです。

デフォルトパーサーのリストは、以下のドキュメントで確認できます。

参考 : Supported log types and default parsers

また、サードパーティ製品側でのログフォーマットの変更にデフォルトパーサーの更新が追いついていない場合や、既存のデフォルトパーサーを拡張したい場合などは、パーサー拡張機能（Parser extensions）を使うことで、既存のパーサーをベースとしながらフィールドを追加したりフィールド名を変更したりできます。

製品側の急な変更にできる限り小さい労力で対応するには、この機能を使います。

参考：Parser extensions

カスタムパーサー

取り込み対象の製品向けのデフォルトパーサーが存在しない場合、カスタムパーサーを使用して独自のデータマッピングをユーザー側で記述します。

カスタムパーサーのリストは、以下のドキュメントで確認できます。

参考：Supported log types without a default parser

パーサーの管理

パーサーは SecOps UI や Google SecOps CLI（secops）から管理します。

デフォルトパーサーの表示
デフォルトパーサーのアップデート管理
パーサー拡張機能の作成管理
カスタムパーサーの作成管理

なお Google SecOps CLI は chronicle_cli の後継にあたり、パーサーの管理以外にも、フィードの管理や検出ルールの管理など、Google SecOps の様々な機能の管理にも使用されます。

参考 : Manage prebuilt and custom parsers
参考：Parser Management

脅威検知（SIEM）

インテリジェンスと IoC Matches

Google SecOps は、Mandiant、VirusTotal、Google Threat Intelligence（GTI）などの、備え付けの脅威インテリジェンスソースによってキュレーション（推奨）された IoC を自動的に取り込む（ingest）ようになっています。

これらのインテリジェンスは、SecOps に取り込まれた後、UDM イベントデータの継続的な分析に使用されます。これにより、既知の悪意のあるドメイン、IPアドレス、ファイルハッシュ、URL に一致する IoC が自動的に発見され、一致が見つかった場合はアラートが生成されます。（IoC Matches）

参考：Google SecOps で IoC が自動的に照合される仕組み

Curated Detections

IoC Matches とは別に、特定の脅威カテゴリをカバーできるよう、Curated Detections と呼ばれるマネージドなルールセットがあります。

Curated Detections を使用する場合、Enterprise エディション以上の契約が必要です。また UEBA や Applied Threat Intelligence については Enterprise Plus エディションの契約が必要です。

脅威カテゴリ	カバーするルールセット
Cloud Threats	Google Cloud、AWS、Azure、Office 365、Okta
Chrome Enterprise Threats	Chrome 拡張機能の脅威、Chrome ブラウザの脅威
Windows Threats	異常な PowerShell、暗号通貨マイニング、ランサムウェアなど
Linux Threats	権限の昇格や変更、マルウェアによる不審なアクティビティ、Mandiant が評価した脅威など
macOS Threats	Mandiant が評価した脅威
Risk Analytics for UEBA	認証、ネットワークトラフィック、ピアグループ、不審なアクティビティ、データ損失
Applied Threat Intelligence	Mandiant Threat Intelligence によるネットワークやホスト関連の IoC 特定

参考：Use the curated detections page

Curated Detections の使用方法

Curated Detections は対象のログソースがある状態で、SecOps UI から一括あるいは個別に有効化するだけで使用可能となります。

有効化の際、ルールの動作モードとして Precise（高精度）と Broad（広範囲）を選択できます。

前者の場合、信頼性の高いアラートを生成するため誤検知が少なくなります。一方後者の場合はヒューリスティックなアラート検出を行うため、異常検知をしやすくなる反面、誤検知の可能性も高くなります。

参考：Modification of all the rules in a rule set

YARA-L ルール

パーサーによって正規化され UDM となったイベントデータは、前述のとおり Google のインテリジェンスによって自動的に分析されますが、独自の検知ルールを定義したい場合は YARA-L 2.0 という構文を用いて記述することができます。

参考：YARA-L 2.0 言語の概要

YARA-L 2.0 は UDM に対する検索にも用いられます。また YARA-L 2.0 の記述には、生成 AI モデルであるGemini の力を借りることもできます。ルールエディタで Gemini に対して自然言語で目的などを指示することで、YARA-L ルールを記述することができます。

参考：Gemini を使用して YARA-L ルールを生成する

YARA-L ルールの基本構造

YARA-L ルールはルール名と最大6つのセクションから構成されます。

セクション	必要性	説明
meta	必須	ルールに関するメタデータ（Key-Value）で、`author`、`description`、`severity`、`version` など
events	必須	検出対象とする UDM イベントの条件を定義。SQL の `WHERE` 句に相当し、演算子を省略した場合は自動的に `and` が適用
match	任意	events セクション内で定義した変数を基に検出イベントをグループ化。SQL の `GROUP BY` に相当
outcome	任意	検知結果に含めたい追加情報。例えば `count()` や `array_distinct()` 関数を用いて、検出対象の件数や一覧を出力
condition	必須	検知をトリガーする条件。例えばイベント変数 `$e` を使用し、条件が一致した場合にルールをトリガーするように定義
options	任意	ルールの実行方法の制御で使用し、2025年10月現在、設定できるのは `allow_zero_values = true`（マッチ結果が空でもルールをトリガーする）のみ

参考：YARA-L 2.0 language syntax

YARA-L ルールの変数

YARA-L では、ルール内で UDM イベントを柔軟に扱うために変数（$variable の形式）と特殊文字が使用できます。

以下のサンプルルールは、Office 365 への macOS 端末からのログインイベントを識別するルールであり、ユーザーIDとIPアドレスを変数化し、30分間の同一組み合わせをグループ化しています。

rule office365_mac_os_login {
  
  meta:
    author = "ACME Corp"
    description = "Identifies an Office 365 login on a mac os"
    severity = "Low"
  
  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.metadata.log_type = "OFFICE_365"
    $e.principal.platform = "MAC"
    $e.security_result.action = "ALLOW"
  
    $e.target.user.userid = $account
    $e.principal.ip = $ip
  
  match:
    $account, $ip over 30m
  
  outcome:
    $target_user_userid = array_distinct(strings.to_lower($e.target.user.userid))
    $security_result_summary = array_distinct($e.security_result.summary)
  
  condition:
    $e
  
  options:
    allow_zero_values = true
}

変数	使用セクション	説明
イベント変数	`events` `outcome` `condition`	UDM イベントそのものを表す変数で、events セクションを `$e` と宣言してイベント全体を参照し、condition セクションで検知条件として指定
プレースホルダー変数	`events` `match` `outcome` `condition`	イベント内の特定のフィールドの値を一時的に保持する変数。 `$e.target.user.userid = $account` のように設定し、他イベントや時間範囲で比較・グループ化するために使用
一致変数	`match`	複数のイベントをグループ化するための変数。 SQL の `GROUP BY` に相当し、同一アカウント・同一 IP などの条件でイベントをまとめる。例：`match: $account, $ip over 30m`（30分間の同一ユーザーと IP の組み合わせをグループ化）

参考：変数

YARA-L ルールの特殊文字

変数の前に # を付けると、その変数にマッチしたイベントの件数をカウントできます。

これはカウント文字と呼ばれる特殊文字で、主に condition セクションで使用します。

例えば以下は、同一ホストから複数ユーザーのログイン失敗が発生した場合を検出するルールです。

rule win_password_spray_kc {
  
  meta:
    author = "Chronicle Security"
    description = "Detect repeated authentication failure with multiple users from a single origin."
    severity = "Low"
  
  events:
    $event.metadata.event_type = "USER_LOGIN"
    $event.metadata.vendor_name = "Microsoft"
    $event.security_result.action = "BLOCK"
    $event.principal.hostname = $principalHost
    $event.target.user.userid = $targetUser
  
  match:
    $principalHost over 30m
  
  outcome:
    $targetUser_distinct_count = count_distinct($targetUser)
    $targetUser_uniq_list = array_distinct($targetUser)
  
  condition:
    #targetUser > 10
}

上記サンプルにおける condition セクションのカウント文字#targetUser > 10は、そのホストから10件を超える異なるユーザーの失敗イベントがあった場合を検知ルールのトリガー条件としています。

参考：カウント文字

YARA-L ルールサンプル

Curated Detections とは別に、Google 管理の YARA-L ルールサンプルも提供されています。

Curated Detections の使用には Enterprise エディション以上の契約が必要ですが、こちらのルールサンプルはどのエディションでも無料で使用可能です。

詳細は以下の公式ドキュメントや GitHub をご確認ください。

参考：デフォルトの検出ルール
参考：detection-rules

ログの検索

Google SecOps の SIEM では、Raw Log Search と UDM Search の両方が利用可能です。

Raw Log Search は取り込まれた生ログ（UDM 化される前のログデータ）を対象にし、UDM 検索は正規化されたイベントを検索対象とします。

生ログは、主にデータ取り込み状況の確認やパーサー動作の検証などのトラブルシューティング用途で利用されることが多く、日常的な分析や相関調査では UDM 検索を用います。

検索種別	概要	用途
Raw Log Search	各ベンダー固有フォーマットのログをそのまま検索。文字列一致や正規表現での検索が可能	データ取り込み確認、パーサーの検証、UDM 変換の確認など
UDM Search	SIEM に取り込まれたログを UDM スキーマに基づいて正規化し、共通フォーマットで検索可能	アラート調査、相関分析、ピボットテーブル・統計的検索の利用など

UDM 形式に正規化されたデータは、ベンダーごとの項目名や値のばらつきを吸収し、一貫したフィールド名・データ型・列挙値によって統一的な検索により、ログ検索時のフィールド抽出コストを削減し、迅速かつ標準化された分析が可能です。

参考：Use raw log search
参考：Search for events and alerts

ケース管理と対応自動化（SOAR）

ケースとは

Google SecOps の SOAR 機能では、SIEM で作成されたアラートをケースというチケットとして自動的にグルーピングし、SecOps UI でその後のライフサイクルを管理できる状態に整えます。

ケースとは、関連するセキュリティアラートやイベントを後述するメカニズムによってグルーピングしたもので、端的にまとめると類似した特徴を持つアラート群と言えます。

これにより、SIEM で検出した同一の脅威に関連する類似のアラートを効率的かつ効果的に管理することができます。

参考：Cases overview

ケース化のメカニズム

SOAR によるケース化の条件には以下の基準があります。

条件	説明
エンティティ	アラートに関与する主体（ユーザー・端末・IP アドレス等）が同一である
発生時刻	アラートの発生時刻が特定の時間帯で集中している
検出ルール	アラートが同一もしくは類似する検出ルールによって生成されている

なお、デフォルトのルールの調整や手動でケース化ルールを作成する場合は、SecOps UI の SOAR Setting から調整可能です。

参考：Configure an alert grouping

Playbooks

Playbooks（プレイブック）は、SOAR による自動化を実現するアクションの定義オブジェクトです。

Playbooks では、SIEM によって検知されたアラートに対してあらかじめ一連の対応手順を定義することで、自動または半自動でアクションを実行する仕組みです。これにより、対応プロセスを標準化・迅速化できます。

Playbooks の構成要素

Playbooks は次の4つの要素で構成されます。

要素	概要
トリガー（Trigger）	Playbooks を起動する条件。特定のアラートやイベントの発生時、またはスケジュールを契機に自動実行される
アクション（Action）	実行される処理。例えば「VirusTotal への照会」、「Jira チケット起票」、「ユーザーの無効化」など
フロー（Flow）	条件分岐や承認を制御する仕組み。自動判断やアナリストの入力を挟みながら次の処理を決定する
ブロック（Block）	再利用可能な処理単位。複数の Playbooksで共通利用できる部品化されたモジュール

Playbooks の管理

Playbooks は運用面を考慮した設計と継続的な改善が求められます。SecOps UI では、Playbooks の実行履歴や成功率、稼働環境ごとの傾向を可視化でき、運用状況を踏まえた最適化が可能です。

Marketplace を活用すれば、Google や外部ベンダーが提供する Playbooks や Block を追加・再利用できます。これにより、新しい検知ルールや自動化タスクを迅速に取り込み、既存ワークフローに統合できます。

また Gemini を利用することで、自然言語で「目的」「トリガー」「アクション」「条件」を指示するだけで Playbooks の雛形を生成でき、設計工数を大幅に削減できます。

一方で、Playbooks ですべてを自動化するのは現実的ではなく、次のような判断軸を持つことが重要です。

対応の種類	自動化の可否	例
定型的・繰り返し発生する対応	〇	ログイン失敗の調査、マルウェア検知後の隔離、レピュテーション照会など
分析や意思決定を伴う対応	△	インシデントの深刻度評価、例外対応、再発防止策の検討など（アナリストの判断が適宜必要なもの）