The false positive is the product, not the bug

Modern EDR watches endpoint activity and asks a model or a signature how suspicious it looks. The answer is a probability. When it crosses a threshold, you get an alert. Because the answer is a guess, a large share of those alerts are wrong — and that is a property of the approach, not a defect in a particular vendor.

The numbers are consistent across a decade of research. A 2021 IDC survey of more than 300 security operations centers found that 45% of all alerts are false positives — rising to 53% at managed security providers.[2] Oxford researchers who interviewed SOC analysts for USENIX Security 2022 named their peer-reviewed paper after a practitioner’s own estimate: “99% False Positives.”[1]

That paper contains the single most important nuance in this whole debate. The researchers found that many of those “false positives” were not noise at all — they were benign triggers: real events, fully explained by legitimate behavior in the organization’s own environment. The tool flagged something that genuinely happened. It simply could not tell that it was allowed.

That is the whole problem in one sentence. Detection can see the event. It cannot know your intent.

What false positives actually cost

The cost is not the wasted click on any single alert. It is what happens to the queue.

1 in 3 SOC analysts admit to ignoring alerts when the queue is full[2] — which means the real one hides in the pile no one is reading.

When a third of alerts get ignored under load, the failure mode isn’t a missed click — it is a missed intrusion. And intrusions are patient. IBM’s 2024 Cost of a Data Breach report puts the global average breach at 194 days to identify and 64 more to contain, at an average cost of $4.88 million.[3] Every hour a genuine alert waits behind a thousand false ones is dwell time — and dwell time is what that number is made of.

Why tuning can’t fix it

The instinct is to tune the rules down. It doesn’t work, because detection sits on a base-rate tradeoff it cannot escape:

  • Turn sensitivity down, and you miss real attacks — false negatives, the expensive kind.
  • Turn it up, and the false positives flood back.

You are moving a slider between two failures, never removing either. Behavioral and machine-learning models make it worse, not better, because they infer intent from behavior — and the exact behaviors that signal an attack (a shell spawning, a process reading a credential file, an outbound connection from a database) also occur constantly for entirely legitimate reasons. No amount of retraining teaches a probability what your environment considers normal, because “normal” is a policy decision, not a statistical one.

The alternative: verify against a rule, don’t score a guess

Runtime verification inverts the question. Instead of “does this look malicious?” it asks “did the system do something a rule forbids?”

A rule is a precise, declarative statement about what must never happen — for example, a web server must never spawn an interactive shell. The engine models every process, file, and connection as a live graph and checks each event against the rule as it lands. Either the forbidden edge appears in the graph or it does not. There is no score, no threshold, and no “medium confidence.”

This is why the false-positive rate is zero by construction, not by tuning: a rule cannot partially match. And because the finding is a concrete edge in a causal graph, the alert is the evidence — nginx(4521) → spawned → /bin/sh(4522) — not “suspicious activity detected.” The benign trigger that fooled the detector never fires here, because the rule already encodes which spawns are allowed. (This is the model invariantd is built on — see how it works and the rule language.)

The honest tradeoff

Verification is not magic, and pretending otherwise would be its own kind of false positive. It catches exactly what you specify — no more. It makes no probabilistic claim about the attack you never wrote a rule for. The rulebook, not a model, is where your judgment lives.

That is a deliberate trade. You give up the comforting illusion that a model will catch the unknown, and in return you get certainty on the known: the web shells, reverse shells, credential dumps, container escapes, and ransomware behaviors catalogued across the tactics of MITRE ATT&CK.[4] For the overwhelming majority of real intrusions, the technique is not novel — it is a known move executed on your infrastructure, and a rule catches a known move every single time.

Getting to zero

You don’t reach a zero false-positive rate by tuning your way there. You reach it one unambiguous rule at a time:

  • Start where the answer is not debatable — a production web server spawning /bin/sh, a database process opening an outbound connection to the internet, a container entering the host namespace. These are never legitimate, so a rule for them never cries wolf.
  • Layer coverage across the ATT&CK tactics. Every rule you add is an entire class of attack that can no longer produce a false positive or a false negative.
  • Attach a response to the ones that are unambiguous, so the verdict does something in the same microseconds it’s reached, instead of joining a queue.

The goal was never “fewer false positives.” It was to stop guessing.

References

  1. Alahmadi, B. A., Axon, L., & Martinovic, I. “99% False Positives: A Qualitative Study of SOC Analysts’ Perspectives on Security Alarms.” 31st USENIX Security Symposium (USENIX Security 2022), pp. 2783–2800. University of Oxford.
  2. IDC & FireEye, The Voice of the Analysts survey (300+ SOCs, 50 MSSPs), reported by Cybersecurity Dive, February 2021.
  3. IBM Security, Cost of a Data Breach Report 2024 (global average $4.88M; 194 days to identify, 64 to contain).
  4. MITRE, ATT&CK — the adversary tactics and techniques knowledge base.