fix(o365): stop alert floods from nine Office 365 rules

[kryonsx]

Why

Since v11.2.14 these Office 365 rules alert on routine Microsoft 365 activity, and the rule flood guard switches them off. Filter 1.4.1 now keeps OneDrive and SharePoint file access and download records, several rules count far below everyday volume, two rules added on 2026-09-25 have no volume threshold, and grouped rules still store one child alert for every matching event. The target is fewer than 10 alerts per hour per rule on any server.

Noise is reduced only by de-duplication, trigger thresholds, or removing a trigger or rule that does not belong. No account or application is excluded by name. Thresholds were set from 30 days of per-identity volumes on v11 deployments, far above everyday use.

What changes

Every changed rule raises one alert per identity (per IP address for password spraying) and drops repeats for seven days with deduplicateBy, instead of groupBy.

Rule	Trigger before	Trigger after
Microsoft 365 Mailbox Mass Item Access	every MailItemsAccessed record	2,000 MailItemsAccessed records per identity within 1h
OneDrive Mass File Access Detected	67 per operation within 30m	1,000 per operation (FileAccessed, FileAccessedExtended, FilePreviewed) within 1h
SharePoint Mass File Download Detected	100 FileDownloaded within 30m	500 within 1h
Suspicious Teams Message Export Activity	20 Teams records within 1h	100 within 1h
Mass Email Deletion Detected	100 HardDelete or 100 SoftDelete within 15m	200 HardDelete or 5,000 SoftDelete within 1h
Potential Password Spraying of Microsoft 365 User Accounts	any 5 records from the IP within 60s	50 UserLoginFailed records from the IP within 10m
O365 Audit Log Purge	DSIPurgeStarted, AuditSearchDeleted, HardDelete	DSIPurgeStarted, AuditSearchDeleted
O365 Admin Role Assignment	Add member to role., Add member to group., Add delegated permission grant.	Add member to role.
O365 Admin Role/Permission Granted	Update user. with TargetId.UserType	removed

Why each trigger means what it now claims, from Microsoft's audit log activities, Teams activities and MailItemsAccessed references:

• MailItemsAccessed records every mail read by any client and groups the messages one client reads within two minutes into one record, so 2,000 records in an hour is bulk reading, not ordinary use.
• FileAccessed is not logged again for the same user and file within five minutes, so 1,000 in an hour means at least 84 different files. FilePreviewed and FileAccessedExtended are counted separately, as before.
• Downloading a folder as a ZIP file writes one FileDownloaded record per file.
• MessagesListed ("Retrieved messages") is logged only for Microsoft Graph API calls, which backup and compliance applications make continuously.
• SoftDelete removes a message from Deleted Items; emptying a large folder writes thousands of records. HardDelete purges a message from Recoverable Items.
• HardDelete is a mailbox purge, not audit data, so it no longer triggers O365 Audit Log Purge; mass purges are Mass Email Deletion. DSIPurgeStarted (a Data Security Investigations purge job) and AuditSearchDeleted remain.
• Password spraying now counts failed sign-ins only (the old history search counted any record from the address, including successful ones).
• "Add member to group." and user consent grants ("Add delegated permission grant.") are not role assignments.
• O365 Admin Role/Permission Granted described itself as a stand-in for "Add member to role." records; those are available and covered by O365 Admin Role Assignment, while its Update user. condition matches almost every user update. The startup definition sync deletes shipped rules whose names disappear, so deployments drop it.

Tests

• plugins/alerts/o365_alert_volume_test.go (new) runs fabricated records through the checked-in O365 filter and the pinned go-sdk v1.1.36 CEL and history code. It pins every threshold, window, history scope and de-duplication key: below the threshold, at it, outside the window, a different identity, and the records that must no longer match.

• o365_action_result_rules_test.go: the password spraying history case moves to 10m, 50 and the action term.

• go test ./... in plugins/alerts: all O365, contract, grouping and placeholder tests pass. TestBitdefenderActionResultRaw fails in the same way on untouched v11 (dda9d45a) and is unrelated.

• Local EventProcessor lab (engine 8a3ade7, go-sdk v1.1.36, production events and alerts plugins, OpenSearch 2.19.1), fabricated identities, seed events spread over several runs so the history counts are real:

  • 23,607 events over nine runs (every run processed all its events): one run older than the windows, six seeding runs, one trigger run, one repeat run.
  • Each identity at the threshold stored exactly one alert and every later repeat was dropped as a duplicate: mailbox (2,000), OneDrive FileAccessed and FilePreviewed (1,000 each), downloads (500), Teams (100), HardDelete (200), SoftDelete (5,000), password spraying (50 from one address), audit purge (one per operation), role assignment (one per actor and target).
  • Identities just below each threshold, and seeds older than each window, stored none. Group membership, consent grants and HardDelete no longer trigger the admin role and audit purge rules.
  • Same inputs with the rules as shipped: 21,593 alerts produced. With this branch: 71 produced, 32 stored.
  • Known engine limit, not changed here: 20 alerts for one identity that arrive at the same instant were all stored, because plugins/alerts checks for duplicates in parallel. A per-rule-and-key lock around the duplicate check and store would remove these copies for every rule.

Follow-up, not in this PR

"Office 365 App Consent Grants Detected" and "Office 365 OAuth Application Anomalous Activity" test Consent to application without the final period that Microsoft records (Consent to application.), so they never match. With consent grants out of O365 Admin Role Assignment, those two rules are where user consent should be detected, once fixed with their own volume check.

🤖 Generated with Claude Code