Professional Security Operations Engineer試験対策マニュアル

Google Cloud プロダクトを中心としたセキュリティオペレーション担当者向けの認定資格である Professional Security Operations Engineer 試験について、合格に向けて役立つ情報をご紹介します。

試験情報

PSOE 試験とは

Professional Security Operations Engineer 試験（以下、PSOE）は、セキュリティオペレーションの知識を問う Google Cloud 認定資格です。2025年7月〜8月にベータ試験が公開され、2025年9月に GA（一般公開）となりました。

Google ならびに Google Cloud が持つセキュリティオペレーション製品、特に Google Security Operations（略称 Google SecOps）と Security Command Center（SCC）を中心に、攻撃の検知や防衛・対応に関する技術的な知識からインシデント管理の体制に関するものまで、包括的に問われる試験です。開発者向けというよりは、セキュリティオペレーションセンター（SOC）やネットワークオペレーションセンター（NOC）、また情報システム部のセキュリティ部門に所属しているような、セキュリティ対応を主な役割とするエンジニア向けの試験となっています。

他のプロフェッショナル資格と同じく、試験時間は120分、問題数は50〜60問の選択式です。認定の有効期間は2年間です。

当試験は、2025年9月時点で英語版のみが提供されています。

• 参考 : Professional Security Operations Engineer

難易度

PSOE 試験の難易度は、Google Cloud 認定資格の中でも比較的高いといえます。

公式ガイドでは「3年以上のセキュリティ業界経験」「1年以上の Google Cloud におけるセキュリティツール群の利用経験」が求められると記載されています。当試験で中心的に扱われる Google のセキュリティ製品は有償のものが多く、またある程度の規模感をもつ組織でないと導入されない性質です。これらの製品を普段から業務で扱っているエンジニアは少なく、またインターネット上に情報が豊富に公開されていないことが、当試験を難しくしています。

また2025年9月現在、当試験は日本語で受験できないこともあり、セキュリティ分野に特有の英単語の語彙が必要です。

逆に言えば、SOC や NOC、情報システム部のセキュリティ部門に所属されているなど、普段からこれらの分野の製品や用語、概念に英語で触れる機会のある人であれば、Google Cloud や対象プロダクトの知識を数日〜数週間程度かけて習得することで、十分に合格が可能です。

他の認定試験との違い

PSOE 試験は、Professional Data Engineer 試験（PDE）や Professional Machine Learning Engineer 試験（PMLE）と同様、その試験名に「Cloud」を含みません。このことからも分かるように、Google Cloud に閉じず、情報セキュリティ関係の広い知識が問われる試験となっています。

Professional Cloud Security Engineer 試験との違い

Professional Cloud Security Engineer 試験（PCSE）では情報セキュリティの知識が問われるものの、「Google Cloud をどうセキュアに利用するか」という開発者寄りの観点が主になります。

一方で PSOE は防衛組織寄りの、「どのようにして攻撃を検知し対応するか」が主に問われます。

Google Cloud をセキュアに扱うための IAM や Cloud Audit Logs といった知識は、共通して問われます。

• 参考 : Professional Cloud Security Engineer 試験 - Google Cloud
• 参考 : Professional Cloud Security Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog

Professional Cloud Network Engineer 試験との違い

ネットワークに関する知識と情報セキュリティは密接に繋がります。Professional Cloud Network Engineer 試験（PCNE）でも、ファイアウォールなどのネットワーク防御機能が問われます。しかし PSOE はより深く、例えば「ファイアウォールのログに攻撃の痕跡があったらどのように対処するか」といったことが問われます。

一方で PSOE にもアタックサーフェス（攻撃対象領域、後述）に関する知識が必要となるため、ネットワーク的な知見は必要です。

• 参考 : Professional Cloud Network Engineer 試験 - Google Cloud
• 参考 : Professional Cloud Network Engineer試験対策マニュアル - G-gen Tech Blog

