One wastes an analyst's time on an alert that fired for nothing. The other lets a real attacker walk past a control that never made a sound — and the two are connected in a way most people miss.
Every detection control — a SIEM correlation rule, an EDR agent, an IDS signature, a SOC analyst reading a queue — makes a binary call on every event: alert, or don't. There are exactly four possible outcomes once you cross that call against what actually happened, and security teams live or die by which two of the four they're accumulating. Get the "harmless" one wrong at scale, and it quietly produces more of the dangerous one.
Make a detection rule more sensitive — broaden the signature, lower the threshold — and you catch more true positives, but you also catch more false positives, because sensitivity can't distinguish "more attacks" from "more things that merely resemble attacks." Make it stricter to cut the noise, and some genuine attacks that don't perfectly match the pattern slip through as false negatives instead. There is no tuning setting that eliminates both at once for a fixed detection approach — every SOC is explicitly or implicitly choosing a point on that trade-off curve, and the right point depends on what a missed detection actually costs versus what an analyst-hour actually costs.
That's true for any single false positive, and false at scale. The real cost of a chronically noisy detection rule isn't the sum of individual ten-minute investigations — it's alert fatigue: analysts, correctly calibrated by weeks of a rule being wrong 99% of the time, start triaging its alerts last, applying less scrutiny, or filtering them out of view entirely. The rule hasn't become less accurate on any given day, but the humans downstream of it have rationally learned to distrust it — which means the one day the rule is actually right, it gets the same reduced attention as every other day. A high false-positive rate doesn't just cost analyst time; over time it manufactures false negatives by degrading the response to the true positives buried in the same queue.
Explains the four possible outcomes of any security alert — true positive, false positive, false negative, true negative — why a false positive is never truly harmless at scale, and how alert fatigue quietly converts a high false-positive rate into missed real attacks (false negatives).
People treat "false positive" and "false negative" as a matched pair of equally-weighted errors, the way they might in an unrelated statistics class. In security alerting they are not symmetric: a false positive costs bounded analyst time on a single ticket, while a false negative costs unbounded dwell time for an attacker operating with zero defensive resistance. Treating them as equivalent in severity — and therefore tuning purely to minimize the more visible one (alert volume) — is a common and costly mistake.
Cross what a detection control actually decided (alert or no alert) against what actually happened (real attack or benign activity) and there are exactly four outcomes: true positive (correctly caught), false positive (cried wolf), false negative (silently missed), and true negative (correctly silent — the overwhelming majority of events in any real environment). Every tuning decision on a detection rule — a stricter match pattern, a lower alert threshold, a new correlation condition — moves probability mass between these four quadrants; it never eliminates error, it only redistributes it.
A high false-positive rate does not stay contained to "wasted analyst time" — it produces alert fatigue, where analysts rationally learn to deprioritize, batch-dismiss, or tune out a chronically noisy source. Once that happens, the source's true positives get the same reduced scrutiny as its false positives, meaning the false-positive rate has functionally created new false negatives without the detection rule's underlying accuracy changing at all. This is why SOC metrics increasingly track alert-to-investigation ratios and analyst fatigue signals alongside raw detection coverage — a rule that "never misses" but generates ten times the sustainable alert volume is not actually a win.
A single false negative is almost always worse in immediate terms — it means a real attack proceeded with no defensive response. But a chronically high false-positive rate is dangerous in a different way: it causes alert fatigue, which degrades how analysts respond to true positives buried in the same noisy queue, indirectly producing more false negatives over time.
Only by genuinely improving the detection logic itself — adding a more specific behavioral indicator, enriching context, using a better data source — not by simply moving a threshold. Sliding a single threshold up or down trades one error type for the other; it does not reduce both simultaneously, because the ambiguity between "close match" and "true match" hasn't actually gone away.
Alert fatigue is the well-documented tendency for analysts (or automated triage logic) to give progressively less attention to alerts from a source that has a track record of being wrong most of the time. It's a rational adaptation to a noisy signal, but it means the source's occasional true positives receive the same reduced scrutiny as its frequent false positives.
Common metrics include the false-positive rate (or precision) of individual detection rules, the ratio of alerts generated to alerts actually investigated, mean time to detect (MTTD) and mean time to respond (MTTR), and periodic detection rule tuning reviews that retire or adjust rules whose false-positive rate has made them a net negative to analyst attention.
The underlying four-quadrant logic (true/false positive/negative) is the same statistical concept used across ML, medical testing, and security alerting — but the cost structure is domain-specific. In security alerting specifically, the asymmetric cost of a missed real attack versus a noisy alert, and the alert-fatigue feedback loop between them, is what makes this worth understanding as its own operational concern rather than a purely abstract classification metric.
Try our Cybersecurity Studio
More calculators, simulators, and guides for this discipline.