模擬問題集一覧

GCP-PSOE 模擬問題集（練習問題）

Professional Security Operations Engineer 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

GCP-PSOE（Professional Security Operations Engineer）の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

GCP-PSOE の出題範囲（カバーしている分野）

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はGCP-PSOE の学習ガイドにまとめています。

GCP-PSOE の無料練習問題（15 問・解説つき）

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1検出ルールにどのような変更を実装すべきですか。検出エンジニアリング
問題
過剰なネットワーク接続を検出する Google Security Operations（SecOps）の検出ルールが頻繁にトリガーされすぎて、誤検知のアラートが多数生成されていることに気付きました。ルールの有効性を損なわずにノイズを減らすよう、ルールを改善したいと考えています。検出ルールにどのような変更を実装すべきですか。

選択肢と解説

  • ✓
    YARA-L の condition: セクションにしきい値を追加し、一定数の接続があった後にのみルールがアラートを出すようにする。
  • 2
    YARA-L の outcome: セクションでリスクスコアを割り当て、アラート キューでアラートをより効果的に優先順位付けする。
  • 3
    ネットワーク接続の送信元と宛先が同じものについて、YARA-L の match: セクションに 10 分間の時間枠を含め、アラートを集約する。
  • 4
    YARA-L の events: セクションを更新し、ネットワーク接続アラートに関与する最も一般的な IP アドレスを除外して、アラートの数を減らす。

解説

【正解】A

【0からの解説】
①前提知識：YARA-L 2.0 のルールは主に次のセクションで構成されます。meta:（説明情報）、events:（照合するイベントの条件。UDM フィールドで記述）、match:（イベントをグループ化するプレースホルダ変数と時間枠。例：match: $src, $dst over 10m）、outcome:（リスクスコアや集計値など、検出に付与する出力）、condition:（検出を発生させる条件。例：#e > 100 のように、イベント件数のしきい値を指定）です。

②要件の整理：ルールの目的は「過剰な」ネットワーク接続の検出です。問題は、トリガーが多すぎて「誤検知」が多いことで、求められているのは「ルールの有効性を損なわずに」ノイズを減らすことです。

③正解の理由：A のように condition: セクションに件数のしきい値（例：$e のイベント数が N を超えた場合のみ）を設定すると、少数の正常な接続ではアラートが出ず、本当に「過剰」と言える量の接続があったときだけ検出されます。これは「過剰な接続」というルール本来の意図をそのまま表現したチューニングで、悪意のある大量接続の検出能力を保ったまま、正常な通信による誤検知を削減できます。なお、condition: の件数のしきい値は、match: の時間枠（例：送信元ごとに over 10m）の中で発生したイベントの数を数えるものなので、match: の時間枠と組み合わせて使うことが前提です。つまり A は「時間枠で集約する」ことに加えて「件数で絞り込む」変更であり、C の要素も含んだうえで一歩進んだ対策といえます。

【誤りの選択肢】
B：outcome: でリスクスコアを付けると、アラートの優先順位付けには役立ちますが、アラートの数（ノイズ）自体も誤検知も減りません。アナリストが処理すべきアラートは同じだけ残ります。
C：match: で送信元・宛先ごとに 10 分間の時間枠でグループ化すると、同じ組み合わせのアラートが 1 件にまとまるため、アラートの件数は確かに減ります。ノイズ対策として一定の効果があるので迷いやすい選択肢ですが、C が減らすのはアラートの「件数」だけです。件数のしきい値がなければ、時間枠の中に正常な接続が 1 回あるだけで検出が発生するため、正常な通信による誤検知そのものは（まとめられた形で）残り続けます。誤検知を減らすには、A のように「どれだけの数の接続があれば過剰とみなすか」を condition: で定義する必要があります。
D：最も一般的な IP アドレスを一律に除外すると、それらのアドレスが侵害された場合や攻撃に悪用された場合に検出できなくなり、「ルールの有効性を損なわずに」という要件に反します。

【参考】
YARA-L を使ってみる | Google Security Operations
この問題のページを開く →
問題 2インシデント対応インシデント対応
問題
あなたの会社で優先度の高いフィッシング インシデントが発生した際、Google Security Operations（SecOps）はケースを作成し、Tier 1 アナリストに割り当てました。アナリストはメールヘッダーを追加し、悪意のあるファイルを証拠として添付しましたが、ケースをエスカレーションしませんでした。これは、フィッシング対応に関する 30 分という社内 SLA に違反するものでした。この遅延により、封じ込めアクションが開始される前に複数のユーザーがそのファイルを開いてしまいました。今後の優先度の高いインシデントに向けて、ケース管理のワークフローを最適化したいと考えています。どうすればよいですか。

選択肢と解説

  • ✓
    報告されたフィッシング メールを自動的に取り込み、脅威インテリジェンスでエンティティを拡充し、影響を判定して、レビューのためにケースを割り当てるプレイブックを構築する。
  • 2
    デフォルトのケース割り当てロジックを変更し、すべてのフィッシング アラートを Tier 2 チームにルーティングする。
  • 3
    ケースが手動で再割り当てされるまで、Tier 1 アナリスト、Tier 2 アナリスト、SOC マネージャーに 5 分ごとにエスカレーションのメールアラートを送信する SOAR の通知ループを構成する。
  • 4
    手動での対応が 60 分間行われなかった場合に、フィッシング ケースを自動的にクローズするようにプレイブックを更新する。

解説

【正解】A

【0からの解説】
①前提知識：Google Security Operations（Google SecOps、旧 Chronicle と旧 Siemplify を統合した SIEM / SOAR プラットフォーム）の SOAR 機能では、アラートがケースとしてまとめられ、プレイブック（ハンドブック）がケースに対して自動でアクションを実行します。プレイブックは「メールの取り込み → 添付ファイルや URL・送信元などのエンティティ抽出 → Google Threat Intelligence（旧 VirusTotal Enterprise）などの脅威インテリジェンスによる拡充 → 影響範囲の判定（同じメールを受信・開封したユーザーの特定など）→ 適切なアナリストやステージへの割り当て」といった一連の手順を、人手を介さずに数秒〜数分で実行できます。

②要件の整理：問題の根本原因は「Tier 1 アナリストの手作業（証拠の追加・判断・エスカレーション）に依存していたため、30 分の SLA 内に重要な判断と次のアクションが行われなかった」ことです。求められているのは「今後の優先度の高いインシデントに向けてケース管理ワークフローを最適化する」ことで、人に依存する遅延を構造的に取り除く対策が必要です。

③正解の理由：A のプレイブックは、報告されたフィッシング メールの取り込み・エンティティ拡充・影響判定を自動で行い、その結果を付けてケースを適切な担当者に割り当てます。アナリストが手作業で行っていた初動調査が自動化されるため、判断材料がそろった状態で即座にレビューへ回り、SLA 内の封じ込めにつながります。Google SecOps SOAR の設計思想（反復的な初動対応はプレイブックで自動化し、アナリストは判断に集中する）に沿った最も適切な改善策です。

