What is False Positive?

NIST's glossary carries three versions of the definition.

• SP 800-83, the malware handling guide, calls it a security tool classifying benign content as malicious.
• SP 800-86, on forensics, says incorrectly classifying benign activity as malicious.
• SP 800-115, on security testing, applies the term to a scan result that reports a vulnerability that is not there.

The SOC meaning sits closest to the second: a detection rule matched, and the activity behind the match was harmless. The mirror image is the false negative, which SP 800-83 defines as a tool failing to detect the threat it was meant to detect. A false positive costs analyst time; a false negative costs you the incident.

Every alert decision lands in one cell of a two-by-two grid.

• Malicious activity and the rule fired: true positive.
• Benign activity and the rule fired: false positive.
• Malicious activity and the rule stayed quiet: false negative.
• Benign and quiet: true negative, which nobody counts because it covers almost every event you collect.

SOC teams add a label the grid hides. A benign true positive is real activity that the rule describes correctly but that turns out to be authorized, like a penetration tester guessing passwords inside the agreed window. Microsoft Defender XDR gives it its own classification, Informational, expected activity, meant for security tests, red team activity and expected unusual behavior from trusted apps and users. It keeps False positive for incidents that are technically inaccurate or misleading. The fix differs as well. A false positive says the rule logic or its data is wrong; a benign true positive says the rule works and needs an exception for an approved source.

Here is one week of one rule, with numbers made up for this page (simulated example generated by SOCSimulator Research). The rule raises an alert when a single account produces five or more Windows 4625 failed logons inside an hour, and it fired 214 times.

• Triage closed 151 of them for the same reason: after a password rotation, a scheduled task on APP-07 kept running as svc-report with the old password, failing every ten minutes with Logon Type 4 (batch) and Sub Status 0xC000006A (bad password).
• Another 13 came from users mistyping a password they had just changed.
• The authorized external penetration test produced 41 benign true positives, brute-forcing test accounts from the address listed in its rules of engagement.
• Nine alerts were true positives: password guessing against an exposed RDP host.

Weeks later a threat hunt found two password-spraying runs from a compromised workstation that tried two passwords against each of 300 accounts. No account ever reached five failures, so the rule never fired. Those were the false negatives.

Put into the grid, the week reads 9 true positives, 164 false positives, 41 benign true positives and two missed spraying runs. Only 9 of 214 alerts, 4.2%, needed a response. Counting the pentest as the rule doing its job, 50 of 214 (23%) were correct detections. One scoped exclusion for svc-report batch logons from APP-07 removes 151 alerts and lifts the response-worthy share of the queue from 4.2% to 14.3% (9 of 63) without losing a single true positive. Switching the rule off would also have emptied the queue, along with all nine real attacks.

The two spraying runs appear in none of these ratios, because a missed attack produces no alert to count. Precision shows up in your queue every day. Misses only show up through hunting, purple team work or the incident that follows.

MITRE ATT&CK describes password spraying (T1110.003) as one password or a short list tried against many accounts specifically to avoid lockouts, and notes that operators throttle attempts to stay under detection thresholds. A rule that counts failures per account cannot see that pattern however it is tuned; catching it takes a second rule that counts distinct accounts per source. NIST SP 800-94 states the general trade-off: it is not possible to eliminate all false positives and negatives, reducing one usually increases the other, and many organizations accept more false positives so that they miss less.

When a false-positive pattern keeps coming back, there are three ways to stop it, and they carry different risks.

The first is suppression: an automation or tuning rule hides or closes matching alerts. Defender XDR calls this alert tuning (it was previously named alert suppression). Hide alert keeps the alert out of the queue and prevents an incident, Resolve alert closes it automatically, and Microsoft's documentation says to use it with caution, for known internal business applications or security tests. Suppression is fast and leaves the detection logic untouched, so a broad condition will also hide the next real attack that matches it.

The second is fixing the rule, for false positives that come from the logic itself. The brute-force rule above counts every 4625. Microsoft's monitoring guidance for that event lists 0xC000005E, no logon servers available, as typically an availability problem rather than a security one, so a domain controller outage would flood the rule with failures nobody guessed. Filtering on Sub Status to keep only the bad-password and unknown-user codes (0xC000006A and 0xC0000064) fixes that for every source at once. In Sigma, the vendor-neutral rule format, the optional falsepositives field lists known benign triggers so the next person to read the rule knows what to expect.

The third is an exclusion with a narrow scope, for one known source. Name every attribute you can: the account, the host and the logon type together, never the account alone, or a stolen svc-report password used from anywhere else goes quiet as well. Give the exclusion an owner and a review date, and open a ticket for the root cause; this one should disappear once someone updates the password stored in the task. SP 800-94 recommends reviewing tuning periodically to make sure it is still accurate. An exception list nobody reviews turns into a list of places where an attacker can work without raising an alert. The 13 mistyped passwords get no exclusion at all. They are the price of keeping the rule sensitive.

The SOCSimulator alert triage guide on the blog sets the three verdicts side by side and follows one suspicious login alert from the queue to a written verdict. That written verdict is what makes tuning possible, because a false positive closed without a reason teaches the rule owner nothing.