all3xj/fixing-google-secops-detectionsGoogle Chronicle Curated Detections のチューニングとリファクタリングにより、アラート疲れを解消し、ロジックのギャップやバグを修正します。
このリポジトリは、ネイティブの Google SecOps (Chronicle) Curated Detections に関する アーキテクチャ上の設計上の欠陥、ロジックの不整合、およびチューニング戦略 を文書化したものです。
Google Threat Intelligence (GTIG) は (APT29/BRICKSTORM キャンペーンを追跡するなど) 概念的な脅威カバレッジは非常に優れていますが、キュレーションされたルールの生の YARA-L 実装には、グループ化ロジックの矛盾やハードコードされた閾値変数など、実装上の見落としが生じることがあります。実際のエンタープライズ環境では、これにより大規模なアラート疲れが頻繁に発生します。
このプロジェクトは、ネイティブルールがなぜ壊れたり SOC にアラートを氾濫させたりするのかを分析し、これらの問題を解決するための最適化済みカスタムルールとパッチを共有します。
Google は、侵害された Service Principal による Microsoft 365 Exchange Online からの一括メール流出を検出するための一連のルールをリリースしました (APT29/Midnight Blizzard が多用する手法)。
影響を受けるキュレーションされたルールは次のとおりです。
O365 Mailbox Access by Service Principal with Multiple User AgentsO365 Multiple Mailboxes Accessed by Service PrincipalO365 Mailbox Access by Service Principal from Multiple ASNsO365 Multiple Mailboxes Accessed via Microsoft Graph APIこのルール群には、表明された目的と YARA-L 実装の間に、おそらくルールパック全体でのコード再利用に起因する体系的なロジックの不一致があります。これらのルールは、自動化された Service Principal と標準的な人間のアクティビティを適切に区別できず、通常の従業員の行動に対してアラートを発生させます。
ルールの説明に 「単一の O365 セッション ID を持つ Service Principal を検出...」 と明示されているにもかかわらず、「Multiple User Agents」ルールの YARA-L match セクションは、セッション ID ($session_id) ではなく $application_id でグループ化しています。これはルールの表明された目的と完全に矛盾しており、同じアプリケーションを使用しているという理由だけで、無関係な人間のログインを 3 時間のウィンドウにわたって集約します。
このルールは、特定の ClientAppId に関連付けられた異常な行動パターン (IP、ASN、またはユーザーエージェントの変更) を追跡します。Google はいくつかのネイティブ Microsoft アプリケーションの除外正規表現を含めていますが、最も普及している人間向けモバイルクライアントである Microsoft Outlook Mobile App (27922004-5251-4030-b22d-91ecd9a37ea4) を不可解にも省略しています。
Multiple ASNs および Multiple IPs アラートが本質的にトリガーされます。iOS と Android を使用する異なる従業員が同じ部門メールボックスをチェックすると、Multiple User Agents アラートがトリガーされます。バックエンドのサービスアカウントを識別するために、Google のロジックは次の条件に依存しています。
$e.principal.user.userid != $e.target.user.userid
[email protected] を開く) にとっても標準的な動作です。この設計上の欠陥は、通常の運用上の人間のトラフィックに対して大量のノイズを生成します。これらの設計上の欠陥を修正するには、運用ニーズに応じて 2 つのオプションがあります。
オプション 1: ネイティブ SIEM 除外 (クイックフィックス)
ルールを無効にしたりカスタムコードを書いたりする必要は必ずしもありません。Google SecOps SIEM の UI 内で直接 除外 を作成するだけです。Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) の ClientAppId と、承認済みのバックアップアプリケーション (例: Keepit) を対象とする除外を追加してください。これにより、Google のキュレーションされたルールを有効にしたまま、誤検知の洪水を即座に止めることができます。
オプション 2: カスタムルールの展開 (アーキテクチャ上の修正)
基盤となるグルーピングロジックの欠陥 (例: $application_id の不一致) を完全に修正したい場合は、Curated Detections を無効にしてカスタムルールを展開する必要があります。修正には以下が含まれます。
27922004-...) を明示的にホワイトリストに登録する。match セクションを修正して、セッションごとに適切に集約する。rule custom_ttp_o365_mailbox_access_by_service_principal_with_multiple_uas {
meta:
rule_name = "[CUSTOM] O365 Mailbox Access by Service Principal with Multiple User Agents"
description = "Detects a Service Principal with a single O365 session ID accessing O365 mailboxes with multiple user agents. Tuned to fix grouping logic and exclude Outlook Mobile (Public Client) human traffic."
severity = "Low"
tactic = "TA0009"
technique = "T1114.002"
events:
$e.metadata.log_type = "OFFICE_365"
$e.metadata.product_event_type = "MailItemsAccessed" nocase
$e.target.application = "Exchange"
$e.security_result.detection_fields["RecordType"] = /^(2|50)$/
// Extract actual Session ID and App ID
$session_id = $e.network.session_id
$application_id = $e.additional.fields["ClientAppId"]
$e.principal.user.userid !=$e.target.user.userid
(
$e.network.http.user_agent = /AppId/ nocase or $e.additional.fields["ClientAppId"] = /./
)
// EXCLUSIONS: Added Outlook Mobile + Standard Google Exclusions
$e.additional.fields["ClientAppId"] != /^(27922004-5251-4030-b22d-91ecd9a37ea4|bea75f7a-2505-46e8-9bf6-d3f7da9c9da7|b52893c8-bc2e-47fc-918b-77022b299bbc|...)$/ nocase
match:
// Group by both App AND Session to isolate the specific token lifecycle
$application_id,$session_id over 3h
outcome:
$vendor_name = "Microsoft"
$product_name = "Office 365"
$source_ua_dc = count_distinct($e.network.http.user_agent)
$client_app_id = array_distinct($e.additional.fields["ClientAppId"])
condition:
// Triggers if the SAME session rotates 2+ User Agents
$e and $source_ua_dc >= 2
}
(同じロジックですが、除外では Outlook Mobile に加えて、Keepit (a7cd46df...) などの承認済みバックアップソリューションをホワイトリストに登録してください。)
(ユーザーエージェントのルールとは異なり、Google は実際にこのルールでは $session_id で正しくグループ化しています。ただし、Outlook Mobile の除外が依然として欠けています。上記と同じ除外ロジックに従い、$source_asn_dc >= 2 の条件を維持してください。)
(同じロジックです。events ブロックの最後にある除外正規表現に、Keepit (a7cd46df...) などの承認済みバックアップアプリケーションを必ず追加してください。)
ルール: Anomalous Auth Attempts Total by Principal Hostname and Target User ID
(注: UEBA は「User and Entity Behavior Analytics」の略です。これらのルールは静的シグネチャを使用せず、数学的アルゴリズムに依存して「正常な」動作のベースラインを作成し、統計的な逸脱に対してアラートを発します。)
この UEBA ルールは、30 日間の履歴平均と標準偏差を計算することにより、異常な認証スパイクを検出しようとします。
outcome ブロックの先頭で変数 $num_stddevs_away = max(2) を宣言しています。しかし、$historical_threshold の計算では、Google 開発者は変数を使用せずに値 2 をハードコードしました。このプログラミングエラーにより、アナリストは YARA-L ロジックを完全にクローンして書き直すことなく、UI や継承された変数を介して感度を簡単に上書きすることができません。実際のテストでは、統計的な閾値を単に調整するだけ (例: $num_stddevs_away を 3 または 4 に引き上げる、$coefficient_of_variation_threshold を 0.1 から 0.05 に下げる、$observation_threshold を 15 に増やす) では不十分であることが示されています。毎週のアラート数が 710 件から 111 件に減るだけであり、アナリストチームにとっては依然として過度にノイジーです。
Broad ルールセットのアラートを無効にし、Precise アラートチャネルに厳密に依存してください。この構造的な緩和策のみが、アラートの洪水を止める効果的な方法です。$historical_threshold 内のハードコードされた 2 をカスタムの $num_stddevs_away 変数に合わせて修正し、より厳格なベースライン係数を適用してください。免責事項: これらのチューニングは、実世界のインシデント対応および SIEM エンジニアリングの経験に基づいています。本番環境に展開する前に、必ずお使いの環境で YARA-L ルールをテストしてください。