【誤りの選択肢】
B：すべてのフィッシング アラートを Tier 2 に送るのは担当者を変えるだけで、手作業による調査とエスカレーション判断の遅延という根本原因は解消されません。Tier 2 の負荷が増え、低優先度のアラートまで上位層に集中するため、かえって対応が遅れるおそれがあります。
C：5 分ごとに複数の関係者へメールを送り続ける通知ループは、アラート疲れ（ノイズ）を生むだけで、調査や封じ込めそのものは何も自動化されません。「手動で再割り当てされるまで」という条件も人の操作に依存しており、ワークフローの最適化とは言えません。
D：60 分間対応がなければ自動クローズするのは、未対応の高優先度インシデントを放置したまま闇に葬ることになり、セキュリティ上きわめて危険です。SLA 違反を隠すだけで、対応速度は改善しません。

【参考】
ハンドブックと自動化の概要 | Google Security Operations
調査とケース管理の概要 | Google Security Operations
拡充 | Google Security Operations
この問題のページを開く →
問題 3このフィールドが EDR と Windows イベントログのすべての可能なログエントリと一致するように、追加のログソース…データ管理
問題
あなたは Google Security Operations（SecOps）のキュレート検出と YARA-L ルールを使用して、Windows エンドポイントでの疑わしいアクティビティを検出しています。ソースのテレメトリには EDR と Windows イベントログを使用しています。ルールは UDM フィールド principal.user.userid に対して照合しています。このフィールドが EDR と Windows イベントログのすべての可能なログエントリと一致するように、追加のログソースを取り込む必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Windows Sysmon のログを取り込む。
  • ✓
    Microsoft Entra ID のログを取り込む。
  • 3
    Windows PowerShell のログを取り込む。
  • 4
    Windows Procmon のログを取り込む。

解説

【正解】B

【0からの解説】
①前提知識：Google SecOps（旧 Chronicle）には「エイリアス（aliasing）とデータ拡充（enrichment）」の仕組みがあります。ユーザーを表す識別子はログソースによってばらばらで、EDR のイベントには Windows SID やメールアドレスしかなく、Windows イベントログには DOMAIN\ユーザー名の形式しかない、といったことがよくあります。Google SecOps は、ID 基盤から取り込んだユーザー コンテキスト（エンティティ コンテキスト、USER_CONTEXT。例：Microsoft Entra ID（旧 Azure Active Directory）や Active Directory のユーザー情報）を使って、userid（USERNAME）・email・windows_sid・employee_id・product_object_id などの識別子を同じユーザーとして紐付け（ユーザー エイリアス）、イベントの principal.user などのフィールドを拡充します。

②要件の整理：ルールは principal.user.userid で照合していますが、EDR と Windows イベントログの中にはこのフィールドが入っていない、あるいは別の形式の識別子しか持たないエントリがあり、「すべての可能なログエントリ」に一致させたいという要件です。必要なのは新たなイベントログではなく、既存のログのユーザー識別子を相互に結び付けるための ID 情報源です。

③正解の理由：B の Microsoft Entra ID を取り込むと、ユーザーのメールアドレス、ユーザー名、オブジェクト ID、（同期環境では）オンプレミスの SID などの属性が Google SecOps に入り、ユーザー エイリアスとデータ拡充によって、EDR や Windows イベントのエントリに対しても principal.user.userid を含むユーザー情報が補完されます。その結果、識別子の種類が異なるエントリもルールで照合できるようになります。

【誤りの選択肢】
A：Windows Sysmon はプロセス生成・ネットワーク接続などのエンドポイント イベントを追加するログソースです。「Windows 端末のログを増やせば照合できるエントリも増える」と考えて選びたくなりますが、Sysmon を足しても増えるのはエンドポイントのイベントの数だけで、ユーザー識別子は統一されません。Sysmon のイベントに入るのも端末上のユーザー名（DOMAIN\ユーザー名の形式など）だけで、EDR 側の SID やメールアドレスと「同じ人物である」と結び付ける情報は含まれていません。既存の EDR や Windows イベントログのエントリに欠けている principal.user.userid を補完するには、識別子どうしの対応関係を持つ ID 基盤（Microsoft Entra ID など）のユーザー コンテキストが必要です。
C：PowerShell のログはスクリプト ブロックなどのイベントを追加するだけで、他のログソースのユーザー識別子を紐付ける ID 情報は提供しません。
D：Procmon（Process Monitor）は端末上でのトラブルシューティング用の対話型ツールで、SIEM に継続的に取り込むログソースとしては一般的でなく、ユーザー識別子の補完にも役立ちません。

【参考】
データ拡充とエイリアスの概要 | Google Security Operations
Microsoft Entra ID（旧 Azure Active Directory）のログインログを収集する | Google Security Operations
この問題のページを開く →
問題 4影響を受けたシステムとユーザー ID を横断して検索し、悪意のあるユーザーを特定して侵害の範囲を把握する必要があります。脅威ハンティング
問題
あなたは Google Security Operations（SecOps）を使用している組織の SOC アナリストです。組織の環境で発生している疑わしいアクティビティを調査しています。Google SecOps のアラートは、一連のエンドポイントで PowerShell のアクティビティが繰り返し発生していることを示しています。脅威インテリジェンス フィードに含まれていないドメインへの外向き接続が行われています。このアクティビティは複数のシステムとユーザー アカウントにまたがって発生しています。影響を受けたシステムとユーザー ID を横断して検索し、悪意のあるユーザーを特定して侵害の範囲を把握する必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    YARA-L 2.0 検索を実行して、影響を受けたシステムとユーザーにまたがるアクティビティを相関させる。
  • 2
    疑わしいドメイン文字列で raw ログ検索を実行し、関連するユーザー アクティビティに手動でピボットする。
  • 3
    User Sign-In Overview ダッシュボードを使用して、すべてのユーザーの認証の傾向と異常をモニタリングする。
  • 4
    Risk Analytics の Behavioral Analytics ダッシュボードを使用して、IP ベースの異常なアクティビティとリスクの高いユーザー行動を特定する。

解説

【正解】A

【0からの解説】
①前提知識：Google SecOps（旧 Chronicle）の SIEM では、取り込んだログはパーサーによって UDM（統合データモデル）に正規化されます。UDM 検索（検索機能）は YARA-L 2.0 の構文で記述でき、principal.hostname・principal.user.userid・target.process.command_line・network.dns.questions.name などの正規化フィールドに条件を付けて、ログソースの違いを意識せずに全環境を横断検索できます。さらに match や outcome（統計・集計）を使って、ホストやユーザーごとにイベントをグループ化し、件数や関連するドメインを集計することも可能です。

②要件の整理：状況は「複数のエンドポイント」「複数のユーザー アカウント」にまたがる PowerShell 実行と未知ドメインへの通信です。脅威インテリジェンスに載っていないため IOC 照合だけでは追えません。求められているのは「影響を受けたシステムとユーザー ID を横断して検索」し、「悪意のあるユーザーの特定」と「侵害範囲の把握」を行うことです。

③正解の理由：選択肢 A の「YARA-L 2.0 検索」とは、YARA-L 2.0 の構文で条件を書いて実行する UDM 検索（その場で過去のデータを調べるアドホックな検索）のことです。新しく取り込まれるイベントを継続的に監視してアラートを生成する「検出ルール」を作成するという意味ではありません。調査中の今この場で、取り込み済みのデータを掘り下げるための操作です。A の YARA-L 2.0 構文による UDM 検索なら、例えば PowerShell のプロセス起動イベントと疑わしいドメインへのネットワーク / DNS イベントを UDM フィールドで指定し、ホスト名やユーザー ID でグループ化して相関させられます。どのユーザーがどの端末で起点となったか、どの範囲に広がったかを 1 つのクエリで構造的に把握でき、調査の再現性も高まります。