Professional Cloud DevOps Engineer 試験との違い

「SecOps」「DevOps」という似通った表記の概念があるため、混乱する方もいらっしゃるかもしれません。さらに「DevSecOps」のような表現もあります。これらは見た目が似ているものの、それぞれ異なる分野の概念・用語です。しかしながら SRE やオブザーバビリティ（可観測性、 Observability、o11y）など、それぞれに通じるモダンな概念・指向・考え方は身につけておく必要があります。その意味では Professional Cloud DevOps Engineer 試験（PCDE）についての学習は役に立ちます。

• 参考 : Professional Cloud DevOps Engineer 試験 - Google Cloud
• 参考 : Professional Cloud DevOps Engineer試験対策マニュアル - G-gen Tech Blog

出題範囲と傾向

PSOE 試験は、以下の6つの分野から出題されます。

No.	セクションタイトル	出題数
1.	Platform operations（プラットフォームの操作）	約14%
2.	Data management（データ管理）	約14%
3.	Threat hunting（脅威ハンティング）	約19%
4.	Detection engineering（検出技術）	約22%
5.	Incident response（インシデント対応）	約21%
6.	Observability（可観測性）	約10%

傾向として、脅威・攻撃の検出とその対応に関する問題の比率が高くなっています。全体のうち20〜25問程度がこれに関する設問です。

各セクションにおいて具体的にどのような知識を問われるのかについては、試験ガイドをご参照ください。

• 参考 : Professional Security Operations Engineer Exam Guide | English - Google Docs

PSOE 試験の学習コンテンツ

他の Google Cloud 認定試験と同様に、公式には以下の学習コンテンツが用意されています。

• オンライントレーニング（Google Skills ラーニングパス）
• 模擬試験

オンライントレーニングは、Google Cloud の学習プラットフォームである Google Skills（旧称：Skills Boost）で公開されています。動画とテキスト、小テストと、実際に Google Cloud の操作を行うことができる「ラボ」を組み合わせたラーニングパスで、ウェブブラウザからいつでも受講することができます。

Google が推奨するインシデント管理手法を体系的に学ぶことができるうえ、Security Command Center など実際に扱う機会が少ないサービスもラボで操作することができるため、時間はかかりますが有効なラーニングパスだと言えます。

模擬試験は Google フォームを利用した簡易的なものですが、無料でチャレンジすることができますし、設問に対する解説や参考リンクも整備されています。出題傾向や、自分自身の不得意分野を知ることができるものになっています。

オンライントレーニングならびに模擬試験は、上述した 試験のランディングページ にあるリンクから開始できます。

当記事ではこのあと、試験の出題範囲において重要となるであろう基本的な知識を紹介します。学習を進めるうえで参考にしてください。

英単語の読み方

この記事で紹介する用語等について、一般的と考えられる読み方を紹介します。

用語	読み方
SIEM	しーむ
SOAR	そあー
CNAPP	しーなっぷ
MITRE ATT&CK	まいたーあたっく
Mandiant	まんでぃあんと
IEEE	あいとりぷるいー
SecOps	せっくおぷす

SIEM、SOAR、CNAPP

SIEM、SOAR、CNAPP とは

まず最初に、現代の IT セキュリティ戦略を語るうえで欠かせない、3つの概念について解説します。

• Security Information and Event Management（SIEM）
• Security Orchestration, Automation, and Response（SOAR）
• Cloud-Native Application Protection Platforms（CNAPP）

上記は情報セキュリティ製品の種類を表す一般名称です。これらの名称に対応する Google Cloud ソリューションは、以下の2つです。

• SIEM / SOAR→ Google Security Operations（Google SecOps）
• CNAPP → Security Command Center（SCC）

このあと、当試験の中心となる概念とソリューションについて順に解説しますが、先に各概念がセキュリティ戦略に対してどのように対応しているかを説明します。

