【正解】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 OperationsUDM の概要 | Google Security Operationsアラートとエンティティのコンテキストを調査する | Google Security Operations