Auto-close closed 4,000 alerts last quarter and a confirmed intrusion started in that window - how do you find the swallowed alert?

## What is actually being asked This is the question that decides whether your automation is auditable. Any SOC can close alerts automatically; only some can answer, months later, *did the automation close the one that mattered, and why*. The interviewer wants a method, an honest list of what the trail must have kept, and the discipline not to confuse absence of a record with absence of an event. ## Do not read 4,000 cases The investigation has already produced pivots: a set of hosts, one or two accounts, a time window with a defensible start, file hashes or names, destination addresses, a scheduled task or service name. Query the closure store with those. A well-run exercise is a handful of targeted searches, not a bulk review, and it should also cover the period *before* the currently believed start - the whole point of the exercise is that your believed start may be later than the real one because an early alert was closed. ## What a closure record has to contain To reconstruct a decision you need all of: - **The rule identity and version** that fired, so you know what was being detected. - **The criterion identity and version** that closed it. "Closed by automation" is not an answer. - **The values that matched at closure time**, not a reference to a list. If the record says the criterion matched allowlist entry `ALLOW-PATCHAGENT`, and that entry has been edited twice since, you cannot say what it contained then. - **A pointer to the retained original event**, not a rendered summary. Summaries drop the fields you did not know you would need. - **Timestamps for both the alert and the closure**, so you can measure how long the estate had an unread signal. ## The two failures that end the exercise **The mutable lookup.** Closure criteria are usually written against tables - asset owners, exempted accounts, approved paths - that change constantly. Replaying the criterion against today's table tells you what would happen today. If you cannot recover the table as of the closure timestamp (a versioned list, a change log, or the matched values copied into the record), the honest answer is "the decision is not reconstructable", and that is itself a finding. **Retention asymmetry.** Case records are often kept for years while raw telemetry is kept for thirty or ninety days. An intrusion confirmed months later meets a closure record that references an event which no longer exists. The fix is to copy the evidence into the closure, not the reference, for any criterion closing at volume. ## Separate the stages before you conclude A missing closure record has at least four explanations, and they lead to different remediation: 1. **The telemetry never arrived** - the sensor was not installed, the log source had stopped shipping, or the event type was not collected. Blindness, not automation. 2. **The telemetry arrived but no rule matched** - a detection gap. 3. **A rule fired and the criterion closed it** - what you are looking for. 4. **A rule fired, a human closed it** - a triage failure, not an automation one. Proving (1) apart from (2) requires evidence that the records existed for that host in that window; a sensor-health or ingest-volume record is what carries that. Without it you cannot claim the automation is innocent. ## What the closure proves, and what it does not If you find the alert: the rule fired and the criterion matched. It does **not** follow that the criterion was unreasonable - a well-built criterion can be satisfied by an adversary who shaped activity to fit, which is a different lesson from a sloppy predicate. Read the matched values and decide which it was. If you do not find it, you have proved nothing about the automation until you have shown the alert was ever generated. ## The output The exercise is worth running only if it changes something. Expect three deliverables: a verdict on the specific criterion (narrowed, corroborated, scoped, or retired); a fix to the trail itself so the next reconstruction is a query rather than an archaeology project; and a corrected intrusion start time, because a swallowed alert usually moves the timeline earlier - which changes scope, notification obligations and what else you have to go back and check.