セキュリティフレームワークにおける各々の役割

米国国立標準技術研究所（NIST）が策定したサイバーセキュリティフレームワーク（CSF）2.0 によると、セキュリティに関する「機能（Function）」として以下の 6 種類と体系化されています。

• 統治（GOVERN） - セキュリティリスクマネジメント戦略やポリシーなど
• 識別（IDENTIFY） - 現在発生中のセキュリティリスクの識別
• 防御（PROTECT） - セキュリティ防御策・対策
• 検知（DETECT） - 攻撃や侵害の可能性（インシデント）の発見・検出と分析
• 対応（RESPOND） - 検知されたインシデントに対するアクション
• 復旧（RECOVER） - インシデントの影響を受けたリソースや業務の復旧

これらの機能のうち、一般的に、SIEM は検知を、 SOAR は対応と復旧を担います。CNAPP は複合的な機能を持つ製品なので単純には分類できませんが、主に統治・識別と検知を担当すると言えるでしょう。つまり検知は、SIEM と CNAPP が互いの担当範囲のもと、連携して担うことになります。

残った防御は通常、ファイアウォールや WAF などのプロダクトが担当しますが、クラウド領域においては CNAPP がそれらを管理します。

• 参考 : セキュリティ関連NIST文書について - IPA 独立行政法人 情報処理推進機構

Security Information and Event Management（SIEM）

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

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

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

Security Orchestration, Automation, and Response（SOAR）

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

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

例として、以下のような作業をプレイブックにより自動化できます。

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

Google Security Operations（Google SecOps）

Google Cloud が提供する Google Security Operations（Google SecOps）は、SIEM と SOAR の役割を担う製品です。かつては Chronicle と呼称されていましたが、リブランディングに伴い製品名が変更されました。

Google SecOps は Google の持つ大規模なインフラと高度な脅威インテリジェンスを基盤としており、以下のような特徴があります。

特徴	説明
ペタバイト級のスケーラビリティ	クラウドネイティブなアーキテクチャにより、増え続けるログデータをコスト効率よく、高速に処理・分析
強力な検索と分析	Google のもつデータ分析基盤を活用、関連する様々な領域で生成 AI「Gemini」を統合
高品質な脅威インテリジェンス	Google の脅威分析チームなどから得られる最新情報に基づき、高精度な脅威検出ルールを自動的に適用
組み込みのインシデント管理機能	チーム対応を前提としたインシデント（ケース）管理機能
RBAC による権限管理	IAM とは独立したロールベースの権限管理機能
SOAR Marketplace	Playbook などを自前で開発しなくてもマーケットプレイスから調達可能

脅威インテリジェンスについては後ほど詳しく解説しますが、世界中で発生しているセキュリティリスクや攻撃の情報を蓄積したナレッジベースと言い換えることができます。ユーザーは Google SecOps を通じて、Google が持つ世界屈指のナレッジベースにアクセスすることができます。

また Google SecOps は、Amazon Web Services（AWS）や Microsoft Azure などのクラウドプラットフォームや、Sentinel One などの EDR 製品など、多くのサードパーティ製品が出力するログにも広く対応しており、オンプレミスやクラウドプラットフォーム、SaaS 製品などに関するあらゆるセキュリティ情報を集約することができます。

• 参考 : 最新の SecOps: セキュリティ運用のモダナイズ | Google Cloud

受験にあたっては、Google SecOps で何ができるかについて、以下の記事を参考にして把握しておく必要があります。

blog.g-gen.co.jp

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 (SCC)

Google Cloud では、Security Command Center（SCC）が CNAPP の役割を担います。SCC は、Google Cloud 環境全体のアセット（資産）を自動的に検出し、潜在的なリスクや脅威を単一のダッシュボードに集約して可視化します。

• 参考 : Security Command Center | Google Cloud

受験にあたっては、SCC で何ができるかについて、以下の記事を参考にして把握しておく必要があります。

