Tuning detections to remove 35% of false positives

Every SOC I have worked with has the same complaint: too many alerts, too few of them real. The usual responses are either to hire more analysts or to quietly disable the noisiest rules. The first is expensive. The second is how breaches get missed.

There is a third option, and it is less glamorous than either: tune the detections properly. Over a few months of focused work on our custom rules, we cut false-positive noise by about 35% without removing coverage. This post is the playbook I followed, with examples of the kinds of changes that made the difference.

First, define what a false positive is

This sounds pedantic, but most tuning arguments are really definition arguments. I find it useful to separate three things:

• True positive: the rule fired and the activity was malicious or a real policy violation.
• Benign true positive: the rule fired correctly on the behaviour it describes, but the behaviour was legitimate. An admin running a remote script is the classic example.
• False positive: the rule fired on something it was never meant to match, usually because the logic was too broad or the data was misparsed.

These need different fixes. A false positive means the rule logic is wrong. A benign true positive means the rule is right but lacks context. Lumping them together is how teams end up "tuning" by deleting useful rules.

Step one: measure before you touch anything

Pick a window, ideally 30 to 90 days, and pull every alert with its final disposition. For each rule, work out how often it fired, how many of those were closed as false or benign, and how long analysts spent on them. Sort by total analyst time, not by alert count. A rule that fires 50 times a day but is closed in seconds may cost less than one that fires five times and takes 20 minutes each.

In our case a small number of rules produced most of the noise. That is typical. You do not need to tune everything; you need to tune the top ten well.

Step two: read the alerts, not the dashboard

For each noisy rule, read 20 to 30 recent closed alerts end to end. Patterns show up fast: the same service account, the same deployment tool, the same scheduled job, the same office network. Write down every pattern and how many alerts it explains. This list becomes your tuning plan.

Step three: choose the right kind of fix

Most of our gains came from five kinds of change. Here they are with illustrative before and after examples. The specifics are simplified, but the shape of each change is real.

Notice that none of these remove the rule. Each one makes it more specific about what suspicious looks like.

Allowlists done safely

Allowlists are where tuning goes wrong most often. A broad exclusion, such as "ignore everything from this server" or "ignore this user", is a gift to an attacker who compromises that server or user. A few rules I follow:

• Exclude the combination, not the entity. Match the exact tool, path, parent process, host group and account together, not any one of them alone.
• Prefer hashes or signed publishers over file names. File names are trivial to fake.
• Give every exclusion an owner and an expiry. Re-review it when it expires. Infrastructure changes and old exclusions become blind spots.
• Log what you suppress. Suppressed events should still be searchable, so a hunt can find them later.

Step four: test before and after

Before deploying a tuned rule, run the old and new versions side by side against the same historical data. Three checks matter:

• Noise reduction: how many of the past false positives would the new version have dropped?
• Coverage: did any past true positive disappear? If so, stop and rethink.
• Attack simulation: run or replay the behaviour the rule is meant to catch, mapped to the relevant MITRE ATT&CK technique, and confirm it still fires.

The second check is the one people skip. A tuning change that drops a single real detection is not an improvement, however much noise it removes.

Step five: measure again, then keep measuring

After deployment, compare the same numbers from step one over a similar window. In our case the combined effect across the tuned rules was roughly 35% less false-positive noise, with no loss of the true positives we tested against. Just as important, analysts started trusting those rules again. An alert that is right most of the time gets read carefully. One that is wrong most of the time gets closed on reflex, and that reflex is what attackers rely on.

Tuning is not a one-off project. New software, new offices and new admin habits all create new noise. We review the top noisy rules on a regular cadence and treat a sudden jump in a rule's volume as a signal in itself.

A worked example

One rule flagged any process on a server that opened an outbound connection to an address outside our known ranges. In principle it was a good exfiltration and command-and-control signal. In practice it fired constantly, and analysts closed nearly all of it as benign.

Reading a month of closed alerts showed three patterns. Most came from software update agents contacting their vendors. A second group came from a backup job that had moved to a new cloud region. The rest came from one log source that recorded internal addresses in a different format, so they looked external.

The fixes matched the patterns. Update agents were excluded only when the signed binary, its usual install path and the vendor's published domains all lined up. The backup job's new destination was added to the known ranges with an owner and a review date. The address format was normalised at ingest, which also fixed two other rules that nobody had connected to the problem. The rule stayed in place, fired far less, and the alerts that remained were worth reading.

Common mistakes

• Tuning by volume alone. The loudest rule is not always the costliest.
• Silencing instead of fixing. Lowering a rule's severity so nobody looks at it is disabling it with extra steps.
• No record of why. Every change should say what pattern it addresses and which alerts prompted it. Six months later, nobody remembers.
• Ignoring data quality. A surprising share of false positives come from parsing problems, not bad logic.

Frequently asked questions

What is a good false positive rate for SIEM detections? There is no single number. It depends on the rule's purpose and severity. A better test is whether analysts trust the rule enough to read every alert carefully, and whether its noise costs more analyst time than the threats it catches.

Is it safe to allowlist noisy activity? Yes, if the allowlist is narrow. Exclude the exact combination of tool, path, host group and account, give each exclusion an owner and an expiry, and keep suppressed events searchable.

How often should detections be re-tuned? Review your noisiest rules on a regular cadence, such as monthly, and whenever a rule's volume jumps suddenly. New software, offices and admin habits keep creating new noise.

The point

Alert fatigue is a detection engineering problem before it is a staffing problem. Most of the gain comes from a short list of noisy rules, careful reading of real alerts, precise fixes and honest before and after testing. Do that well and you get something more valuable than a smaller queue: analysts who believe their alerts again.