A rule is generating hundreds of false positives a day. How do you tune it down safely?

Tuning is one of the highest-leverage things a SOC does, and also one of the easiest to get wrong. A sloppy exclusion can silence a real attack forever. Interviewers ask this to see whether you treat tuning as careful engineering rather than a mute button.

Start with root cause

Before changing anything, ask why the rule is so noisy. Pull a sample of the false positives and look for the common thread: a vulnerability scanner, a backup service account, a monitoring tool, or a misconfigured rule threshold. The fix depends entirely on the cause. Often the rule logic itself is too broad, and the right answer is better logic, not an exclusion.

Scope exclusions as narrowly as possible

When you do need an exclusion, make it surgical. Excluding "scanner-host running this specific tool against this specific subnet" is defensible. Excluding an entire IP range, an entire account type, or a whole event ID is how blind spots are born — an attacker who lands on that host or abuses that account now goes undetected.

Document and validate

Every tuning change needs a paper trail: what you changed, why, who approved it, and when to revisit it. Then validate: confirm that a genuine malicious instance of the behavior would still trigger the alert. Replay a known-bad sample or reason through the new logic explicitly.

Track the metrics

Watch precision (true positives over total alerts) before and after. If volume dropped but you also lost true positives, the change was too aggressive.

Why this matters

Anyone can make alerts go away. An analyst who can reduce noise while preserving coverage — and prove it — is protecting the SOC from both fatigue and blindness at the same time.