blog.g-gen.co.jp

SCC が提供する主な機能は以下の通りです。

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

Google SecOps と SCC は、連携することでさらに強力になります。SCC が検出した重要な脅威や脆弱性の情報を Google SecOps に送信し、SOAR プレイブックを起動させることで、検出から対応までの一連のプロセスをシームレスに自動化できます。

このように、SIEM、SOAR、CNAPP はそれぞれ異なる役割を持ちながらも、連携することで強い効果を発揮します。Google Cloud は、これらの機能を統合されたプラットフォームとして提供することで、複雑化するクラウド環境のセキュリティ運用をシンプルかつ効果的に実現します。

SCC には多くの検知ルールが Google によって用意されており、有効化するだけで自動的にスキャンと検知が行われます。一方で、カスタムモジュールを構成することで、独自の検知ルールを作成することもできます。

• 参考 : Security Health Analytics 用のカスタム モジュールの概要
• 参考 : Event Threat Detection 用カスタム モジュールの概要

以下の記事も参考にしてください。

blog.g-gen.co.jp

アタックサーフェスとゼロ・トラスト

アタックサーフェス（Attack Surface）

SIEM や CNAPP がセキュリティを確保するための手段、「道具」であるとするなら、それらの道具で管理・保護すべき対象がアタックサーフェス（攻撃対象領域、Attack Surface）です。アタックサーフェスはその名の通り、攻撃者が狙ってくる「脅威の侵入口」といえます。これは、ソフトウェアの脆弱性、設定ミス、従業員の認証情報などの要素を含みます。

アタックサーフェスは、大きく以下の3つに分類できます。

• 外部からアクセス可能なあらゆるデジタルリソース（Web サーバー、API、クラウドストレージなど）
• 物理的なアクセスによって情報を盗み出せる場所やデバイス（データセンター、業務用の PC やスマートフォンなど）
• 担当者など、標的となりうる人物や組織（ソーシャルエンジニアリング、フィッシングメールなど）

従来、これらのアタックサーフェスは境界型セキュリティで防御していました。つまり「社内と社外」「ゲートウェイ型ファイアウォールの内と外」など、「ここから先は危険」「ここからのアクセスなら安全」と、領域を分けて考えていたのです。

しかしながらクラウドが普及するにつれて、アタックサーフェスはますます拡大し、複雑化しています。攻撃側も巧妙になり、例えばまず社内 PC にマルウェアを送り込み踏み台にしてデータセンターを狙うなど段階を踏むようにもなったため、「ここは安全」と無条件に信頼することができなくなりました。

この状況には、境界型セキュリティでは対処できません。そこで、「信頼できる領域がないことを前提とすべき」という考え方が広まりました。

ゼロ・トラスト（Zero Trust）

先にもふれた米国国立標準技術研究所（NIST）が公開した SP800-207「Zero Trust Architecture」によると、ゼロ・トラストの原則（Tenet）は以下の 7 つとされています。意訳して抜粋します。

1. 全てのデータと処理サービスは「リソース」とみなす
2. 全ての「通信」は、全ての場所で保護する
3. セッション単位の権限付与を基本とする
4. リソースへのアクセスは動的ポリシーで認可する
5. 企業は全ての保有資産の整合性とセキュリティ上の挙動を監視・計測する
6. 全てのリソースに対する認証認可は、アクセスが許可される前に動的かつ厳格に処理される
7. すべての企業は資産やネットワークに関する情報を可能な限り収集し、セキュリティ対策の改善に用いる

Google Cloud において、これらはベストプラクティスの多くと合致します。IAM や限定公開アクセス機能などによってアタックサーフェスを如何に狭くし、残ったアタックサーフェスをどのように監視・防御するか、という観点が求められます。

• 参考 : NIST SP800-207 Zero Trust Architecture - NIST（PDF）
• 参考 : NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳 - PwCコンサルティング合同会社