【誤りの選択肢】
B：raw ログ検索は正規化前の文字列を対象とするため、ログソースごとの表記揺れに弱く、低速です。さらに「手動でピボット」する必要があり、複数のシステムとユーザーにまたがる相関を効率よく、漏れなく行うには不向きです。A と比べて手間がかかり、見落としのリスクも高くなります。
C：User Sign-In Overview ダッシュボードは認証（サインイン）の傾向を俯瞰するためのもので、PowerShell の実行や外向き通信との相関、侵害範囲の特定には使えません。「モニタリング」は継続監視であり、今回の調査（検索）の目的とも合いません。
D：Risk Analytics（UEBA）の Behavioral Analytics ダッシュボードはリスクの高いユーザーや異常を俯瞰するのに役立ちますが、特定の PowerShell 活動と未知ドメインへの通信をシステム・ユーザー横断で相関させて範囲を特定する用途には、具体的な検索の方が直接的です。また「IP ベースの異常」に焦点を当てており、今回のプロセス実行とドメイン通信の調査とはずれています。

【参考】
YARA-L を使ってみる | Google Security Operations
UDM の概要 | Google Security Operations
アラートとエンティティのコンテキストを調査する | Google Security Operations
この問題のページを開く →
問題 5検出ルールの作成に必要な労力を減らすために、どのログを Google SecOps に取り込むべきかを判断する必要があり…プラットフォームの運用
問題
あなたは、Google Security Operations（SecOps）に統合するデータソースの候補を選定し、優先順位を付ける担当者です。あなたの会社は最近、Google Cloud 組織のセキュリティを強化するために、いくつかの Google Cloud サービスを使い始めました。検出ルールの作成に必要な労力を減らすために、どのログを Google SecOps に取り込むべきかを判断する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Cloud Logging を使用して Google Cloud Armor のログを取り込む。
  • 2
    エンドポイントの可視性を提供する Compute Engine VM のイベントログを取り込むために、Bindplane エージェントをデプロイする。
  • ✓
    Security Command Center（SCC）を Google SecOps に統合し、Google Cloud サービスに由来するログを取り込む。
  • 4
    Google Threat Intelligence を使用して脅威グループの行動に関する分析情報を得て、脅威ハンティング活動を支援する。

解説

【正解】C

【0からの解説】
①前提知識：Security Command Center（SCC）は Google Cloud のセキュリティとリスク管理のプラットフォームで、Security Health Analytics（構成ミスの検出）、Event Threat Detection（ログに基づく脅威検出）、Container Threat Detection、VM Threat Detection などの組み込み検出サービスが、Google Cloud サービスのログやメタデータを分析して「検出結果（finding）」を生成します。Google SecOps（旧 Chronicle）は、SCC の検出結果を Google Cloud からの直接取り込みで受け取ることができ、SCC Enterprise では両者が統合されています。

②要件の整理：目的は「検出ルールの作成に必要な労力を減らす」ことです。生ログを取り込むと、そのログから脅威を見つけるための YARA-L ルールを自分たちで設計・作成・チューニングする必要があります。一方、すでに Google が管理する検出ロジックで分析済みの「検出結果」を取り込めば、自前でルールを書く量を大幅に減らせます。

③正解の理由：C のように SCC を Google SecOps と統合すると、SCC の各検出サービスが Google Cloud サービスのログ（Cloud Audit Logs、VPC フローログ、DNS ログなど）から生成した脅威・脆弱性・構成ミスの検出結果が Google SecOps に取り込まれます。これらは Google が保守する検出であり、Google SecOps 側ではアラートとしてそのまま扱ったり、他のイベントとの相関に使ったりできるため、検出ルールを一から書く労力を最小化できます。なお、選択肢 C の「Google Cloud サービスに由来するログを取り込む」という表現は、実際には生のログそのものではなく、SCC がそれらのログを分析して生成した「検出結果（finding）」を取り込むことを指しています。ログではなく、すでに脅威と判定された検出結果を取り込むからこそ、自分たちでルールを書く手間が減るのです。

【誤りの選択肢】
A：Google Cloud Armor のログは WAF / DDoS 対策の有用なテレメトリですが、生ログを取り込むだけで、攻撃を見つけるための検出ルールは自分で作成する必要があります。対象も Cloud Armor の 1 サービスに限られ、「検出ルール作成の労力を減らす」という要件を満たしません。
B：Bindplane エージェントで VM のイベントログを取り込むとエンドポイントの可視性は向上しますが、これも生ログであり、検出ルールの作成・チューニングが必要です。さらにエージェントの展開・運用負荷も増えます。
D：Google Threat Intelligence は脅威アクターや IOC に関するインテリジェンスで、脅威ハンティングには役立ちますが、「どのログを取り込むか」という問いへの答えではなく、Google Cloud 環境の検出を肩代わりするものでもありません。

【参考】
検出サービス | Security Command Center
データ取り込みの概要 | Google Security Operations
この問題のページを開く →
問題 6アラートの数を減らす必要があります。検出エンジニアリング
問題
あなたの組織では、優先度の高いネットワーク インジケーター向けに Google Security Operations（SecOps）のキュレート検出ルールセットを使用しています。オンプレミスのプロキシ サーバーから大量の誤検知が発生していることがわかりました。アラートの数を減らす必要があります。どうすればよいですか。

選択肢と解説

  • 1
    network.asset.ip フィールドに対してルール除外を構成する。
  • ✓
    principal.ip フィールドに対してルール除外を構成する。
  • 3
    target.domain フィールドに対してルール除外を構成する。
  • 4
    target.ip フィールドに対してルール除外を構成する。

解説

【正解】B

【0からの解説】
①前提知識：Google SecOps（旧 Chronicle）のキュレート検出（Curated Detections）は、Google が作成・保守する検出ルールセットです。「優先度の高いネットワーク インジケーター（high priority network indicators）」は Applied Threat Intelligence（ATI）のルールセットの 1 つで、Mandiant / Google Threat Intelligence が把握している悪性の IP・ドメインとの通信を検出します。キュレート ルールは自分で中身を書き換えられないため、誤検知を減らすには「ルール除外（rule exclusions）」を使い、UDM フィールドと値（またはリスト）を指定して、条件に一致するイベントをルールセットの検出対象から外します。

②要件の整理：(a) 誤検知の発生源はオンプレミスのプロキシ サーバー、(b) アラート数を減らしたい。UDM では、通信を行った主体（送信元）は principal、通信先は target に入ります。プロキシ サーバーは社内ユーザーに代わって外部へ接続するため、ネットワーク ログ上ではプロキシ サーバーの IP が通信の送信元＝principal.ip として現れます。

③正解の理由：principal.ip にプロキシ サーバーの IP アドレスを指定したルール除外を構成すれば、プロキシ サーバー発のイベントだけをルールセットの対象から外せます。悪性インジケーター自体（宛先）は引き続き他の送信元に対して検出されるため、検出カバレッジへの影響を限定しつつアラートを削減できます。

