When closing a security alert, what separates a false positive from a benign true positive?
answer
- not an incident is several statements
- was the rule wrong, or the activity fine
- one indicts the rule, one clears it
- authorised is not the same as absent
- the code is the rule's only feedback
basics
~20 sA false positive means the detection was wrong: the behaviour it claimed to see did not occur. A benign true positive means the detection was right and the behaviour was authorised. One indicts the rule; the other clears it.
solid answer
~50 sBoth close without an incident, but they say opposite things about the detection. A **false positive** asserts the rule misread the data: the process, the login, the transfer it described did not actually happen that way, so the logic or the field it keyed on is faulty. A **benign true positive** asserts the rule was correct about the observed behaviour, and the behaviour was permitted: a records team really did move 40 GB of case files to a partner tenant, under a signed contract, through the sanctioned sync client. Nothing about the rule is broken. The distinction matters because the disposition is the only feedback the detection ever gets. Recording authorised activity as a false positive puts a working rule on the broken list, where the next portfolio review may weaken or retire it. Recording a genuine logic error as benign leaves a broken rule running untouched.
go deeper
Be ready to state the three codes and what each asserts, in one sentence each, without hedging. The distinction interviewers listen for is whether the rule was wrong versus whether the activity was allowed.
Explain what each disposition obliges next and why the codes are the detection's only feedback channel. Be able to say what goes wrong downstream when authorised activity is filed as a false positive.
Show that you treat benign as a verified claim: name the authorisation, the evidence and who confirmed it. Interviewers probe whether queue pressure would push you to close benign on an unverified assertion.
Own the argument that disposition quality is a data-integrity problem for the whole detection programme, and that codes chosen for speed or comfort make every downstream number about detections untrustworthy.
## Three verdicts, not two Triage ends in a **disposition**: a short code written on the closed alert saying what the analyst concluded. Everyone knows two of them. Mature SOCs carry at least three, because *not an incident* is not one statement but several. - **True positive** - the behaviour the rule described occurred, and it was unwanted. This is the verdict that escalates. - **False positive** - the behaviour the rule described did not occur. The rule misread the data: it keyed on a field that means something else, matched a substring it should not have, or fired on a value the source populates differently than the author assumed. - **Benign true positive (BTP)** - the behaviour occurred exactly as described, and it was authorised. The rule did its job perfectly and there is still nothing to respond to. ## Why the third code is not pedantry A detection has almost no feedback channel. It emits alerts; analysts close them; the closure codes are the whole record of whether it works. So the disposition is not an administrative tick, it is a claim about the rule. Say a data-movement rule on a SaaS audit trail fires because a records team copied 812 case files to an approved partner tenant, on a contract that legal signed. If the analyst closes it *false positive*, the rule's record now says it was wrong. Aggregate a quarter of those and the rule looks like a noise generator, and someone with a queue to protect will suppress, narrow or delete it - and the estate silently loses a working exfiltration detection. If instead it closes *benign true positive*, the record says the rule fired correctly on activity that happened to be permitted. That is not a defect, and it defends the rule at review time. The reverse error is just as bad. Closing a genuine logic fault as "benign" leaves a rule that cannot detect what it claims to detect running for a year while everyone assumes coverage exists. ## What each verdict obliges next - **True positive** - escalate. Someone owns the response from here. - **False positive** - the rule needs work, and the useful artefact is *which field made it wrong* on *which asset*, not just a count. - **Benign true positive** - nothing is wrong with the rule, so nothing about the rule should change on the strength of one case. What the case does produce is a record that this activity is expected: who authorised it, what its shape is, and when that authorisation lapses, so the next analyst reaches the same verdict in two minutes instead of forty. ## The verification trap A BTP is a *verified* claim, not a comfortable assumption. "The user says it was approved" is a lead; "the transfer matches contract reference C-2291 and the records-team manager confirmed the destination tenant" is a verdict. Analysts under queue pressure reach for benign because it closes fast and blames nobody, and an intruder operating through a sanctioned tool and a legitimate account is precisely the case that looks benign. If you cannot name the authorisation and who confirmed it, you have an unfinished investigation, not a BTP. ## Cases that are genuinely benign - A sanctioned bulk transfer to a partner under contract. - An authorised red-team or penetration-test action that reached the queue because nobody told the SOC. - A backup or migration job whose service account behaves like mass collection. - An administrator legitimately doing something that has no benign-looking signature. All of these fire correct rules on real behaviour. None of them are defects. ## What people get wrong The common failure is treating "benign true positive" as a politer synonym for false positive, so the codes get used interchangeably and the whole feedback channel turns to noise. The second failure is the opposite: insisting a rule that produces many BTPs is therefore bad. A rule can be perfectly precise about *behaviour* and still fire constantly, because the environment does the behaviour legitimately - and that is an argument about scoping and expected-activity records, not about correctness. Keeping the two claims apart - *was the rule right?* and *was the activity allowed?* - is exactly what the third disposition code exists to preserve.
- Can an alert be a true positive and still not become a declared incident?Yes. A true positive says the unwanted behaviour occurred; declaring an incident is a separate decision about scope, impact and whether a coordinated response is warranted. A single blocked malicious attachment can be a true positive that closes as a handled event. What it must not become is a benign true positive - benign means authorised, not small.
- The user tells you the transfer was approved. Is that enough to close it benign?No. A benign true positive rests on verified authorisation: a contract, ticket or change record, and confirmation from someone who can grant it. The subject's own account is a lead to check, not evidence. An intruder using a legitimate account through a sanctioned tool gives exactly the same answer, which is why unverified benign closures are the disposition adversaries benefit from most.
- What does a high volume of benign true positives say about a detection?That the rule is accurate about behaviour but poorly scoped to this environment - the estate does the behaviour legitimately and often. That is a scoping conversation, not evidence the logic is broken. Answering it with a false-positive label would misstate the problem and put a correct rule at risk of retirement.
A smoke alarm that shrieks at nothing is faulty. A smoke alarm that shrieks because you seared a steak is working exactly as designed - and you do not fix it by taking the battery out.
saying these in an interview costs you the question
- Treats benign true positive as a polite word for false positive
- Says any alert with no incident is a false positive
- Closes benign on the subject's word without verifying authorisation
- Assumes many benign true positives prove the rule logic is broken
- Thinks the disposition code is paperwork with no downstream effect