False positive

Formally, a false positive is the FP cell of the confusion matrix: a detector predicts the positive class (malicious, vulnerable, spam) for an instance that is actually negative. Three derived rates are routinely confused. The false-positive rate, FP / (FP + TN), is the share of benign events that trigger an alert. Precision, TP / (TP + FP), is the share of alerts that are real. The false discovery rate, 1 − precision, is what analysts actually experience as noise. A detector can have an excellent false-positive rate and still terrible precision, and in statistics a false positive corresponds to a Type I error.

The reason is the base rate. Suppose one event in 100,000 is malicious and a detector catches 99% of malicious events while wrongly flagging only 1% of benign ones. Out of a million events, about 10 are malicious and roughly 10 of those alerts are true, but about 10,000 benign events are flagged, so fewer than one alert in a thousand is real. Axelsson's 2000 paper on the base-rate fallacy in intrusion detection made this argument formally, and it explains why security teams judge detections by precision and alert volume per day, not by accuracy.

In SOC practice it is useful to separate a false positive (the rule matched something it was not meant to match, a logic or data error) from a benign true positive (the rule matched exactly the intended behaviour, but in this case it was authorised, such as an administrator using PsExec or a scheduled vulnerability scan). The remedies differ: the first calls for fixing the rule or its parsing, the second for narrowly scoped exceptions or context enrichment. Tuning always trades against false negatives, the missed attacks, and broad exclusions (a whole directory, a signed binary, a service account) create blind spots attackers can use, particularly with living-off-the-land techniques that deliberately look like administration.

False positives are not just an efficiency problem. Chronic noise produces alert fatigue and normalisation of deviance; post-incident analyses of the 2013 Target breach reported that malware alerts had been raised but not acted on. In prevention controls, a false positive causes direct harm: in April 2010 a McAfee antivirus definition update (DAT 5958) misidentified the Windows file svchost.exe as malware on Windows XP SP3 machines, sending many into reboot loops. The same concept appears across security tooling: static analysis findings that are not exploitable, spam filters quarantining legitimate mail, and data loss prevention rules blocking normal business transfers. Measuring the false-positive share per rule over time is the basic input for detection engineering.