【誤りの選択肢】
A：network.asset.ip という UDM フィールドは存在しません（network は通信のプロトコルやセッション情報などを持つオブジェクトで、IP アドレスは principal / target などの名詞に入ります）。存在しないフィールドで除外は構成できません。
C：target.domain は通信先のドメイン、つまりこのルールセットが検出しようとしている悪性インジケーターそのものです。これを除外すると、プロキシ以外の端末からの本物の悪性通信まで見逃すことになり、誤検知対策として不適切です。
D：target.ip も同様に通信先（悪性 IP）を表すため、除外すると検出したい脅威そのものを無効化してしまいます。誤検知の発生源であるプロキシ サーバー（送信元）を絞り込むのが正しい方法です。

【参考】
Applied Threat Intelligence の概要 | Google Security Operations
UDM の概要 | Google Security Operations
この問題のページを開く →
問題 7このファイルを操作した組織内のデバイスとユーザーを迅速に特定する必要があります。インシデント対応
問題
あなたは Google Security Operations（SecOps）でケースを担当している SOC アナリストです。ケースにはファイルハッシュが含まれており、プレイブックによって VirusTotal のコンテキストで自動的に拡充され、悪意がある可能性が高いと分類されています。このファイルを操作した組織内のデバイスとユーザーを迅速に特定する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Google SecOps SIEM でファイルハッシュに一致する UDM 検索を実行するプレイブックを構築する。
  • 2
    脅威インテリジェンス プラットフォーム（TIP）でファイルハッシュの存在を照会するプレイブックを構築する。
  • ✓
    Google SecOps SOAR の手動アクションを使用して、Google SecOps SIEM でファイルハッシュに一致する UDM 検索を実行する。
  • 4
    Google SecOps SOAR の手動アクションを使用して、脅威インテリジェンス プラットフォーム（TIP）でファイルハッシュの存在を照会する。

解説

【正解】C

【0からの解説】
①前提知識：Google SecOps の SOAR（旧 Siemplify）では、ケース画面からアナリストが統合（インテグレーション）のアクションを「手動アクション」として即座に実行できます。Google SecOps（旧 Chronicle）の SIEM 統合には UDM クエリを実行するアクションがあり、ケース内のエンティティ（ハッシュ、IP、ドメインなど）を使って、取り込み済みの社内テレメトリを検索できます。VirusTotal（現 Google Threat Intelligence）による拡充は「そのファイルが世界的に見て悪意があるか」を教えてくれますが、「自社のどの端末・ユーザーが触ったか」は社内ログ（SIEM）を検索しなければ分かりません。

②要件の整理：ハッシュはすでに悪意の可能性が高いと判定済みで、次に必要なのは「組織内でこのファイルを操作したデバイスとユーザー」の特定です。しかも「迅速に」という制約があり、目の前の 1 件のケースに対する調査ステップです。

③正解の理由：C の手動アクションなら、プレイブックを新たに設計・テストする時間をかけずに、ケース画面からその場で SIEM に対してハッシュ一致の UDM 検索（例：target.file.sha256 / target.process.file.sha256 など）を実行し、該当するホスト名やユーザー ID を即座に取得できます。社内テレメトリを持つのは SIEM なので、検索先としても正しい選択です。A と C はどちらも同じ UDM 検索を行いますが、目の前にある 1 件のケースを調査するのであれば、何も作らずにケース画面からすぐ実行できる手動アクションが最も速い方法です。プレイブックは「同じ手順を多数のケースで繰り返す」ときに真価を発揮するもので、1 件の調査のために作るのは遠回りになります。

【誤りの選択肢】
A：検索先（SIEM の UDM 検索）は正しいものの、プレイブックの構築には設計・テスト・有効化の時間がかかり、今まさに対応中のケースを「迅速に」調査するという要件に合いません。同種のケースが繰り返し発生する場合の将来的な自動化としては有効ですが、今回の最善策ではありません。
B：TIP は外部の脅威インテリジェンス（IOC やその評価）を管理するもので、自社のどのデバイスやユーザーがファイルを操作したかという社内のテレメトリは持っていません。しかも拡充はすでに VirusTotal で完了しています。プレイブック構築の時間がかかる点でも劣ります。
D：手動アクションで迅速ではありますが、照会先が TIP であるため、組織内のデバイスとユーザーは特定できません。

【参考】
アラートとケースに対応する | Google Security Operations
調査とケース管理の概要 | Google Security Operations
ハンドブックと自動化の概要 | Google Security Operations
この問題のページを開く →
問題 8どのログソースを優先すべきですか。データ管理
問題
あなたは、クラウド中心の企業環境における Google Security Operations（SecOps）SIEM の導入に向けて、ログのオンボーディングを計画しています。検出エンジニアリング チームは、次の項目を可視化できるログソースを求めています。 ・ユーザー ID の行動 ・ラテラル ムーブメント（横展開） ・権限昇格の試み 最初に取り込むテレメトリ ソースを決める必要があります。どのログソースを優先すべきですか。

選択肢と解説

  • 1
    Cloud Access Security Broker（CASB）のログ
  • 2
    EDR のログ
  • ✓
    IAM のログ
  • 4
    ネットワーク ファイアウォールのログ

解説

【正解】C

【0からの解説】
①前提知識：クラウド中心の環境では、ネットワーク境界よりも「ID」がセキュリティの境界になります。IAM のログ（Google Cloud であれば Cloud Audit Logs の管理アクティビティ ログに記録される IAM ポリシーの変更、サービス アカウントのキー作成や権限借用（impersonation）、ロール付与など、そして IdP の認証ログ）は、「誰が・どの ID で・何の権限を使って・何をしたか」を記録します。

②要件の整理：求められているのは (1) ユーザー ID の行動、(2) ラテラル ムーブメント、(3) 権限昇格の試み、の 3 つすべてを可視化できるソースで、しかも「クラウド中心の企業環境」で「最初に」取り込むべきものです。

③正解の理由：C の IAM ログは、(1) ID ごとの認証・操作の履歴でユーザー行動を、(2) サービス アカウントの権限借用やプロジェクト間・リソース間での認証情報の利用でクラウド上のラテラル ムーブメントを、(3) 自分自身や他者への高権限ロールの付与、ポリシー変更などで権限昇格の試みを、それぞれ直接可視化できます。3 つの要件をすべて 1 つのソースでカバーでき、クラウド中心の環境では最優先で取り込むべきテレメトリです。

【誤りの選択肢】
A：CASB のログは SaaS 利用状況やシャドー IT、データの持ち出しの可視化には有効ですが、クラウド基盤内での権限昇格やラテラル ムーブメントの把握は主目的ではなく、3 つの要件すべてを満たすものではありません。
B：EDR のログはエンドポイント上のプロセス実行やローカルでの権限昇格、端末間の横展開の検出に優れますが、クラウド中心の環境における ID の行動やクラウド IAM を悪用した権限昇格は捉えられません。エンドポイント中心の環境なら有力ですが、この問題の前提では IAM ログに劣ります。
D：ネットワーク ファイアウォールのログは通信の許可 / 拒否を記録し、ネットワーク経由の横展開の兆候は見えるものの、「どの ID が何をしたか」というユーザー ID の行動や権限昇格は可視化できません。

