Tune a noisy rule when you can describe the benign behavior precisely. Suppress only for a short, documented period with an owner. Retire the rule if nobody acts on it. Never silence a rule because it is annoying, and be careful when an AI assistant proposes the exclusion.
Start by naming the noise
Pull a sample of recent alerts from the rule and sort them. How many were benign? What did the benign ones have in common: a user group, a host type, a scheduled job, a software update?
If you cannot describe the pattern, you are not ready to change the rule. Gather more samples first.
The four options
1. Tune the logic. Change the rule so it describes the suspicious behavior more exactly. In Sigma, real exclusions go in the detection logic as a filter selection combined with not in the condition. The falsepositives field is only a note for humans and is not parsed by converters.
2. Add a narrow exclusion. If a specific known good source causes the noise, exclude that source by exact value, not by broad pattern. Record who approved it and why.
3. Suppress temporarily. Use this when a known event, such as a migration, will cause noise for a few days. Set an end date and an owner. Review when it ends.
4. Retire the rule. If the rule never produces action, or the behavior is covered better elsewhere, remove it and note why.
A decision guide
- Benign pattern is exact and stable: narrow exclusion or tune.
- Benign pattern is vague: gather more data first.
- One off event: temporary suppression with an end date.
- Rule never leads to action: retire it.
- Exclusion would hide the attack too: rewrite the rule, do not exclude.
The last item matters. If the benign and malicious cases look the same at this log level, an exclusion removes your detection. You may need another data source.
Be careful with AI suggested exclusions
A model asked to reduce false positives will often suggest broad exclusions, since they work fastest. Check each one by asking what an attacker could do inside the excluded set. The Sigma rule review checklist applies to changes as well as new rules.
Keep a record
For every change, record the date, the reason, the data you looked at, the approver and a review date. Keep rules and changes in version control, as in a detection as code pipeline for Sigma rules.
Test after changing
Replay a simulation of the malicious behavior and confirm the rule still fires. Then check alert volume after a week. A change you do not test may have fixed the noise by breaking the rule.
Quick check
Is suppression the same as exclusion?
No. An exclusion permanently changes what the rule matches. Suppression silences output for a limited time while the rule logic stays the same.
Who should approve exclusions?
Someone other than the person who wrote the change, ideally the rule owner or a senior analyst, with the reason recorded.
Sources
Last reviewed: 19 October 2026.
