[Rule Tunings][Rule Deprecation] Google Workspace authentication policy modification rules

[imays11]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/905

Summary - What I changed

Updates four Google Workspace authentication policy rules with refreshed threat-centric descriptions and investigation guides, investigation_fields for alert triage, and targeted alert suppression where trade-lab testing showed multi-event bursts. One overlapping MFA rule is deprecated.

Shared changes across updated rules:

• data stream specific index
• Descriptions and investigation guides rewritten to focus on threat impact and practical triage (Admin console paths, KQL examples) instead of generic MFA/password background
• investigation_fields added
• event.provider / event.category filters removed from queries
• Alert suppression added where a single admin action generates multiple events (130m window, matching rule lookback)

Deprecated — MFA Disabled for Google Workspace Organization

Overlaps with Google Workspace MFA Enforcement Disabled (For Organization) on the same admin telemetry. Renamed with Deprecated - prefix to start deprecation process.

Google Workspace MFA Enforcement Disabled For Organization (renamed)

Org-level admin change (ENFORCE_STRONG_AUTHENTICATION or ALLOW_STRONG_AUTHENTICATION with new_value:false).

• Query expanded to include ALLOW_STRONG_AUTHENTICATION.
• Investigation guide clarifies this is tenant/Org-level policy tampering, distinct from user-level 2sv_disable.

Screenshot of both Allow and Enforce event.action settings in Admin Console + Duplicate Alerts for both MFA rules

Google Workspace 2SV Policy Disabled By User (renamed)

User-level 2sv_disable event, not an admin policy change.

• Query expanded to include both google_workspace.login and google_workspace.user_accounts indexes.
  • Google mirrors this event across both streams, the user_accounts stream is narrower in scope (produces less events). Customer telemetry shows at least one customer customizing the rule to use the narrower user_accounts data stream. Others may do the same and miss this alert as it currently only looks at the login data stream.
• Suppression on user.email + source.ip prevents duplicate alerts when both streams are ingested.

Screenshot of both login and user_accounts streams surfacing the same event

Google Workspace Password Policy Modified

A single Admin console save emits one CHANGE_APPLICATION_SETTING event per checkbox (e.g. min/max length, reuse, strong password).

• Suppression on user.email + org_unit.name + source.ip consolidates these into one alert per modification session.
• Guide calls out high-risk weakening patterns via old_value / new_value.

Screenshot of Password Modification options in Admin Console and Corresponding Alerts

How To Test

All rules manually tested and data is currently in trade-lab shared stack.

[github-actions]

Rule: Tuning - Guidelines

These guidelines serve as a reminder set of considerations when tuning an existing rule.

Documentation and Context

• Detailed description of the suggested changes.
• Provide example JSON data or screenshots.
• Provide evidence of reducing benign events mistakenly identified as threats (False Positives).
• Provide evidence of enhancing detection of true threats that were previously missed (False Negatives).
• Provide evidence of optimizing resource consumption and execution time of detection rules (Performance).
• Provide evidence of specific environment factors influencing customized rule tuning (Contextual Tuning).
• Provide evidence of improvements made by modifying sensitivity by changing alert triggering thresholds (Threshold Adjustments).
• Provide evidence of refining rules to better detect deviations from typical behavior (Behavioral Tuning).
• Provide evidence of improvements of adjusting rules based on time-based patterns (Temporal Tuning).
• Provide reasoning of adjusting priority or severity levels of alerts (Severity Tuning).
• Provide evidence of improving quality integrity of our data used by detection rules (Data Quality).
• Ensure the tuning includes necessary updates to the release documentation and versioning.

Rule Metadata Checks

• updated_date matches the date of tuning PR merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive. Review to ensure the original intent of the rule is maintained.

Testing and Validation

• Validate that the tuned rule's performance is satisfactory and does not negatively impact the stack.
• Ensure that the tuned rule has a low false positive rate.