【参考】
Cloud Audit Logs の概要 | Cloud Logging
Collect Google Cloud Audit Logs | Google Security Operations
この問題のページを開く →
問題 9脅威ハンティング脅威ハンティング
問題
あなたは組織で脅威インテリジェンスと侵害指標（IOC）リストの管理を担当しています。最近のインシデントから IOC のリストを取りまとめました。この IOC を他のチームと迅速かつ効率的に共有し、共同作業を行ったり、各チームの運用プロセスに組み込んだりできるようにしたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    Google Security Operations（SecOps）でリストを作成し、他のチームに必要なアクセス権を付与する。
  • 2
    Google Threat Intelligence から IOC を CSV 形式または JSON 形式でエクスポートし、そのファイルを他のチームにメールで送信する。
  • ✓
    Google Threat Intelligence のコレクションに IOC を追加し、そのコレクションを他のチームと共有する。
  • 4
    Google Threat Intelligence で新しい脅威グラフを作成し、そのグラフを他のチームと共有する。

解説

【正解】C

【0からの解説】
①前提知識：Google Threat Intelligence（GTI）は、VirusTotal（旧 VirusTotal Enterprise）と Mandiant の脅威インテリジェンスを統合した Google の脅威インテリジェンス基盤です。GTI の「コレクション（Collection）」は、ファイル ハッシュ・ドメイン・IP アドレス・URL といった IOC をひとまとまりにして名前・説明・タグを付けて管理する入れ物で、組織内のユーザーやグループと共有したり、API 経由で取得して他のツールに取り込んだり、内容を更新し続けたりできます。GTI 自体が脅威アクターやキャンペーンの情報を「コレクション」として配信しているのと同じ仕組みを、自組織の IOC にも使えるイメージです。

②要件の整理：(a) 最近のインシデントから集めた IOC を「他チームと共有」したい、(b)「迅速かつ効率的に（quickly and efficiently）」、(c) 共同作業（collaboration）ができ、(d) 各チームの運用プロセスへ統合（integration）できること。つまり一度きりの送付ではなく、共同で更新でき、ツールや API から機械的に利用できる共有形態が求められています。

③正解の理由：GTI のコレクションに IOC を追加して共有すれば、共有先チームは常に最新のリストを GTI の UI で参照・追記でき、各 IOC には GTI の評価（検出数、関連する脅威アクター、関連インフラ）がそのまま付いた状態で確認できます。さらにコレクションは API やエクスポートで他システム（SIEM・EDR・ファイアウォールなど）へ取り込めるため、運用プロセスへの統合という要件も満たします。IOC の共有・共同作業のために用意された機能をそのまま使う方法であり、最も迅速かつ効率的です。

【誤りの選択肢】
A：Google SecOps（旧 Chronicle）のリスト（参照リスト / データテーブル）は、YARA-L 検出ルールや UDM 検索の中で値を照合するための仕組みで、SecOps 内部の検出ロジック向けです。SecOps を使っていない他チームとの共同作業や、各 IOC の脅威インテリジェンス文脈の共有には向いておらず、SecOps へのアクセス権を他チームに付与すること自体も最小権限の観点で過剰です。
B：CSV/JSON をメールで送る方法は動きますが、送った時点のスナップショットにすぎず、IOC が追加・更新されるたびに再送が必要です。共同編集もできず、版の混乱や送付漏れが起きやすく、手作業の多い非効率な方法です。また IOC をメール添付で流すこと自体も管理上望ましくありません。
D：脅威グラフ（VirusTotal Graph）は、IOC 同士の関係（ドメインと IP、ファイルと通信先など）を可視化して調査するためのツールです。調査結果の共有には使えますが、IOC リストを管理して他チームの運用プロセスへ取り込む用途にはコレクションの方が適しています。

【参考】
Applied Threat Intelligence の概要 | Google Security Operations
この問題のページを開く →
問題 10この環境で見つかった非準拠リソースの証拠を含むレポートを作成する必要があります。オブザーバビリティ
問題
あなたの会社のリスク管理・コンプライアンス チームは、継続的にプロジェクトが追加されていく規制対象の事業部門について、業界標準の統制フレームワークへの準拠状況を定期的に報告することを求めています。この環境で見つかった非準拠リソースの証拠を含むレポートを作成する必要があります。このレポートをどのように生成すればよいですか。

選択肢と解説

  • ✓
    Audit Manager のコンプライアンス フレームワークを使用して監査を実行する。評価結果をエクスポートし、第 2 線のチームが利用できるようにする。
  • 2
    BigQuery に保存された Cloud Asset Inventory のデータを使用して、必要な統制に関するクエリを実行する。このレポートが定期的に実行されるようにスケジュールする。
  • 3
    Rego を使用して統制フレームワークを実装し、このフレームワークを Workload Manager にデプロイする。Workload Manager で定期的なレポートをスケジュールする。
  • 4
    Security Command Center（SCC）のポスチャーで、そのコンプライアンス フレームワーク用の組み込みポスチャーを実装する。

解説

【正解】A

【0からの解説】
①前提知識：Audit Manager は、Google Cloud のワークロードが業界標準の統制フレームワーク（SOC 2、CIS Critical Security Controls v8、PCI DSS v4.0.1、ISO 27001:2022、NIST Cybersecurity Framework、CSA Cloud Controls Matrix など）に準拠しているかを評価し、監査の証拠を自動収集するサービスです。フォルダまたはプロジェクトを範囲として監査を実行でき（組織全体を範囲にする監査は、一部のフレームワークを除きプレビュー段階）、結果は統制ごとの評価や、リソースごとの準拠 / 違反などの内訳を含む監査レポートとしてまとめられ、レポートと証拠は指定した Cloud Storage バケットに保存されます。監査を定期的に実行するスケジュール機能もあります。なお、Security Command Center の Compliance Manager との統合が進んでおり、Compliance Manager で作成したカスタム フレームワークに対しても Audit Manager で監査を実行できるなど、製品の位置付けは変化しています。最新の状況は公式ドキュメントで確認してください。

②要件の整理：(1) 業界標準の統制フレームワークへの準拠状況、(2) 非準拠リソースの「証拠」を含むレポート、(3) 定期的な報告、(4) プロジェクトが継続的に追加される環境、(5) リスク管理・コンプライアンス チーム（第 2 線）が利用する、という条件です。

③正解の理由：この問題のポイントは「プロジェクトが継続的に追加される」ことです。A の Audit Manager で事業部門のフォルダを監査範囲に指定すれば、監査はそのフォルダ配下のプロジェクト全体に対して行われるため、後から追加された新しいプロジェクトも、設定を変えることなく次回の監査に自動的に含まれます。そして、組み込みのフレームワークを選んで監査を実行するだけで、統制ごとの評価と非準拠リソースの証拠を含む監査レポートが生成され、評価結果をエクスポートして第 2 線のチームに渡せます。自前でクエリやポリシーを書く必要がなく、「証拠付きのコンプライアンス レポート」という要件に最も直接的に合致します。

