Skip to main content

Suppress Noisy Security Incidents

Tasks

Create a suppression rule for findings you have decided are safe to hide, such as a CI job that trips the same policy every few minutes. A rule always has a reason and an expiry of at most 90 days, and every change is recorded.

Before you start​

Only administrators create or revoke rules. Viewers can read the Suppressions list. A rule hides findings from incidents; it does not stop the control that produced them. A denied call is still denied and still recorded in the audit log. For how incidents are formed, see Security posture.

Create a rule​

  1. Start from an incident. Open an incident under Security → Activity → Correlated findings and select Suppress similar, which appears on an incident the Judge marks likely benign. The dialog is filled in from the incident's actor, detection type, policy and target. From the security briefing, Suppress for 30 days on a Clear the noise group opens the same dialog.
  2. Choose what to match. Clear any field you do not want to match on. A rule needs at least one of Actor, Detection type, Policy, Plugin, Entity and Target, and a finding must match every field you leave filled in. Actor and Target are an exact kind:id, or kind:* for every actor or target of that kind (a * is allowed only as the whole id), for example user:* or server:*.
  3. Check the preview. The dialog counts the findings from the last 7 days that the rule would have matched. Narrow the rule if the number is larger than you expect.
  4. Give a reason and an expiry. The reason is required. Choose 7, 30 or 90 days; there is no rule without an end. Select Create rule.

What a rule hides​

A rule is in effect from the moment you create it until it expires or you revoke it. Findings recorded in that period are left out before incidents are formed, so they never open or extend an incident. Findings recorded before the rule existed are unchanged.

When the rule ends, the findings it hid stay hidden. Findings recorded after it ends form incidents again as usual. A rule that expires does not bring back a backlog of incidents.

An incident that was already open when you created the rule stays in the list until you resolve it; only its later findings are hidden. Its time to acknowledge and resolve are left out of the triage metrics.

Review and revoke rules​

  1. Open the list. Select Suppressions in the grouping switch on Correlated findings. The Active, Expired and Revoked tabs show each rule's match, reason, creator, expiry and the number of findings it has hidden in the retained 31 day window.
  2. Revoke. On an active rule, select Revoke and add a reason if you want one. Findings hidden so far stay hidden; findings recorded after the revoke form incidents again.

Rules and their history are kept as part of the triage record. At most 200 rules can be active at once, and a new rule is refused while 500 rules are active or ended in the last 31 days, because every incident read tests each of them. Wait for old rules to age out of that window.

Audit​

Creating and revoking a rule are recorded in Security → Activity → Configuration as security_suppression.created and security_suppression.revoked, in the same transaction as the change. The reason text is kept with the rule, not in the configuration audit. Rules active in a date range are included in the triage record export.

For the API, see Suppression rules.