Auto-closing a detection's alerts versus deleting the rule - what changes about catching an intruder?
answer
- one lever spends time, the other spends sight
- which one still writes a record?
- the rule keeps firing in exactly one case
- a green dashboard over an unread queue
basics
~20 sAuto-closing keeps the rule firing and writing records you can search later; only the human verdict is automated. Deleting the rule ends detection entirely, so an intruder using that technique leaves nothing behind to find.
solid answer
~40 sThey are decisions about two different resources. Auto-close spends analyst time: the rule still runs, still fires, still writes an alert and a closure record, so the activity remains searchable for a retro-hunt or a later investigation - you have only automated the verdict. Deleting spends visibility: nothing fires, nothing is written, and an intruder using that technique produces no artefact you can go back to. That makes auto-close the safer lever on paper, but it has a failure mode delete does not: the coverage dashboard still shows the rule green while every case is being closed unread, so a blind spot looks like coverage. Auto-close therefore only counts as the safer choice if the closure keeps the original event, is searchable alongside open cases, and the criterion is reviewed like a detection.
go deeper
Be ready to state the difference in one breath: auto-close automates the verdict and still leaves a record; deleting the rule ends detection and leaves nothing. Do not call an auto-closed alert a false positive.
Explain what survives each choice - alert, raw event, retention, countability - and why an auto-closed alert proves only that a criterion matched, never that the activity was harmless.
Show the judgment: before you accept auto-close as the safe option, verify the original event is retained long enough, closed cases are searchable, and the criterion has an owner and an expiry. Otherwise it is deletion in disguise.
Own the reporting consequence. Decide how coverage is stated when a rule fires but nothing acts on it, and insist that blanket auto-close is declared as a visibility decision rather than buried as a queue-management one.
## The three levers A SOC with more detections than it can work has exactly three things it can do to any one rule: **tune** it so it fires less (narrowing its logic or scoping it, which is detection-engineering work), **automate** the verdict so alerts are closed without an analyst reading them, or **delete** the rule and stop detecting the behaviour. Interviewers ask about the second and third together because candidates routinely treat them as interchangeable ways of "getting rid of the noise". They are not. ## What auto-close actually does Auto-close leaves the detection intact. Telemetry is still collected, the rule still evaluates it, an alert is still produced, and a machine - a closure criterion - writes the verdict instead of a person. Four things survive: - **The alert exists.** It has an id, a timestamp, a host, an account. - **The underlying event is still there** (subject to retention), so a hunt or a post-incident timeline can find it. - **You can count it.** The rate of auto-closures per criterion is a measurable number that can itself be alerted on. - **You can replay the decision** - if, and only if, the closure record kept enough to reconstruct why it matched. What does *not* survive is the human judgment. Nobody looked. So an auto-closed alert proves that the rule fired and that a criterion matched. It does **not** prove the activity was benign, and a candidate who says "it was auto-closed, so it was a false positive" has stated the single most common wrong answer in this area. ## What deletion does Deleting the rule removes the last stage that turns telemetry into an alert. If the underlying telemetry is still collected and retained, you keep *evidence* while losing *detection*: you will not be told at the time, but a hunter or an examiner can still find the behaviour afterwards. If the deletion is accompanied by turning off the collection - dropping the log source because nothing consumes it any more - you lose both, and the intrusion leaves nothing at all. That distinction is the one worth stating out loud in an interview, because it is the compromise that often makes a deletion acceptable: stop detecting, keep the records. ## Why auto-close can be worse than deletion Deletion is honest. Everyone can see the rule is gone; a coverage review will show the technique uncovered; someone has to sign for it. An auto-close criterion applied to every alert from a rule produces the same practical blindness while the rule still appears on every dashboard as deployed and firing. Two consequences follow: 1. **The coverage claim is false.** A report saying "we detect this behaviour" is true about the rule and false about the outcome, because no human or downstream process ever acts on it. 2. **The criterion is an unreviewed detection written backwards.** A detection rule decides "suspicious" and gets peer review, testing and an owner. A closure criterion decides "benign" at far greater volume and, in most SOCs, was added by whoever was drowning that week. An adversary who can satisfy it gets a guaranteed close. ## What makes auto-close defensible - **The original event is retained**, not just a case summary, and for at least as long as the investigations that might need it. - **Closed cases are searchable in the same place as open ones.** A closure store that analysts cannot query is evidence you cannot reach. - **The closure record replays**: which criterion, which version, which field values matched, at what time. - **The criterion is scoped, owned and expiring** rather than a permanent global truth. - **A sample is read by a human**, so the criterion's error rate is measured rather than assumed. ## The queue reality behind the question The reason the question exists is that a small team watching a large estate cannot read everything, at any tuning level. So the choice is not "work it or automate it"; it is "which of these three levers, with what evidence, and who is told". The right answer names the lever, names what it costs, and names who is now blind - not a claim that the queue got smaller.
- Six months after an intrusion, is an auto-closed alert from that period any use to you?Yes, if two things held: the closure retained the original event rather than a summary, and closed cases are searchable next to open ones. Many platforms purge auto-closed cases early or exclude them from the analyst-facing view, which converts a recoverable record into a real gap. Check both before you rely on auto-close as the safe lever.
- Which is more dangerous on a coverage report: a deleted rule or a rule whose alerts are all auto-closed?The auto-closed rule. A deletion is visible - the coverage review shows the behaviour uncovered and someone has to own that. Blanket auto-close leaves the rule listed as deployed and firing, so the report claims detection while no human or downstream action ever follows. Blindness that looks like coverage is the harder failure to find.
- If you delete a detection, does the intrusion become unreconstructable?Not necessarily. Deleting the rule removes detection, not evidence: if the underlying telemetry is still collected and retained, a hunter or examiner can still find the behaviour after the fact. It becomes unreconstructable only if you also drop the log source because nothing consumes it any more - which is a separate decision, and usually the one that should be refused.
Auto-closing is a smoke alarm wired to a switch that silences it automatically; deleting is taking the alarm off the wall. Only one of them still logs that it went off.
saying these in an interview costs you the question
- Treats auto-closing and deleting as the same noise-reduction move
- Says an auto-closed alert was benign because it was auto-closed
- Assumes deleting a rule also deletes the underlying telemetry
- Counts an all-auto-closed rule as coverage on a report
- Never asks whether closed cases are still searchable