【誤りの選択肢】
B：Cloud Asset Inventory のエクスポートに対する BigQuery クエリでも構成を確認できますが、各フレームワークの統制を SQL に自前で落とし込み、保守し続ける必要があり、運用負荷が大きく、監査人向けの証拠としての体裁も自分で整える必要があります。マネージドな Audit Manager に比べて劣ります。
C：Workload Manager は SAP などのワークロードのベストプラクティス評価が主目的のサービスで、Rego でカスタム ルールを書くこと自体はできますが、業界標準の統制フレームワーク全体を自前で Rego 実装するのは膨大な作業で、コンプライアンス監査レポートの用途には適していません。
D：SCC のセキュリティ ポスチャーは、事前定義されたポスチャー（CIS、NIST SP 800-53、ISO 27001、PCI DSS など）をデプロイして、組織のポリシー制約による予防と Security Health Analytics の検出器による検知を行い、定義した状態からの逸脱（違反のドリフト）を検出する機能です。つまりポスチャーの役割は「あるべき設定を適用し、そこから外れたら知らせる」ことで、統制ごとの評価と非準拠リソースの証拠をまとめた監査レポートを作成するものではありません。セキュリティ統制の適用・維持には有効ですが、問われている「非準拠リソースの証拠を含むレポートの生成」には直接答えていません。証拠付きの監査レポートは Audit Manager の役割です。

【参考】
規制、コンプライアンス、プライバシーのニーズに対応する
セキュリティ ポスチャーの概要 | Security Command Center
この問題のページを開く →
問題 11Google SecOps を使用して、関連する活動を識別する検出の仕組みを開発する必要があります。検出エンジニアリング
問題
あなたは、高度な持続的脅威（APT）アクターが組織の環境内で検出されないまま活動していたかどうかを調査しています。次の内容を含む脅威インテリジェンスを受け取りました。 ・悪意のある DLL の SHA256 ハッシュ ・既知のコマンド アンド コントロール（C2）ドメイン ・rundll32.exe が難読化された引数付きで powershell.exe を起動するという行動パターン あなたの Google Security Operations（SecOps）インスタンスには、EDR、DNS、Windows Sysmon のログが含まれています。しかし最近、Sysmon の構成が統一されていないため、すべてのエンドポイントでプロセスのハッシュが確実に取得されているわけではないことがわかりました。Google SecOps を使用して、関連する活動を識別する検出の仕組みを開発する必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    プロセスの親子関係とハッシュを相関させるマルチイベントの YARA-L 検出ルールを作成し、このルールに基づいてレトロハントを実行する。
  • 2
    ハッシュとドメインを含むリファレンス リストを作成し、そのリストを高頻度のルールにリンクしてほぼリアルタイムでアラートを出す。
  • 3
    ファイル ハッシュに基づくシングルイベントの YARA-L 検出ルールを作成し、過去および新規のテレメトリに対してルールを実行して DLL の実行を検出する。
  • 4
    Google SecOps の検索を使用して rundll32.exe の最近の使用状況を特定し、影響を受けたアセットにタグを付けてウォッチリストに登録する。

解説

【正解】A

【0からの解説】
①前提知識：YARA-L 2.0 は Google SecOps（旧 Chronicle）の検出ルール言語です。events セクションで条件を書き、match セクションで「同じホストで○分以内」などの単位と時間枠を指定すると、複数のイベントを相関させるマルチイベント ルールになります（例：親プロセス rundll32.exe → 子プロセス powershell.exe の起動、その前後の DLL 読み込み、C2 ドメインへの DNS 問い合わせなど）。レトロハント（Retrohunt）は、作成したルールを過去に取り込み済みのデータに遡って実行する機能で、「すでに侵入されていて気付いていなかったか」を確かめるのに使います。

②要件の整理：(a) APT が「検出されないまま活動していたか」＝過去に遡った調査が必要、(b) IOC はハッシュ・C2 ドメイン・行動パターン（rundll32.exe → 難読化 powershell.exe）の 3 種、(c) ただしプロセスのハッシュは一部のエンドポイントで取れていない＝ハッシュだけに依存した検出は穴がある、(d) 単発の検索ではなく「検出の仕組み」を作る。

③正解の理由：マルチイベント ルールでプロセスの親子関係という行動パターンを軸に検出すれば、ハッシュが記録されていないエンドポイントでも EDR / Sysmon のプロセス生成イベントから活動を捉えられます。ハッシュが取れている端末ではハッシュとの相関で確度を上げられ、行動とインジケーターを組み合わせた堅牢なルールになります。さらにレトロハントで過去データに適用することで、「これまで気付かずに活動していたか」という調査目的にも応えられ、ルールは以後も継続的な検出に使えます。

【誤りの選択肢】
B：ハッシュとドメインのリファレンス リストによる照合は IOC ベースの検出として有用ですが、ハッシュは一部の端末で取得できておらず、攻撃者はハッシュやドメインを容易に変更できます。行動パターンを検出しないため取りこぼしが大きく、また「ほぼリアルタイムのアラート」は将来の活動向けで、過去に活動していたかの調査（レトロハント）が含まれていません。
C：ハッシュだけに基づくシングルイベント ルールは、まさに「ハッシュが確実に取得されていない」という制約に弱く、ハッシュが記録されていない端末での DLL 実行を見逃します。行動パターンや C2 ドメインも活用していません。
D：検索で rundll32.exe の使用を洗い出すのは一回限りの調査で、継続的な「検出の仕組み」になりません。rundll32.exe は正規の Windows プロセスとして頻繁に使われるため、それだけでは誤検知も膨大になり、powershell.exe の起動や難読化引数といった行動の条件も考慮されていません。

【参考】
YARA-L を使ってみる | Google Security Operations
この問題のページを開く →
問題 12どの IP アドレス エンティティがネットワークの内部のものかを識別し、各エンティティにその IP アドレスが属する具体…インシデント対応
問題
Google Security Operations（SecOps）インスタンスで、複数のコネクタからセキュリティ アラートを受信しています。どの IP アドレス エンティティがネットワークの内部のものかを識別し、各エンティティにその IP アドレスが属する具体的なネットワーク名のラベルを付ける必要があります。このネットワーク名はプレイブックのトリガーとして使用されます。どうすればよいですか。

選択肢と解説

  • ✓
    Google SecOps SOAR の設定で各ネットワークを構成する。
  • 2
    プレイブックの最初のステップとして IP アドレス エンティティを拡充する。
  • 3
    アラートの概要でエンティティ属性を変更する。
  • 4
    ルールで outcome 変数を作成してネットワーク名を割り当てる。

解説

【正解】A

【0からの解説】
①前提知識：Google SecOps SOAR（旧 Siemplify / Chronicle SOAR）は、コネクタで取り込んだアラートをケースにまとめ、プレイブック（自動化ワークフロー）で対応する機能です。アラートに含まれる IP アドレス・ホスト名・ユーザーなどは「エンティティ」として抽出され、各エンティティには「内部（Internal）か外部か」「どのネットワーク／環境に属するか」といったプロパティが付きます。SOAR の［Settings］→［Environments］→［Networks］（ネットワークの管理）では、ネットワーク名・CIDR 範囲・優先度・環境を登録でき、取り込まれた IP アドレス エンティティがその CIDR に一致すると、自動的に内部エンティティとしてマークされ、ネットワーク名が付与されます。

