← All recipes · Ops
Tell the SuppressionMatcher 'this pattern is noise' once — and have every future matching event silently dropped, with the audit chain still capturing the suppression.
Last updated 2026-06-07 · 4 steps
§1
§2
You'll select repeated events that share a correlation key, click Suppress, pick a disposition, and verify the rule is active by watching the next matching event get dropped (with a `signal_suppressed` audit row).
§3
Open /signals. Look for repeated rows that share a `correlation_key` — the dashboard shows the key in the row detail. The matcher keys on this exact correlation_key, so a rule covers every future event with the same key.
Common patterns: same source IP + same disposition (TP-SCAN repeated 30 times), same user_agent + same endpoint (a probe pattern).
You can identify at least 3 rows that share a correlation_key.
Check the checkbox at the start of each row you want to suppress. The toolbar at the top of /signals now shows a Suppress button.
Click Suppress. A modal opens asking for the disposition (FP-BENIGN, FP-EXPECTED, DUPLICATE) and an optional comment. Pick the disposition that best fits why this is noise.
The modal closes; a toast confirms 'Rule created'. The selected rows now show a 'suppressed' badge.
Open /suppression. Your new rule appears at the top of the table with the correlation_key, disposition, author, and a match_count starting at the suppressed batch.
The rule is active immediately — future events matching the correlation_key will not appear in /signals.
$ cybercli audit tail -n 5`cybercli audit tail` shows a `suppression_rule_created` row carrying the rule_id + the correlation_key + the disposition + you as actor.
Wait a few minutes (or generate the matching pattern manually if you can). When a matching event arrives, it does NOT appear on /signals — it's dropped at the prefilter stage.
The audit chain still records the drop. Filter /audit by outcome=`signal_suppressed` to see the silenced events; they carry the rule_id and the original event_id so forensic replay can re-derive what would have fired without the rule.
/signals no longer shows the pattern. /audit shows `signal_suppressed` rows incrementing. /suppression shows the rule's match_count climbing.
§4
§5
Cause The selected rows don't all share a correlation_key, OR at least one selected row has no correlation_key (the matcher needs one to write a rule).
Fix Select fewer rows, or select rows you've confirmed share a correlation_key in the row detail panel.
Cause Either no new events match the rule, OR the rule's correlation_key is too narrow.
Fix Check /audit for new events matching the connector + disposition. If events still match the broader pattern but not the exact correlation_key, edit the rule to broaden the key, or delete + re-author with a tighter selection.
Cause The drift detector noticed the rule hasn't matched in 24h while it used to match steadily. Could mean the attacker mutated past it OR the pattern legitimately stopped.
Fix Review the audit log for the original pattern's presence in the last week. If the pattern stopped legitimately, mark the rule reviewed; if you suspect mutation, deactivate the rule and let the events flow to the gate so the Warden can reassess.
What to do next