SECURITYATLAS✳

✳ The reference desk / In practice

False positive

An alert that did not represent the harmful event the detector was meant to catch.

What it means

A false positive is a detection result that says the target condition is present when it is not. The target condition matters: a rule that correctly detects an unusual login may still produce an unhelpful alert if people interpret its label as confirmed account theft. Establish what the detector is intended to identify before labeling outcomes. Distinguish a harmless but accurately detected event from a parsing error or a truly mistaken classification. These differences lead to different improvements and better conversations with the people maintaining detections.

See the idea / Detection

A matched rule still needs the right label.

Keep the job fixed and change the detector’s intended target. The reviewed label changes with it.

Illustrative test: a job exports 200 records. A broad rule alerts above 100. Compare a detector intended to find unauthorized exports with one intended to find large exports.

False positive: Keep the job fixed and change the detector’s intended target. The reviewed label changes with it. The chapter text below describes every state.Review deskExecutionTEST-7 · 02:06Ops · Test DB200 recordsRuleINTENDED TARGETUnauthorized> 100 recordsUncheckedExport alertWaitingTEST-7 · 200 recordsApproval MAINT-88TEST-7 · Ops · Test DBWindow 02:00–02:15Target?UnreviewedONE JOB · ONE ALERT AT MOST

01 / 04

Record

Job TEST-7 exports 200 records from the test database at 02:06. This detector’s intended target is an unauthorized export.

More about this step

The execution record identifies job TEST-7, owner Ops, the test database, the time, and the 200-record count. These are observations. The approval record already exists; it has not yet been compared. Times use the same clock and date.

Keep in mindThis example assumes complete audit evidence and a matching approval. Unreviewed alerts remain unknown. A harmless event can still be a correct detection for the stated target.

Read the visual, step by step

Unauthorized export

  1. Record. Job TEST-7 exports 200 records from the test database at 02:06. This detector’s intended target is an unauthorized export. The execution record identifies job TEST-7, owner Ops, the test database, the time, and the 200-record count. These are observations. The approval record already exists; it has not yet been compared. Times use the same clock and date.
  2. Match. The broad size rule compares 200 records with its threshold of 100. The condition matches. That match alone cannot establish whether the export was authorized. The mechanical rule and threshold stay identical on both paths. Only the intended positive class changes: unauthorized export. Matching a threshold does not supply an authorization decision.
  3. Deliver. The detector sends one alert with the job identifier and count to the review desk. The record remains available. The alert arrives before it can be investigated. The rule match remains true. Receipt is separate from disposition: this alert has not yet been labeled true or false. Lines show record/alert handoffs and the final evidence comparison, rather than a network protocol.
  4. Review. The audit record matches MAINT-88: job, owner, test database, and approved time window. The export is authorized. The unauthorized-export target is absent, so this alert is a false positive for that target. The size condition still matched. Assume the complete execution audit confirms TEST-7 ran under Ops, exported only the test database, and occurred at 02:06 inside MAINT-88’s 02:00–02:15 window on the same date. In this controlled example, the reviewed record establishes authorization. A ticket alone would not establish that an execution followed its approval; real investigations can remain unresolved.

Large export

  1. Record. Job TEST-7 exports 200 records from the test database at 02:06. This detector’s intended target is a large export. The execution record identifies job TEST-7, owner Ops, the test database, the time, and the 200-record count. These are observations. The approval record already exists; it has not yet been compared. Times use the same clock and date.
  2. Match. The broad size rule compares 200 records with its threshold of 100. The condition matches. That match alone cannot establish whether the export was authorized. The mechanical rule and threshold stay identical on both paths. Only the intended positive class changes: large export. Matching a threshold does not supply an authorization decision.
  3. Deliver. The detector sends one alert with the job identifier and count to the review desk. The record remains available. The alert arrives before it can be investigated. The rule match remains true. Receipt is separate from disposition: this alert has not yet been labeled true or false. Lines show record/alert handoffs and the final evidence comparison, rather than a network protocol.
  4. Review. The audit record matches MAINT-88: job, owner, test database, and approved time window. This 200-record export is authorized, but it is large. The large-export target is present: a true positive, even though the action is legitimate. Assume the complete execution audit confirms TEST-7 ran under Ops, exported only the test database, and occurred at 02:06 inside MAINT-88’s 02:00–02:15 window on the same date. In this controlled example, the reviewed record establishes authorization. A ticket alone would not establish that an execution followed its approval; real investigations can remain unresolved.

This example assumes complete audit evidence and a matching approval. Unreviewed alerts remain unknown. A harmless event can still be a correct detection for the stated target.

Flow references: Google: Classification Accuracy, Recall, and Precision · NCSC: Detection practices

AN ILLUSTRATIVE SCENARIO

A planned software rollout triggers malware alerts

A manufacturer rolls out an approved administration script. A rule intended to detect malicious script execution generates alerts because the command pattern resembles an attack. An analyst checks the deployment record, source, signer, target devices, and timing. The investigation supports a benign disposition for this rollout. The team considers a narrow, reviewed exception instead of disabling every alert involving the scripting tool, which attackers can also use.

Put it to work

  1. Define the positive condition and label reviewed cases consistently. Keep the evidence and reasoning behind a benign disposition so another analyst can challenge it.
  2. Look for the cause of noise: missing context, an overly broad condition, incorrect parsing, or a legitimate workflow. Give the detection owner concrete examples.
  3. Test any tuning against both benign activity and representative malicious cases. Time-limit exceptions where possible, and document which previously detectable behavior an exception might hide.

How to check your work

After a change, rerun the legitimate scenario and a contrasting suspicious one. Check that noise falls for the intended reason and that the meaningful detection still works. Track unresolved cases separately from labeled outcomes.

Connect the ideas

  • Alert

    A notification that a rule or model wants a human to look at one or more records.

  • Precision

    True positives divided by all positive alerts in a defined, labeled evaluation set: TP / (TP + FP).

  • Recall

    Detected true events divided by all true events in a defined evaluation set: TP / (TP + FN). Unknown missed events limit production estimates.

  • Triage

    A short, time-boxed judgment of severity, uncertainty, and next action when an alert arrives.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.