At a glance
- Problem
- A detection queue dominated by benign alerts, eroding trust and attention
- Root cause
- Rare true threats plus imperfect detectors: the base-rate problem
- The trade
- Precision versus recall; over-tuning trades false positives for false negatives
- Two categories
- False positive (benign flagged) and true-but-irrelevant (real, not yours)
- Levers
- Context and enrichment, precise detections, disciplined allowlisting, feedback loops
- Standard
- Detection engineering practice; precision, recall, and the base-rate fallacy
The tax nobody budgets for
Every false positive costs a little: a few minutes to open, check, and close. The damage is not in any one of them; it is cumulative. A queue that is ninety-something percent benign teaches analysts, correctly on the evidence in front of them, that the next alert is probably benign too. They get faster and less careful, and eventually the reflex to close beats the instinct to investigate. The false positive that matters is not the one you triaged; it is the true positive you closed on autopilot because a thousand false ones came before it. This is the mechanism behind alert fatigue, the subject of How to prioritize security alerts.
Why good detectors still drown you
The uncomfortable maths is the base-rate fallacy. When the thing you are detecting is genuinely rare, even a very accurate detector produces mostly false alarms, because it is applied to an enormous number of benign events. Consider a detector that is 99% accurate, run across a population where only one event in ten thousand is a true threat: the false alarms from the 9,999 benign events swamp the single true one. The alert queue is dominated by noise not because the tool is bad but because true threats are rare, and rarity is unforgiving of even small error rates.
The lesson is not “accuracy does not matter.” It is that when the base rate of real threats is tiny, you cannot alert your way to signal by raw detection accuracy alone. You need context that lifts the true events out of the benign crowd, which is a different tool than a more sensitive rule.
Precision, recall, and going blind
Every detection sits on a trade-off between precision (of the things it flags, how many are real) and recall (of the real things, how many it flags). Tightening a rule to cut false positives raises precision but lowers recall: you also stop catching some genuine events. Push that too far, in the name of a quiet queue, and you have simply traded a visible problem (false positives) for an invisible one (false negatives), which is far more dangerous because nobody sees the incident you no longer detect.
“We reduced our alert volume by 80%” is not automatically good news. If that came from blunt suppression rather than better context, some of the 80% was signal, and you have made the programme quieter and blinder at the same time.
Two things people call a false positive
Two very different problems hide under one label, and they have different fixes:
- True false positive. The detector fired on something benign, a normal admin action that looks like an attack, a scanner you run yourself. The fix is precision: better logic, better context.
- True but irrelevant. The detection is correct, but it does not matter to you, a real threat against software you do not run, an indicator with no path into your estate. The fix is relevance filtering, not accuracy. This is the same category validation flags in How to validate threat intelligence.
Confusing the two leads to bad tuning. You cannot fix a relevance problem by making a rule more precise, and you cannot fix a precision problem by scoping to your environment. Name which one you have before you touch anything.
The levers that actually work
| Lever | What it does | Watch out for |
|---|---|---|
| Context enrichment | Adds asset, identity, and verdict so real events stand out | Stale context misleads; keep it fresh |
| More precise logic | Narrows the rule to the genuinely suspicious shape | Every narrowing costs some recall |
| Correlation | Alerts on sequences, not single events | Needs reliable, joined telemetry |
| Relevance scoping | Suppresses threats that cannot reach you | Environments change; revisit scope |
| Allowlisting | Removes known-good, high-volume noise | The classic place attackers hide |
Notice that most of these add information rather than remove alerts. That is the durable way to cut false positives: give each alert enough context to disposition itself, so the ones that survive are the ones worth a human.
Allowlisting without holes
Allowlisting known-good activity is the fastest way to cut volume and the easiest to get dangerously wrong. A broad allowlist entry (“ignore everything from this subnet,” “suppress all activity from this admin account”) is precisely the blind spot an attacker wants to live in, and compromised admin credentials or a foothold in a trusted range turn your noise-reduction into their cover. Allowlist narrowly and specifically, document why each entry exists, and review them on a schedule, because an allowlist is a set of detections you have deliberately turned off, and it should be treated with the seriousness that implies.
The feedback loop
False-positive reduction is not a project you finish; it is a loop you run. Every dispositioned alert is data: a benign verdict with a reason tells you what to tune, a true positive tells you the detection earned its place. A healthy programme captures those dispositions and feeds them back, retiring rules that only ever fire falsely, tightening the ones that are close, and, crucially, protecting the rare high-value detections from being tuned away just because they are quiet. The metric to watch is not alert volume but the fraction of alerts that turn out actionable, trending in the right direction over time.
Context that suppresses noise
Because the real cure is context, not suppression, the highest-leverage tool is one that answers “is this actually bad, and does it reach us?” quickly and honestly. Forensia is built to do that: it leads with a verdict, keeps the evidence and provenance attached, and, importantly for false positives, is explicit about what it could not verify and never presents an absence of signal as “safe.” That honesty is exactly what stops a benign-looking alert from being dismissed too fast, and a noisy indicator from being trusted too readily.
Key takeaway
False positives break detection programmes by fatigue, not by cost: a queue of noise trains people to stop reading. But the fix is not a quieter queue, because when threats are rare, blunt suppression trades visible false positives for invisible false negatives.
Cut noise by adding context, not by going blind. Separate true false positives from true-but-irrelevant, allowlist narrowly and review it, and run a feedback loop measured by the fraction of alerts that prove actionable. The goal is a queue where reading the next alert is worth it, because most of the time, it is.
References & further reading
- The base-rate fallacy, and its classic application to intrusion detection by Stefan Axelsson.
- Palantir, Alerting and Detection Strategy framework, on building precise, maintainable detections.
- MITRE, ATT&CK, for grounding detections in real adversary behaviour rather than brittle signatures.
- NIST, SP 800-61, on handling and dispositioning alerts within an incident process.
- OverWatch Labs, How to prioritize security alerts and How to validate threat intelligence.