境界型セキュリティ vs ゼロトラスト（Chrome Enterprise Premium（旧BeyondCorp Enterprise）を徹底解説 - G-gen Tech Blog より引用）

脅威ハンティング

脅威ハンティングと MITRE ATT&CK

攻撃が複雑・巧妙化してきた一方、前述した SIEM など防御側が利用できる「道具」も整ってきたことで、これまで気付かなかった攻撃、技術的に見過ごさざるを得なかった攻撃も検知できるようになりました。

そこからさらに、「隠れた攻撃の痕跡」あるいは「既に潜伏している脅威」を探し出して対応することも可能になりました。

このような動きは、従来型の防御がある意味「受け身」であったことに対し、積極的に「狩り出す」という意味合いを込めて、脅威ハンティング（Threat Hunting）と呼ばれます。

そのハンティングのための地図、あるいはハンドブックとして利用できるフレームワークが、米国の非営利団体 MITRE が運営する MITRE ATT&CK（あるいは単に「ATT&CK」）です。

• 参考 : MITRE ATT&CK

ATT&CK は過去に観測されたサイバー攻撃を分析し、攻撃者の振る舞いを「戦術（Tactics）」と「技術（Techniques）」のマトリクスとして整理したナレッジベースです。これによりセキュリティチームは、攻撃者の「TTPs（Tactics, Techniques, and Procedures、すなわち戦術、技術、手順）」に基づいて脅威を探すことができます。

脅威ハンティングによって「自社では、この TTPs が悪用されやすい」という知見が得られれば、その部分のアタックサーフェスを減らすための投資を強化できます。このように、予防と検知のサイクルを回し続けることで、組織は継続的にセキュリティ態勢を向上させていくことができます。

Actor と IoC

国家支援型グループやサイバー犯罪集団など、サイバー攻撃を実行する個人や組織を Actor（脅威アクター）と呼びます。攻撃手法（TTPs）のクセやツール、接続元の IP アドレスなどからプロファイリングされます。

世界中で「いま」行動中の Actor の情報を共有したり、Actor に応じた対処法を講じることが、防御や脅威ハンティングを効果的に行う近道となります。

• 参考 : サイバー脅威アクターとは？| CrowdStrike

また Actor が活動することで残るログなどの痕跡を Indicators of Compromise（IoC、あるいは複数形で IoCs）と呼びます。直訳すると「侵害の兆候」となります。

IoC はログに含まれる単純な文字列の場合もありますが、さながら犯罪現場の遺留品や破片、足跡のように、一見見逃しそうなものでも IoC となり得ます。例えば「過去に攻撃に使われた IP アドレスやドメイン名」「既知のマルウェアのファイルハッシュ」「C&C との通信に酷似した特徴的なアクセス」などが該当します。

なお、効果的な脅威ハンティングは、やみくもにログを調べるのではなく、仮説（Hypothesis）を立てることから始まります。これは、「もし攻撃者が特定の技術を使ったら、ログにはこのような痕跡（IoC）が残るはずだ」と推論し、それを検証するプロセスです。

その際に役に立つのが Actor や TTPs の知識であり、ATT&CK に整理されているナレッジベースです。

Mandiant と Google Threat Intelligence（GTI）

ここまで説明したような Actor や IoC は、相関性をもたせた「知識（インテリジェンス）」として使用する必要があります。

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

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

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

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

レトロハンティング

レトロハンティング（retro-hunting）は脅威ハンティングの一種、あるいは亜種といえるものです。

通常の脅威ハンティングが「現在進行中の攻撃」に主眼を置いているに対し、レトロ（懐古）ハンティングは「過去」に主眼を置きます。つまり「新たに見つかった・判明した脅威の IoC を過去のログなどから探す」ことです。

例えば「昨日見つかったマルウェア、実は半年前から社内に潜んでいたのでは？」という問いに答えることが目的です。これにより被害範囲を洗い直したり、気づいていなかった侵入経路やアタックサーフェスを見つけ出すことができます。

