Last reviewed:
False-positive tuning should remove known-good activity from the SIEM alert path while leaving the attacker behaviour intact. If tuning changes the behaviour being detected, it has gone too far.
Before tuning a noisy rule, restate the attacker behaviour in one sentence. For example: a new credential is added to a cloud service account, a diagnostic setting is disabled, or a suspicious child process starts from a web server. That sentence is the part you must not tune away.
Then list the legitimate systems that produce the same signal. Most useful suppressions are boring: deployment automation, break-glass accounts, vulnerability scanners, backup jobs and approved maintenance scripts.
A broad exclusion is tempting when alerts are noisy. It is also where detections go to die. Suppressing every administrator, every internal IP or every service account may silence the queue while handing attackers a clean path through the rule.
Use narrow conditions instead. Suppress a named automation principal only when it calls an expected API from an expected network during an approved window. Keep the base behaviour visible outside that lane.
Sigma is the portable source rule. Production tuning belongs in the SIEM where the tenant's field names, enrichment tables and allowlists live. That keeps the shared rule useful while letting each environment handle its own noise.
For Splunk, this may mean lookup tables and macros. For Sentinel, it may mean watchlists and KQL joins. For Google SecOps, Elastic or OpenSearch, the same principle applies: keep the attacker condition, then subtract known-good context as close to the alerting layer as possible.
Every tuning change needs a before-and-after check. Count how many historical alerts disappear, then replay a known-bad or synthetic event that should still fire. If the test event no longer alerts, the suppression is too wide.
Good tuning leaves a note for the next analyst: what was suppressed, why it was safe, who approved it and when to review it. Six months later, that note matters more than the clever query change.
[ ] Attacker behaviour is still present in the condition
[ ] Suppression names exact known-good sources
[ ] Test event still alerts after tuning
[ ] Owner and review date are recorded
[ ] Temporary exceptions have an expiry date