[REVIEW] siem-rules: add exception expiry and lookup freshness gates

[alejandrorivas-pixel]

Skill reviewed

skills/secops/siem-rules/

Reviewer

@alejandrorivas-pixel

Bounty type

Skill Review ($25). I am submitting this as a structured review per the repository contribution guide. I may not have permission to apply the review and bounty labels, so please tag it if accepted into the review queue.

Preferred payment method if accepted: Payment details can be provided privately after maintainer acceptance.

Summary

The SIEM rules skill is useful for KQL/SPL authoring, threshold tuning, correlation design, and lifecycle review. It already warns against noisy queries, hardcoded environment values, duplicate alerts, and missing true-positive validation.

The main gap is that suppression, exclusion lists, watchlists, and lookups are treated mostly as tuning conveniences. In production SIEM programs, these are trust boundaries: a stale lookup or broad suppression can silently disable high-value detections while making the rule appear healthy.

False positive analysis

Scheduled maintenance suppression is not automatically suspicious

A rule can include an exclusion for a maintenance window or approved vulnerability scan without being a weak detection, as long as the exception is narrow, owned, time-bound, and reviewable.

Benign Sentinel example:

let approved_maintenance = datatable(Host:string, StartTime:datetime, EndTime:datetime, Ticket:string, Owner:string)
[
  "jumpbox-01", datetime(2026-06-07T01:00:00Z), datetime(2026-06-07T03:00:00Z), "CHG-4821", "secops@example.com"
];
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| join kind=leftouter approved_maintenance on $left.DeviceName == $right.Host
| where isempty(Ticket) or TimeGenerated < StartTime or TimeGenerated > EndTime

That exclusion should not be reported as suppression abuse. It has a bounded entity, explicit start/end, ticket, and owner.

Environment-specific lookup use is not automatically hardcoding

The skill correctly discourages hardcoded usernames, hosts, and IPs. However, a rule that uses a Sentinel watchlist, Splunk lookup, or KQL datatable can be portable and maintainable if the lookup source has freshness, ownership, and schema evidence.

Lower-risk example:

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624
| lookup approved_scanner_sources ip as IpAddress OUTPUT expires_at owner ticket
| where isnull(expires_at) OR now() > strptime(expires_at, "%Y-%m-%dT%H:%M:%SZ")

The finding should be based on stale or unbounded lookup governance, not lookup usage itself.

Coverage gaps

1. Suppression and exclusion governance is under-specified

The skill mentions exclusion management and review dates, but it does not require reviewers to validate:

• exception owner
• ticket/change reference
• creation date
• explicit expiry or next review date
• bounded entity scope
• reason/category
• reviewer approval for broad exceptions
• evidence that expired exceptions are removed

Risky pattern:

let excluded_users = dynamic(["svc-backup", "admin", "testuser"]);
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 0
| where UserPrincipalName !in (excluded_users)

This can hide compromised privileged or service accounts indefinitely. It should be flagged unless the exclusion source is scoped, owned, and time-bound.

2. Lookup/watchlist freshness is not validated

The skill recommends watchlists and lookup tables, but it does not tell reviewers how to verify whether those data sources are stale, incomplete, or untrusted.

Risky Splunk pattern:

index=proxy sourcetype=bluecoat
| lookup threat_intel_domains domain as cs_host OUTPUT threat_score
| where threat_score >= 80

If threat_intel_domains has not been refreshed for weeks, the rule can miss active indicators while still returning valid-looking results. Reviewers should ask for last_updated, feed source, TTL/expiration, owner, schema mapping, and failed-refresh monitoring.

3. Broad suppression windows can hide multi-stage activity

The skill discusses suppression windows as duplicate-alert control, but does not distinguish duplicate suppression from entity- or incident-level blind spots.

Risky configuration:

Suppression: enabled for 24h
Grouping: all events into single alert
Rule: privilege escalation followed by lateral movement
Entity grouping: none

For high-severity detections, suppression should be entity-aware and scenario-aware. A 24-hour global cooldown can suppress activity from different hosts, users, or tenants.

4. Output lacks exception-evidence fields

The output template has known false positives and threshold configuration, but no structured fields for suppression/lookup evidence. Reviewers need a place to record what was inspected and what is not evaluable.

Suggested output addition:

### Suppression and Lookup Evidence
| Control | Evidence reviewed | Risk if missing |
| --- | --- | --- |
| Exception owner/ticket | [watchlist columns, change record] | unapproved blind spot |
| Expiry/review date | [expires_at, review_due] | permanent suppression |
| Lookup freshness | [last_updated, feed TTL, refresh job status] | stale enrichment |
| Entity-aware grouping | [user/host/IP/tenant keys] | unrelated activity hidden |

Edge cases

• Break-glass accounts may need different alerting logic, not a blanket exclusion.
• Vulnerability scanners and EDR/IT automation are common false positives, but their IP ranges and service accounts change; stale allowlists create blind spots.
• Threat-intel lookups can fail open if the lookup job fails and the detection query treats missing enrichment as benign.
• Managed SIEM deployments may keep lookup governance in a separate repo or ITSM system. In that case, the finding should be Not Evaluable rather than confirmed unsafe.
• Multi-tenant environments need tenant-scoped suppressions so an exception for one tenant does not suppress another tenant's activity.

Remediation quality

Strong existing guidance:

• baseline before alerting
• tune thresholds with TP/FP ratios
• avoid hardcoded environment values
• use suppression windows to reduce duplicate alerts
• track rule health metrics and lifecycle stage

Recommended improvements:

1. Add explicit exception governance gates: owner, ticket, bounded scope, creation date, expiry/review date, and approval for broad suppressions.
2. Add lookup/watchlist freshness checks: feed source, last_updated, TTL, schema mapping, refresh status, and failed-refresh alerting.
3. Distinguish global cooldowns from entity-aware suppression and require entity grouping for high-severity rules.
4. Add vulnerable and benign fixtures for stale lookup use, broad suppressions, and time-bound maintenance exclusions.
5. Add a suppression/lookup evidence table to the output template.

Tool comparison

Tool	Similar coverage	Gap relative to this skill
Microsoft Sentinel analytics rule UI	Supports suppression, entity mapping, watchlists, and rule scheduling	Does not by itself enforce exception owner, expiry, or watchlist freshness governance
Splunk Enterprise Security	Supports notable suppression, lookup enrichment, and correlation searches	Suppression/lookup governance depends on local process; stale lookups can still produce valid syntax
Sigma	Can describe detection logic portability	Does not model SIEM-specific lookup freshness, notable suppression, or watchlist ownership well
Detection-as-code pipelines	Can test query syntax and expected results	Often miss operational exception lifecycle unless explicit metadata gates are required

Suggested test cases to add

1. Benign KQL maintenance exclusion with owner, ticket, bounded host, start/end time: should not be flagged as suppression abuse.
2. KQL rule excluding admin or svc-* forever with no owner or expiry: should be flagged.
3. SPL lookup with expires_at, owner, and failed-refresh monitoring evidence: should be accepted as governed enrichment.
4. SPL threat-intel lookup with no last_updated, TTL, or refresh evidence: should be flagged as stale-enrichment risk.
5. High-severity rule with 24-hour global suppression and no entity grouping: should be flagged.
6. Multi-tenant rule with tenant-scoped suppression keys: should be lower risk than global suppression.

References

• Microsoft Sentinel analytics rules: https://learn.microsoft.com/en-us/azure/sentinel/detect-threats-built-in
• Microsoft Sentinel watchlists: https://learn.microsoft.com/en-us/azure/sentinel/watchlists
• Microsoft Sentinel entity mapping: https://learn.microsoft.com/en-us/azure/sentinel/map-data-fields-to-entities
• Splunk lookup command: https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Lookup
• Splunk Enterprise Security notable event suppression: https://docs.splunk.com/Documentation/ES/latest/Admin/Customizenotablesuppression
• MITRE ATT&CK Data Sources: https://attack.mitre.org/datasources/

[alejandrorivas-pixel]

[Codex GPT-5] Implementation PR submitted: #1222

Validation passed: git diff whitespace checks, staged diff whitespace checks, Markdown fence balance, ASCII check for changed SIEM files, content marker checks for suppression/lookup governance sections and fixtures, prompt-injection term scan on new fixtures, and reference URL reachability via curl for Microsoft Sentinel watchlists and Splunk lookup docs.

Payment details can be provided privately after maintainer acceptance.