レトロハンティングは対象が過去であるため、膨大な量のアーカイブ情報、ネットワークや認証などのログ情報に対して検索をする必要があります。大容量データ分析・検索能力に強みを持つ Google SecOps は、レトロハンティングも得意領域であると言えます。

その他のセキュリティ製品

VirusTotal

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

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

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

サードパーティ製品

Google SecOps は多くのサードパーティ製品と連携することが可能です。PSOE 認定試験にあたりその全てを覚える必要はありませんが、著名かつ代表的なサービスについては、そのユースケースとともに押さえておきましょう。以下は例示です。

• パブリッククラウドの各種サービス（AWS、Azure、Google Cloud ...）
• SIEM（Splunk、Exabeam ...）
• 運用管理（ServiceNow、JIRA ...）
• EDR（CrowdStrike、SentinelOne ...）

インシデントレスポンス

セキュリティインシデントに対しどのような組織体制を組むのか、という戦略は、インシデントの影響を最小限に抑え込むために重要です。

例えば米国の技術標準化機関のひとつである IEEE が公開しているドキュメント「Security Operations Center: A Systematic Study and Open Challenges」によると、セキュリティオペレーションセンター（SOC）のインシデント対応チームに必要なロールは以下だとされています。

• Tier 1: トリアージ スペシャリスト
  データの収集とアラートの確認、重要度を判定し、必要に応じて Tier 2 へエスカレーションする
• Tier 2: インシデント対応者
  詳細なインシデントの評価を行い、重要な問題が発生していると判断された場合にはエスカレーションする
• Tier 3: 脅威ハンター
  重大インシデントへの対応、各 Tier のメンバーの指導。平時には脆弱性試験などの監督やレトロハンティングを行う
• SOC マネージャ
  チーム全体の統括・マネジメント。CISO など経営トップへの説明責任を持つ

引用: FIGURE 4. Interaction of different roles within a SOC（Security Operations Center: A Systematic Study and Open Challenges - IEEE xplore より引用）

このようなチームでの動き方や、各 Tier の責任範囲など、何がベストプラクティスとされているかは押さえておくとよいでしょう。

• 参考 : Security Operations Center: A Systematic Study and Open Challenges

もしこの領域に関する知識・経験が少ない場合は、入門として、以下のドキュメントを参考にしてください。

• 参考 : PagerDuty インシデントレスポンス ドキュメント - PagerDuty

SecOps 文脈でのオブザーバビリティ

オブザーバビリティとセキュリティ

オブザーバビリティ（可観測性）という用語は多くの場合、運用監視の領域で使われることが多いのですが、その本質は「システム内で起きていることのリアルタイムでの計測と把握」であり、セキュリティ分野にも非常に関わりの深い・応用の可能な技術です。

試験ガイドの Section 6 にあるように、当試験においてはログやメトリクスの確認、アラートの設定、ダッシュボードやレポートの作成などが該当します。

サイレントソース検知（silent source detection）

セキュリティにおいても運用監視においてもですが、見逃されやすいのがこの概念です。「異常があったという報告」と同レベルかそれ以上に「来るはずの連絡がない」というのは、非常に重要なアラートになり得ます。

一時的な報告遅延との切り分けが難しいものの、適切にケアすることが重要です。このように、来るはずのデータがこない状況を検知するための仕組みをサイレントソース検知（silent source detection）といいます。

実装としては、Cloud Monitoring のアラート機能により、指標なし（metric-absence、data absence）を検知してアラートを発報するなどの方法が考えられます。

• 参考 : 指標なしのアラート ポリシーを作成する

Google SecOps の詳細

パーサーと UDM

Google SecOps は、Google Cloud だけでなく、数多くのクラウドサービスやソフトウェア製品のログを取り込み、分析と脅威検知ができます。

