What is False Positive?

False positives are one of the central operational challenges in any SOC. Detection rules and ML models are probabilistic: they fire on patterns statistically associated with malicious behavior, but those same patterns sometimes appear in legitimate activity. An IDS rule detecting port scanning fires on a legitimate vulnerability scanner. A UEBA alert for off-hours access fires on an employee working late before a deadline. A malware hash detection fires on a security research tool that happens to share code with a known sample. A geolocation-impossible-travel rule fires on an employee using a VPN exit node in another country.

The false positive rate directly limits SOC capacity. If the large majority of alerts in a queue are false positives, analysts spend most of their shift on non-threats, and the real attacks mixed in get delayed or, worse, closed without proper review. Alert fatigue, the psychological state where analysts become desensitized and start closing alerts on autopilot without gathering evidence, is the most serious downstream consequence of a chronically high false positive rate, and it is how genuine intrusions slip past a fully staffed SOC.

Reducing false positives is an ongoing tuning cycle, not a one-time fix. The correct approach is scoped suppression: rather than disabling a rule entirely, which reintroduces the false-negative risk the rule existed to close, analysts and detection engineers add exception conditions tied to the specific known-good trigger, such as excluding a named vulnerability scanner's IP range from a port-scan rule, or excluding a specific service account from a rare-login-time rule. Blanket suppression of an entire alert type is a common anti-pattern that quietly creates a detection gap. Good SOC operations teams track false positive rate as a KPI per rule and per analyst, and detection engineers are accountable for keeping rule precision high without simply narrowing rules until they stop firing on anything.