Tuning a Noisy Rule (with the Suggestions Panel)

The Suggestions panel at the top of the Rules page turns operator dispositions into concrete tuning recommendations. When your team has dismissed the same alert enough times that a pattern is clear, Burrow's tuning advisor proposes a specific change. This article walks the two kinds of suggestion you will see, plus a manual tuning path for cases where the advisor has not yet produced a recommendation.

Where the Suggestions panel lives

1. Open the Burrow dashboard → Rules in the left navigation.
2. The Suggestions panel sits at the top of the page, above the Detection posture dropdown.

If the panel is empty, there are no recommendations right now — usually a good sign.

Two kinds of suggestion

1. Dismissal-driven suggestions (the most common)

When the same (user, category) pair has been marked Not real three or more times in the last 14 days, the tuning advisor proposes adding an entity exception for that pair. Reads as:

Add exception for bob.smith@example.com on unusual_hour_activity (dismissed 4 times in 14 days)

The proposed action: a Suppress entity exception for that user pattern + category. One click on Apply writes the exception. Future alerts of that pair stop firing.

This is by far the most useful suggestion kind — it learns from the SOC team's actual triage decisions and proposes silencing the things you have already proven you do not want to see.

2. Threshold-tuning suggestions

When a specific rule produces dismissed alerts at high volume across many users (not just one (user, category) pair), the tuning advisor proposes raising the rule's threshold. Reads as:

Raise data_exfiltration_med.bytes_downloaded from 256 MB to 1 GB (137 dismissed alerts in 14 days)

One click on Apply writes the per-rule override. Future alerts of that category only fire above the new threshold.

What each suggestion has

Whether dismissal-driven or threshold-tuning, every suggestion shows:

• A subject — the (user, category) pair or the rule the suggestion targets.
• A rationale — the dismissal count and the lookback window.
• A proposed change — the exact entity exception or threshold change that will be written.
• Apply / Dismiss buttons.

Apply writes the change immediately. It appears on the History page attributed to your operator account, with a source tag identifying it as dismissal-driven. The created exception appears on the Exceptions page tagged as such, so you can later tell auto-derived exceptions apart from ones you added manually.

Dismiss removes the suggestion from the panel. The same suggestion will not re-surface for several days; if the underlying dismissal pattern continues, it will come back.

The workflow

The recommended cadence is a weekly review on Monday morning, alongside the weekly executive briefing:

1. Open the Rules page and read every suggestion in the panel.
2. For each suggestion ask:
   • Does this match my environment? If yes, click Apply. If you are unsure, click Dismiss and re-evaluate next week.
   • Is the rationale right? The dismissal count is your team's own input — if it surprises you, talk to your SOC shift first.
3. After applying, watch the Alerts page for the next few days to confirm the noise has actually dropped.

When to override the suggestion

The tuning advisor sees disposition patterns, not your environmental context. Sometimes it is wrong:

• It may suggest a (user, category) exception when the right move is a posture change because the rule is noisy across many users. If you find yourself applying many same-rule exceptions across different users, the rule itself is the problem — change the per-rule override (or the posture).
• It may suggest raising a threshold past the next posture's default. If you are constantly fighting noise on one rule, the right move may be a posture change rather than rule-by-rule overrides.

In both cases: Dismiss the suggestion and use the posture-overrides workflow or the entity-exception workflow instead.

Auto-suppress: skip the click

For mature SOC teams that want noise reduction without the weekly review, an opt-in Dismissal auto-suppress feature applies the same 3-in-14-days dismissal threshold automatically — no Suggestion review, no Apply click. See Dismissal auto-suppress for the trade-offs.

Manual tuning when there is no suggestion

The tuning advisor only surfaces a suggestion after the threshold has been crossed (dismissals over multiple days for a specific pair, or sustained volume for a rule). If you want to act on a noisy rule sooner:

1. Open the Alerts page filtered to the noisy category. Look at the volume and which users are firing it.
2. If it is concentrated on a small number of accounts → add entity exceptions for those accounts directly.
3. If it is spread across many users → raise the rule's threshold via a per-rule override on the Rules page.
4. Before saving the override, use Rule replay to preview what the rule would have caught at the new threshold over the last 24 hours.

How to know your tuning is working

Healthy tuning signals:

• Alert volume per detection pass stable or trending down over 2-week windows (visible on the Burrow home page trend chart).
• Disposition rate above 50% Real or Maybe. A low rate means too many false positives — keep tuning.
• Suggestions panel small and growing slowly. A panel that fills up with new suggestions every day means the SOC team is dismissing a lot — they probably want more tuning.
• No "we missed an alert" stories from the SOC. Tune for signal-to-noise, not absolute zero noise.

See also

• Postures, overrides, and disabled rules — the three tuning levers and when to use each.
• Entity exceptions — for one-user noise.
• Dispositions — the input that drives dismissal-driven suggestions.
• Dismissal auto-suppress — opt-in skip-the-click version.
• Rule replay — preview a change before committing.
• Rule catalog — per-rule reference with tuning advice.

Need help? support@smikar.com.