各製品のログが SecOps に送られると、パーサー（parser）というコンポーネントでパースされ、UDM（Unified Data Model）形式に再フォーマットされます。これにより、異なる製品の異なるフォーマットのログが1つの形式に統一され、SecOps による分析や脅威検知に利用できるようになります。

• 参考 : Default parser configuration and ingestion

UDM のイベントやアラートは、後述の YARA-L 2.0 構文で検索することができます。

• 参考 : Search for events and alerts

パーサーの種類と拡張

SecOps にはデフォルトのパーサー（Prebuilt parser とも呼称）が多数用意されており、クラウドサービスや EDR 製品など、サードパーティ製品向けのパーサーが充実しています。デフォルトのパーサーのリストは、以下のドキュメントで確認できます。

• 参考 : Supported log types and default parsers

デフォルトのパーサーが存在しない場合は、カスタムパーサーを記述することができます。

• 参考 : Manage prebuilt and custom parsers

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

• 参考 : Parser extensions

サードパーティからのログ取り込み

Google SecOps には、サードパーティの SaaS やオンプレミスのサーバー、ファイアウォール等、多様なデータソースからログを取り込む必要があります。特にサーバー類からのログ取り込みには、以下のような方法があります。

名称	説明
Forwarders	Linux / Windows Server 等にインストールするエージェント
Bindplane agent	Linux / Windows Server 等にインストールするエージェント
Ingestion APIs	Google SecOps が用意するデータ取り込み用 API
Google Cloud	Google Cloud の Cloud Logging 経由で SecOps にログを取り込み
Data feeds	Amazon S3 やサードパーティ API などから直接 SecOps にログを挿入

Forwarders と Bindplane agent の違いについては、以下のようなものがあります。

• Forwarders は SecOps 純正であり最もシンプル
• ただし Forwarders は syslog、ファイル、パケット、Splunk、Kafka など所定のフォーマットにのみ対応
• Bindplane はログ収集エージェントというより「テレメトリパイプライン」であり、より柔軟な処理が可能

試験にあたっては、これらを踏まえて適切な収集方法を選択できる必要があります。

• 参考 : Google SecOps data ingestion

インテリジェンスとアラート

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

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

前述の SecOps に備え付けのインテリジェンスの他にも、MISP などのフィードを通じて独自の IoC データを取り込むこともできます。MISP とは Malware Information Sharing Platform の略で、マルウェア情報の共有を受けられるプラットフォーム（サービス）です。

• 参考 : View alerts and IoCs - How Google SecOps automatically matches IoCs

YARA-L ルール

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

• 参考 : Overview of the YARA-L 2.0 language

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

• 参考 : Generate a YARA-L rule using Gemini

IAM によるアクセス制御

Google SecOps の管理画面へのアクセス制御は、Google Cloud の Identity and Access Management（IAM） で行います。

Google SecOps を紐づけた Google Cloud プロジェクトのプロジェクトレベルの IAM ポリシーにおいて、Google アカウントやグループにロールを付与します。付与するロールによって権限が異なります。読み取り専用ロールには roles/chronicle.viewer と roles/chronicle.limitedViewer の2種類があることに留意してください。

• 参考 : IAM を使用して機能アクセス制御を構成する - IAM での Google SecOps 事前定義ロール

その他に知っておくべき概念

以下のような基本的な Google Cloud の概念については理解しておく必要があります。

• Identity and Access Management（IAM）
• 組織（Organizations）
• 組織のポリシー

以下の記事も参考にしてください。

blog.g-gen.co.jp

blog.g-gen.co.jp

blog.g-gen.co.jp

渡辺聖剛 (Seigo) (記事一覧)

事業開発部トレーニング課所属 Google Cloud 認定トレーナー。2025年2月にG-genにJOIN。福岡在住。オペレーションとモニタリングについて考えるのが好きな元インフラエンジニア。