②要件の整理：(a) 複数コネクタから来るアラートすべてに対して、(b) 内部 IP かどうかを識別し、(c) 具体的なネットワーク名でラベル付けし、(d) そのネットワーク名をプレイブックのトリガー条件に使いたい。トリガーはプレイブックが動き出す「前」に評価されるため、ネットワーク名はプレイブック開始前（取り込み時）に付いている必要があります。

③正解の理由：SOAR 設定でネットワークを定義しておけば、どのコネクタから来たアラートでも、取り込み時に IP エンティティが CIDR と照合されて内部判定とネットワーク名の付与が一元的・自動的に行われます。プレイブックのトリガーでは「Network name」などの条件を指定できるため、ネットワークごとに異なるプレイブックを起動できます。設定作業は一度だけで済み、コネクタごとの個別対応も不要です。

【誤りの選択肢】
B：プレイブックの最初のステップで拡充しても、それはトリガーが評価されてプレイブックが起動した「後」の処理です。トリガーにネットワーク名を使うという要件と順序が矛盾します。また、内部ネットワークの定義を拡充アクションで毎回実装するのは手間がかかり、本来の仕組みの代わりにはなりません。
C：アラートの概要画面でエンティティ属性を手動で変更するのは、アラート 1 件ごとの手作業です。複数コネクタから継続的に届くアラートに対して自動的にラベル付けすることはできず、トリガーにも間に合いません。
D：outcome 変数は YARA-L 検出ルール（SIEM 側）でアラートに付加情報を出力する仕組みで、SIEM ルール由来のアラートにしか使えません。複数のコネクタ（サードパーティ製品）から来るアラートは対象外であり、ネットワーク範囲をルールごとに書き込むのは保守性も悪い方法です。

【参考】
ネットワークを管理する | Google Security Operations
環境の概要 | Google Security Operations
この問題のページを開く →
問題 13Google SecOps の取り込み割り当て（クォータ）への影響を最小限に抑えながら、このアクティビティを可視化する必…データ管理
問題
あなたは Google Security Operations（SecOps）を使用して、Compute Engine イメージから起動した VM インスタンスに対する SSH ログインのブルートフォース試行が繰り返し発生していること（ログインは成功していない）を特定し、報告しようとしています。Google SecOps の取り込み割り当て（クォータ）への影響を最小限に抑えながら、このアクティビティを可視化する必要があります。どのログタイプを Google SecOps に取り込むべきですか。

選択肢と解説

  • 1
    VPC フローログ
  • 2
    Security Command Center Premium（SCCP）の検出結果
  • ✓
    Cloud IDS のログ
  • 4
    Cloud Audit Logs

解説

【正解】C

【0からの解説】
①前提知識：Cloud IDS（Cloud Intrusion Detection System）は、Palo Alto Networks の脅威検出技術を使ったマネージドの侵入検知サービスで、パケット ミラーリングで VPC のトラフィックを検査し、エクスプロイト、マルウェア、コマンド＆コントロール、ブルートフォース攻撃などの脅威シグネチャに一致した通信を「脅威ログ」として Cloud Logging に出力します。Cloud IDS を使うには、監視するリージョンごとに IDS エンドポイントを作成し、検査したい VM のトラフィックをそのエンドポイントへ送るパケット ミラーリング ポリシーを関連付ける必要があります（プライベート サービス アクセスの構成も必要です）。Google SecOps には Cloud IDS ログ用のデフォルト パーサーがあります。SSH ログインの試行先は、イメージそのものではなく、イメージから起動して稼働している VM インスタンスです。

②要件の整理：(1) SSH ログインのブルートフォース「試行」で、ログインは成功していない、(2) 繰り返し発生するパターンを可視化・報告したい、(3) 取り込み割り当てへの影響を最小限にしたい、という条件です。ここでいう「割り当て（クォータ）への影響」とは、Google SecOps に取り込むログの量のことで、Google Cloud 側でかかる費用全体のことではありません。

③正解の理由：C の Cloud IDS は、SSH のブルートフォース試行のようなシグネチャに一致した通信だけを脅威ログとして記録するため、Google SecOps に取り込むログ量が少なく、取り込み割り当てへの影響を最小限に抑えられます。しかもログイン成否にかかわらず攻撃の試行そのものを検出できるため、失敗に終わった繰り返しのブルートフォース試行を可視化するという要件に合致します。
ただし、Cloud IDS は無料ではありません。IDS エンドポイントの稼働時間に応じた料金と、検査したトラフィック量に応じた料金がかかり、パケット ミラーリングの構成と運用も必要です。この問題で最小化を求められているのは Google SecOps への取り込み量なので Cloud IDS が最適ですが、実務ではこうした Google Cloud 側のコストも合わせて検討しましょう。

【誤りの選択肢】
A：VPC フローログでも、同じ送信元からポート 22 への接続が繰り返されている様子は見えるため、ブルートフォースの試行自体は把握できます。しかし、フローログは攻撃かどうかに関係なく、サンプリングされたすべてのネットワーク フローを記録するため、Google SecOps に取り込むログ量が非常に多くなり、取り込み割り当てを大きく消費します。また、フローの情報だけでは攻撃かどうかの判断を自分で行う必要があります。「シグネチャに一致した通信だけ」を記録する Cloud IDS と比べると、取り込み量の点で劣ります。
B：Security Command Center Premium の Event Threat Detection にも「Brute Force: SSH」の検出結果がありますが、これは「ホストに対する SSH のブルートフォースが成功した」ことを検出するもので、ログインが成功していない試行は検出結果になりません。今回の要件を満たしません。
D：Cloud Audit Logs は Google Cloud API の呼び出し（誰がリソースを作成・変更・参照したか）を記録するもので、VM の OS への SSH ログイン試行（sshd の認証失敗など）は記録されません。

【参考】
Cloud IDS の概要 | Cloud Intrusion Detection System
Cloud Intrusion Detection System（Cloud IDS）ログを収集する | Google Security Operations
ブルート フォース: SSH | Security Command Center
この問題のページを開く →
問題 14最初に行うべきアクションはどれですか。脅威ハンティング
問題
あなたは Google Security Operations（SecOps）を使用している組織のセキュリティ アナリストです。複数のユーザー アカウントで疑わしいログイン試行があることに気付きました。これらの試行が組織的（協調的）な攻撃の一部であるかどうかを、できるだけ早く判断する必要があります。最初に行うべきアクションはどれですか。

選択肢と解説

  • 1
    デフォルトのキュレート検出を有効にして、疑わしい IP アドレスを自動的にブロックする。
  • ✓
    UDM 検索を使用して、疑わしいログイン試行に関連する最近の IOC を過去のログから照会する。
  • 3
    無効なログイン試行が繰り返されているユーザー アカウントを削除する。
  • 4
    Risk Analytics ダッシュボードで、影響を受けたユーザー間の相関関係を探す。

解説

【正解】B

