Suppressions
Keep known noise out of the signal queue without weakening the rule.
Why suppress rather than change the rule #
A rule that fires on something you have already decided is fine is doing its job correctly. The fix belongs on the input side, not in the rule: a suppression removes the known case from what the rule sees, and leaves the rule itself able to catch everything else.
That distinction matters. Editing a shipped rule to exclude a scanner's address also removes it as a signal for every other pattern; a suppression applied to that rule leaves the rule working everywhere else.
What a suppression is #
- Name — what it is for, in words your team will recognise.
- Rule — the rule it applies to, or every rule when left open.
- Expression — the events to remove, in the same query syntax you use anywhere else.
- Lifetime — how long it lasts. This is the field that matters most.
- Enabled — whether it is filtering at all.
Writing the expression #
The expression uses the same syntax as a search, so a suppression can be written by pasting the search that found the noise in the first place.
@network.client.ip:10.20.0.15 OR @usr.id:deploy-botScope it to the rule that needs it
A suppression with no rule applies everywhere, which is rarely what you want: the same condition is often legitimate under one rule and an attack under another.
Lifetime #
The lifetime is the safeguard. A suppression with an end date is a decision you made once and will be asked about again; a suppression that never expires is a blind spot that nobody owns.
- Never — indefinite, for the case that genuinely is permanent.
- 24 hours — a maintenance window.
- 7 days — a temporary test run.
- 30 days — a sprint cycle, forcing a decision at the end of it.
Prefer the shortest lifetime that covers the noise. A 30-day suppression on a deploy bot should become a permanent one only when you are confident the account will keep being used the same way.
Reviewing what you have #
The suppression page is worth looking at on a schedule, because suppressions accumulate and each one is a place a real signal can stop appearing. It groups them by what they are currently suppressing, shows which are expiring soon, and flags the disabled and expired ones that are no longer doing anything.
- Suppression metrics — how much each suppression is actually removing.
- Expiring soon — the ones that need a decision.
- Rule binding coverage — how many of your rules have one, and which are being suppressed everywhere at once.
A suppression that suppresses a great deal is worth understanding before it is trusted, and a rule with suppressions across it may be better served by making the rule more precise.
Signals are handled differently from suppressions
Muting a signal hides it from you. A suppression means the event never became a signal in the first place, so it costs nothing to carry and is recorded separately in the audit trail.
Removing one #
Deleting a suppression takes effect immediately and the matching events begin raising signals again. Removing one is the right move when the noise has stopped, and it is the fastest way to confirm a suppression was covering something real.
Give every suppression an end. The ones with no end date are the ones that turn into a gap nobody remembers creating.
Onward #
Suppressions change what Detection rules can see, and the resulting queue is Security signals.