Your verdict audit finds a third of false-positive closures were authorised activity the rule caught correctly - what has that mislabel already broken?

## What was actually recorded An alert on an administrator's credential-audit tooling, or on an in-scope red-team action, is not a false positive. The detection did exactly what it was written to do: the behaviour occurred, the telemetry captured it, the rule matched. What made it not an incident was **authorisation**, which lives outside the detection entirely. Recording that outcome as "false positive" makes a claim about the rule that is simply untrue, and a verdict audit that finds a third of a rule's closures carry that label has found a content defect, not thirty individual mistakes. ## The four downstream consumers of a disposition **1. Tuning.** This is the expensive one. The standard, reasonable response to a false positive is to suppress or narrow the rule - exclude that binary, that account, that host, that path. Applied to a benign true positive, the exclusion removes a genuine detection. If the exclusion is written broadly ("suppress this tool on the admin jump host"), an intruder who reaches that host and runs the same tooling now generates nothing at all, and the exclusion is invisible in the alert stream by definition. Mislabels do not merely distort a number; they buy the adversary a blind spot and pay for it with a ticket nobody re-reads. **2. Rule yield and precision figures.** Every per-rule quality number a SOC reports is derived from analyst dispositions. If a third of one rule's closures are labelled false positive when the rule was right, the rule's apparent precision collapses and it moves to the top of the retirement or rewrite list. The measurement agrees with the error instead of exposing it, which is precisely why the labels themselves have to be audited against raw evidence rather than trusted as ground truth. **3. Coverage claims.** If a suppression grew out of the mislabel, a technique cell that leadership reads as covered may be covered only for cases nobody excluded. The coverage statement and the exclusion list have drifted apart, and nothing reconciles them automatically. **4. Purple-team and exercise attribution.** This is the sharpest case. An in-scope red-team action was executed, the telemetry arrived, the rule fired, an alert reached the queue - and the analyst closed it as a false positive. Reported naively, the exercise records a *detection miss*. It was not. The chain has four stages - telemetry collected, rule fired, analyst acted, response landed - and the failure here is at stage three. Sending that to a detection engineer produces a new rule duplicating one you already have, while the actual fixes are analyst context, a playbook that does not license a close on this signal, and a deconfliction record so the exercise is recognisable. ## What you do about it - **Re-label the sampled cases** with the correct disposition and record why, so the audit trail shows the correction rather than quietly overwriting history. - **Find the population, not just the sample.** Pivot from the sampled cases to their rule, entity and note pattern, and pull every closure that looks like them. A third of a sample being wrong means the same standing assumption is running across the queue. - **Review every suppression that traces back to one of those tickets.** This is the step that actually restores detection. Narrow each exclusion to the specific authorised context - this service account, from this source, on this schedule - rather than the tool or the host. - **Recompute the rule's yield with corrected labels** before making any decision about retiring or rewriting it. - **Return the red-team case to the exercise record with the right stage attribution**, so the remediation goes to the response side. ## Preventing the next one The underlying reason a good analyst mislabels here is that they had no way to establish authorisation quickly. The durable fixes are reference data and process: an inventory of authorised administrative tooling with the accounts and hosts entitled to run it; a change or maintenance record the analyst can query; a deconfliction channel for exercises; and a disposition option in the case system that actually expresses "the rule was right, the activity was authorised", because if the tool offers only true and false positive, analysts will keep choosing the wrong one. One caution in the other direction: an authorised-looking action is not self-certifying. The same command run by an intruder who has taken the administrator's session looks identical in the telemetry. The case is closed correctly only when the *authorisation* was corroborated from a source the adversary does not control - a change record, an approval, the administrator confirming out of band - not merely because the account is one that usually does this.