【0からの解説】
①前提知識：
・UDM 検索：Google Security Operations（Google SecOps、旧 Chronicle）で、UDM（統合データモデル）に正規化された全ログを横断して、IP アドレス・ユーザー・ドメインなどのフィールドで高速に検索できる機能です。たとえば principal.ip = "x.x.x.x" で検索すれば、その IP が関わったすべての認証イベントを、どのログソースかに関係なく一覧できます
・IOC（侵害指標）：攻撃に使われた送信元 IP、ユーザー エージェント、ドメインなど、攻撃の痕跡となる値
・Risk Analytics：UEBA（ユーザーとエンティティの行動分析）のルールやキュレート検出の結果から、ユーザーやアセットのリスクスコアを算出して表示するダッシュボード
・キュレート検出：Google が管理する既製の検出ルールセット。検出してアラートを出すもので、ブロックなどの対応は行いません

②要件の整理：
・複数アカウントへの疑わしいログイン試行が「組織的な攻撃か」を判断したい
・「できるだけ早く」「最初に」行うこと
組織的な攻撃（パスワード スプレー、クレデンシャル スタッフィングなど）かどうかは、「同じ送信元 IP やユーザー エージェントなどの IOC が、複数のアカウントや他のシステムに対しても現れているか」を確かめることで判断できます。

③正解の理由：B の UDM 検索なら、疑わしいログイン試行から得られた送信元 IP などの IOC で過去のログをすぐに横断検索し、同じ IOC が他のユーザーやシステムに対しても使われていないか、いつから始まったかを即座に確認できます。事前の設定なしに、その場で証拠に基づいて判断できるため、最初の一手として最も速く確実です。

【誤りの選択肢】
A：キュレート検出は脅威を検出してアラートを生成する機能であり、IP アドレスを自動でブロックする機能ではありません。また有効化しても今後の検出に役立つだけで、すでに起きているログイン試行が組織的な攻撃かどうかを今すぐ判断することにはつながりません。
C：調査の前にアカウントを削除するのは、正規ユーザーの業務を止め、調査に必要な証拠やコンテキストも失う破壊的な対応です。被害にあっているのはアカウントの持ち主側であり、まず範囲と関連性を調査するのが先です。
D：「影響を受けたユーザー間の相関を見る」という文言だけを読むと筋が通っているように見えますが、Risk Analytics はログイン試行の相関分析に特化した機能ではありません。Risk Analytics のリスクスコアは、UEBA ルールやキュレート検出などの検出ルールが出したアラート・検出（findings）を元にユーザーやアセットごとに計算されるもので、関連する検出ルールが有効になっていて、すでに検出が出ていることが前提です。つまり、検出がまだ出ていないログイン試行はスコアに反映されず、表示されるのもユーザーごとのスコアの推移であって、「同じ送信元 IP やユーザー エージェントが複数アカウントに使われているか」といった攻撃の共通点は直接分かりません。「できるだけ早く」判断する最初の一手としては、こうした前提条件なしに生のログをその場で横断検索できる UDM 検索（B）のほうが速く、確実です。

【参考】
UDM の概要 | Google Security Operations
アラートとエンティティのコンテキストを調査する | Google Security Operations
この問題のページを開く →
問題 15（2 つ選択してください）プラットフォームの運用
問題
あなたは、新しい Google Security Operations（SecOps）のお客様が SOC チームのアクセスを構成するのを支援しています。Google SecOps の管理者は現在インスタンスにアクセスできています。お客様からは、新しい Google SecOps ユーザーがサードパーティの ID プロバイダ（IdP）では認証できるものの、インスタンスへのアクセスが認可されないと報告されています。この問題をどのように解決すればよいですか。（2 つ選択してください）

選択肢と解説

  • 1
    Chronicle API を使用して、Google SecOps を Google Cloud プロジェクトにリンクする。
  • 2
    Workforce Identity 連携を使用して、Google SecOps をサードパーティの IdP と統合する。
  • 3
    IAM で、SOC チームの IdP グループに適切なデータアクセス スコープを付与する。
  • ✓
    IAM で、SOC チームの IdP グループに roles/chronicle.viewer ロールを付与する。
  • ✓
    Google SecOps SOAR の詳細設定（Advanced Settings）で、適切な IdP グループに Basic 権限を付与する。

解説

【正解】D、E

【0からの解説】
①前提知識：Google SecOps（旧 Chronicle）を Google Cloud の認証・認可で使う場合、(1) Google Cloud プロジェクトへのリンクと Chronicle API の有効化、(2) Workforce Identity 連携によるサードパーティ IdP の構成（認証）、(3) IAM による機能アクセスの付与（認可。roles/chronicle.admin・roles/chronicle.editor・roles/chronicle.viewer など。Workforce Identity のグループには principalSet:// の形式でバインド）が必要です。さらに SOAR（旧 Siemplify）を使う場合、SOAR の権限を IAM に移行する前の環境では、[設定] > [SOAR 設定] > [詳細] > [IdP グループ マッピング] で IdP グループを SOAR の権限グループ（Admin、Basic、Readers など）・SOC ロール・環境にマッピングする必要があり、マッピングされていないユーザーは拒否されることがあります。

②要件の整理：管理者はすでにアクセスできているので、プロジェクトのリンクと Workforce Identity 連携（認証の基盤）は構成済みです。新しいユーザーは IdP での認証には成功しているので、足りないのは「認可」、つまり新しいユーザーの IdP グループへの権限付与です。

③正解の理由：D の roles/chronicle.viewer を SOC チームの IdP グループに IAM で付与すると、SIEM 側の機能へのアクセスが認可されます。E の SOAR 詳細設定で IdP グループを Basic 権限グループにマッピングすると、SOAR 側（ケースやプレイブックなど）へのアクセスが認可されます。この 2 つで SOC チームがインスタンスを利用できるようになります。
ただし、E が必要になるのは、SOAR の権限をまだ IAM に移行していない環境（この問題が前提としている環境）です。SOAR の権限グループと権限を Google Cloud IAM に移行する作業（SOAR 移行のステージ 2）を完了した環境では、SOAR の機能アクセスも IAM のロールで管理されるため、SOAR 詳細設定での IdP グループ マッピングによる Basic 権限の付与は不要になり、IAM でのロール付与だけで認可できます。自分の環境がどちらの状態かを確認してから対応しましょう。

【誤りの選択肢】
A：プロジェクトのリンクと Chronicle API の有効化はインスタンス全体の前提条件で、管理者がすでにアクセスできている以上、構成済みです。新しいユーザーだけが認可されない問題の解決にはなりません。
B：Workforce Identity 連携は認証の仕組みで、これもすでに構成済みです（ユーザーは IdP で認証でき、管理者はログインできています）。認可の問題は解決しません。
C：データアクセス スコープ（データ RBAC）は、ユーザーが閲覧できるデータの範囲を任意で制限するための仕組みです。スコープを割り当てないユーザーはすべてのデータにアクセスでき、スコープの付与はインスタンスへのアクセス認可の前提条件ではありません。機能へのアクセスを許可する IAM ロールがなければ、スコープを付与してもアクセスできません。

【参考】
機能アクセスを構成する | Google Security Operations
サードパーティの ID を使用してユーザーをマッピングする | Google Security Operations
SOAR 権限を IAM に移行する | Google Security Operations
この問題のページを開く →

GCP-PSOE 模擬問題集についてよくある質問

GCP-PSOE の練習問題は無料で試せますか？

はい。GCP-PSOE は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

GCP-PSOE は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。