Suppressing a false positive

A false positive is an alert that was technically correct and operationally useless: the pattern really did occur, and the cause was your own business doing its job. Your vulnerability scanner really did port-scan the network. Your administrator really did sign in over the device-code flow, because she was working over SSH with no browser.

A suppression is the tool for that. It is an exclusion applied before a rule is evaluated: name a field and a set of values, and an event carrying any of those values is not evaluated against that rule at all. This article is about using it narrowly, because a suppression is also the easiest way in the whole product to make yourself blind to something on purpose.

Why the mechanism exists at all

Every rule in the library ships with mandatory false-positive guidance, and that guidance is written to produce suppressions. It says things like allowlist by the specific administrator's user_id rather than disabling the rule, and exclude the known metadata.app_id values rather than the flow.

That advice only works if it is expressible. Consider the port-scan rule and a legitimate weekly vulnerability scan. If exclude the scanner's source address cannot be written down as data, your only remaining option is to disable the port-scan rule entirely — and then the scanner's own host becomes the one place in your network where a real scan would be invisible. Which is, of course, exactly the host an attacker would want to be on. Suppression exists so that the narrow, correct answer is available and the broad, wrong one is not the only one.

What a suppression can and cannot express

An entry has three parts: a field, a list of values, and a reason. The field is resolved exactly as a rule condition resolves it, so any top-level field or dotted metadata path works — user_id, source_ip, host, metadata.app_id, metadata.process_name, metadata.geo_country.

The matching is deliberately simple, and the limits matter more than the capability:

One further caveat, from the same mechanism: paths under metadata.ocsf resolve correctly when an event is read, but they are not in the contract, so they cannot be used in a suppression. If the value you want to exclude on is only reachable there, that is a request for the field to be added to the contract, not something to work around.

Doing it

1. 1

   Establish what the innocent cause actually is

   Not the alerts are noisy — the specific thing. Read three or four of the alerts together and find the value they share. Then read the rule's false-positive guidance, which very often names the cause and the field before you have finished working it out yourself.

2. 2

   Pick the narrowest field that identifies it

   Prefer the thing that is genuinely the exception. If the cause is one administrator's tooling, suppress on her user_id, not on the authentication flow — the flow is what the rule is for. If the cause is one appliance, suppress on its host or source_ip. If the cause is one application, suppress on metadata.app_id. Suppressing on the mechanism rather than the actor is how a legitimate exception becomes a general amnesty.

3. 3

   Write the reason before you write the values

   If you cannot state the reason in one sentence that names a system and a person, you do not yet understand the exception well enough to make it. The reason is stored on the entry itself, so the suppression list stays reviewable rather than becoming a pile of exclusions nobody remembers agreeing to.

4. 4

   Send the whole list, not just the new entry

   Suppressions are set as a complete list on the rule's tuning endpoint: PUT /api/v1/organizations/{orgID}/siem-detection-rules/{ruleRef}/tuning with a suppressions array. The list you send replaces the list that was there. Read the current one first and include the existing entries, or you will silently delete a colleague's exception. The body is capped at 64 KiB, which in practice bounds how long the list can get — which is a reasonable bound to be constrained by.

5. 5

   Wait 30 seconds, then confirm on live traffic

   Effective rules are cached per organisation for 30 seconds, so the change is not instant. Then confirm two things, in this order: that the alerts you meant to stop have stopped, and — more importantly — that the alerts you did not mean to stop are still arriving. A suppression that silences more than you intended looks exactly like a suppression that worked.

6. 6

   Write down a review date somewhere you will see it

   The platform does not expire a suppression for you. See the next section — this step is the one people skip, and it is the one that matters in two years' time.

{
  'suppressions': [
    { 'field': 'source_ip',
      'values': ['10.20.0.14'],
      'reason': 'Nessus scanner, server room. Agreed with Dawn 2026-09-01, review 2027-03-01.' },
    { 'field': 'user_id',
      'values': ['[email protected]'],
      'reason': 'Veeam service account. Reviewed at the March 2026 change board.' }
  ],
  'reason': 'Adding the server-room scanner; existing Veeam entry preserved.'
}

Why suppression is never permanent by itself

The most attractive thing an intruder could persuade a detection system to do is to stop looking at them — permanently, quietly, and with a plausible justification recorded next to it. A permanent blind spot is not a side effect of suppression. It is the objective, from the attacker's point of view.

So there is a structural limit on the automated side of the platform: Sentinel-Q may never suppress anything autonomously. Suppression is classified as an action that can only ever be recommended to you, at every autonomy tier including the highest one, and the check that enforces it also refuses any suppression proposal that carries no expiry — the internal refusal reads a suppression with no expiry is a permanent blind spot. Sentinel-Q can tell you that a rule is noisy, can tell you which field to exclude on, and can prepare the change. It cannot make it. See What Sentinel-Q is allowed to do.

The rule library's own guidance takes the same line wherever an exception is genuinely temporary. On the audit-policy rule: suppress for the duration of the hardening change window and re-enable afterwards; the direction of the change is not in the event ID, so a time-boxed suppression is more honest than a permanent filter. On the cloud audit-trail rule, about consolidating trails: handle it with a time-boxed suppression tied to the change window, never a permanent exclusion.

The other thing called suppression

One word covers two mechanisms and only one of them is a blind spot. When a rule has already fired for an entity, its cooldown swallows the repeat alerts for a period — and that is reported rather than hidden, so the console can tell you 12 further occurrences suppressed. Nothing was excluded; the events were seen, counted and folded into the same finding.

If your complaint is one real event produced forty alerts, the cooldown is your control and it is a safe one, because the rule keeps its full sensitivity. If your complaint is this legitimate thing keeps matching, the suppression list is your control and it is the sharp one. Choosing the wrong one of the two is how people end up excluding a whole class of activity when what they actually wanted was fewer duplicates.

Prefer narrowing to disabling — in this order

1. Lengthen the cooldown. Fewer duplicates, no loss of sensitivity, nothing excluded. Try this first whenever the noise is repetition.
2. Add a narrow suppression on the single field that identifies the innocent cause, with a reason and a review date.
3. Raise the threshold, if the judgement you are making is genuinely about volume rather than about a specific actor. Read the rule's threshold rationale first — it tells you what the shipped number was protecting against.
4. Move the rule to testing. It keeps evaluating, keeps recording findings and keeps feeding risk; it just stops interrupting you. This is almost always better than disabling.
5. Disable it. Last. With a reason, which is mandatory here. And with the understanding that from then on, an absence of alerts from that rule tells you nothing at all.

Note what all five have in common except the last: the detection survives. That is the whole point. The cost of a suppression is paid quietly and much later, by whoever is investigating something and does not know that this particular thing stopped being watched.

What to read next

1. Tuning a detection rule — the other eight things you can change, and the full procedure.
2. How your logs are normalised — the field names a suppression is allowed to use.
3. What Sentinel-Q is allowed to do — where the structural limits on automated action come from.