What must a false-positive closure record carry for the detection engineer who owns the rule?
answer
- the label is not the evidence
- which field decided the verdict
- asset plus the group it belongs to
- free text nobody ever queries
- rule version, not just rule name
basics
~20 sThe rule and the version that fired, the exact field and value that made the activity benign, the asset and its asset group, and the analyst's reason. A verdict label on its own is not evidence anyone can act on.
solid answer
~50 sThe closure is the only channel that carries anything back to the person who wrote the rule, so it has to be machine-aggregatable rather than prose. Record the rule id and the version live when it fired, the UTC time, the asset and the group it belongs to, and the part analysts usually skip: the specific field and value that decided the verdict — the process responsible for the CPU was the render daemon, the destination was an internal mirror, the principal was a known service account. Add a one-line free-text reason, but never let free text be the only carrier, because nobody ever queries it. When those fields are structured, six hundred closures collapse into one sentence about a field the rule never checks. When they are not, the engineer sees six hundred alerts stamped `false positive` and learns nothing.
code
json · 14 lines{
"alert_id": "ALR-2026-0418-3391",
"rule_id": "det-resource-hijack-cpu-outbound",
"rule_version": "4.2",
"fired_at_utc": "2026-04-18T01:14:07Z",
"verdict": "false_positive",
"asset": "render-node-31",
"asset_group": "gpu-render-farm",
"deciding_field": "process.executable",
"deciding_value": "/opt/renderd/bin/renderd",
"reason": "scheduled nightly render; sustained CPU is the workload",
"closed_by": "analyst-t1-14",
"time_to_close_seconds": 88
}go deeper
Be ready to list what you type when you close an alert and why each part exists. Naming the specific field and value that decided the verdict, plus the asset group, is what separates a usable closure from a stamp.
Explain why structured fields beat free text: six hundred prose comments cannot be counted or grouped, so nobody reads them. Be able to say what the rule version adds to a series of closures.
Show that you design the closure form, not just fill it in. An interviewer expects you to say which fields you would make mandatory, which you would pre-populate from the alert, and how you keep the extra typing under the time an analyst actually has.
Own the argument that the disposition schema is a detection-program asset rather than case-system hygiene. Be ready to defend spending analyst seconds per alert on structure against the coverage it eventually buys.
## The closure is a message, not just a state change When an analyst finishes an alert, the case moves to a closed state with a verdict on it. It is easy to treat that as bookkeeping — the queue got shorter. It is better to treat it as the **only telemetry the detection team ever receives from the queue**. The person who wrote the rule usually cannot see your case system, does not sit in your org unit, and has no way of knowing why their rule was wrong except through what you wrote down when you closed it. That framing decides the content. You are not writing a note to yourself; you are writing the input to somebody else's decision about a rule. ## The worked case A heuristic for resource hijacking (`T1496`) fires when a host sustains very high CPU for more than an hour while holding an established outbound TCP session to an external address. That is a reasonable proxy for a miner an intruder dropped on the fleet: mining burns CPU and has to talk to a pool. It is also, word for word, a description of what a GPU render farm was bought to do — multi-hour renders while the node holds a session to an external asset store. The rule never evaluates *which process* is burning the CPU. So it fires on the farm every night, and analysts close it. ## The four things the record must carry 1. **Rule identity and version.** A rule is edited over time. Evidence gathered across an edit describes two different detections, and the engineer cannot tell which one the closures are about. 2. **Asset and asset group.** The single hostname is nearly useless on its own. What the engineer needs to know is whether the misfires are confined to one class of machine or spread across the estate — those are different problems with different fixes. 3. **The deciding field and its value.** This is the discriminator: the one observable that separated benign from malicious in the analyst's head. `process.executable = /opt/renderd/bin/renderd`. If that field is not recorded, the engineer knows only that the rule was wrong, never *where* it was wrong. 4. **Reason, closer and time-to-close, in UTC.** The free-text reason gives a human the story. The closer and the elapsed time let anyone later judge how much checking the verdict actually rests on. ## Why free text alone fails Six hundred rows of prose is not evidence, it is an archive. Nobody writes a query over it, nobody reads six hundred of them, and each analyst phrases the same finding differently — "render job", "legit render", "expected for this box". The moment the same fact lives in a structured field, it becomes countable: *94% of closures on this rule came from one asset group, and in every one of them the deciding field was the executing process, which the rule does not evaluate.* That sentence is actionable. The archive is not. ## Keep the direction of the claim straight A closure records **an analyst's judgment**, not a proven fact about the world. "False positive" means one person, under time pressure, concluded the activity was not what the rule was looking for. That is still the best evidence you have, and it is worth recording well — but it is a judgment, and a rule narrowed on the strength of it inherits whatever mistakes it contains. ## What is at stake if the record is thin The rule never narrows, because nobody can see which field would narrow it. The analyst keeps spending ninety seconds a night on it. And the reflex that closing this rule is free is being trained, one closure at a time — so on the night a genuine hijack lands on a render node, it is the six-hundred-and-thirteenth ninety-second close.
- The analyst records a deciding field that the rule never evaluates. Is the closure still useful?That is the single most useful thing it can contain. A discriminator the rule does not look at is exactly the finding: the rule is deciding on a proxy while the analyst decides on something else. Six hundred closures all naming the same unevaluated field is the strongest evidence packet the queue can produce.
- Why record the rule version rather than just its name?Rules get edited. If the closures span an edit, they describe two different detections, and the engineer cannot tell which behaviour the evidence is about — or whether an earlier change already fixed part of it. Versioning the evidence keeps the series honest and lets the engineer cut it at the change.
- What should the analyst write when they genuinely cannot identify the deciding field?Record that honestly rather than inventing one. "No discriminator available from the alert" is itself evidence — it says the alert gives the analyst nothing to decide on, which is a harsher finding about the rule than any single wrong field. A cluster of those is the strongest argument that the alert is unworkable as written.
A closure that says only "false positive" is a bug report that says only "it doesn't work" — technically true, and the developer cannot do a thing with it.
saying these in an interview costs you the question
- Closes with the verdict label and no reason at all
- Puts the deciding detail only in free text nobody queries
- Records the hostname but never the asset group
- Assumes the rule's author can reconstruct the reason later
- Omits the rule version, mixing evidence across two rules