skip to content

An EDR rule auto-quarantines hosts in a live intrusion you are still scoping. How do you quiet it without going blind?

level: middleimportance: should knowfreq 41%

answer

  1. a rule has more than one moving part
  2. the alert and the action are separable
  3. off is not the same as quiet
  4. the isolation is visible to a user
  5. expire it at the cut, with an owner

basics

~20 s

Separate detection from response: leave the rule firing and collecting, and disable only its quarantine action. Disabling the rule itself blinds the case. Time-box the suppression to the planned cut and staff a human for the hits.

solid answer

~50 s

The mistake is to disable the rule. A detection and its response action are two different things, and almost every EDR or SOAR platform lets a rule alert and enrich without executing its action. Switch the rule to alert-only so telemetry keeps flowing into the case, and turn off only the quarantine, because a host dropping off the network is visible to the operator using it and to the user who calls the service desk. Then handle the risk you just created: an un-actioned true detection now needs a human, so name who is watching the queue, time-box the suppression to the planned containment time, record the change with an owner and a reason, and put the revert into the cut runbook so response comes back on at T-0 rather than being remembered later. Check nothing else keys off that action before you change it.

go deeper

for a junior

Know that a detection rule and the automated action it triggers are separate settings, and that switching a rule off during an incident destroys the very telemetry the investigation needs.

for a middle

Explain the alert-only configuration, why the isolation is observable to both the user and the adversary, and how you cover the alerts that no longer get automatic action.

for a senior

Show the operational discipline around the change: narrow scope, a named owner, an expiry bound to the containment time, a documented approval, and verification that the action really stopped firing.

for a principal

Frame when the organisation should accept a loud automated containment instead: if the loss accruing now outweighs the value of a complete simultaneous cut, quiet is the wrong optimisation.

## Why this question is asked Automated response is a control that an adversary can trip on purpose, and it is also a control that can announce your investigation before you are ready. Interviewers use this scenario to see whether a candidate understands that a detection rule has at least three separable parts — the logic over records, the alert it raises, and the action it executes — and whether they can change one without losing the others. ## What the quarantine actually reveals An automated isolation is not a quiet act. From the adversary's side, a session dies mid-command and does not come back; from the estate's side, a laptop drops off the network, its user calls the service desk, and a ticket appears in a system that may itself be readable by the intruder. If the operator holds a second foothold elsewhere — a dormant mail rule, an implant in an edge device — the isolation of one host is exactly the partial cut that teaches them what you have found and where to move. ## The change to make 1. **Alert-only, not off.** Keep the rule evaluating and raising alerts; disable only the response action. The rule is producing the scope you are still building. Turning it off blinds the investigation and removes records you will later need to show when each host was first touched. 2. **Scope the suppression narrowly.** Suppress the action for the rule, or for the specific hosts in the incident, rather than switching the platform's response engine off globally. A broad suppression protects the adversary you already know about and every unrelated one you do not. 3. **Cover the gap with a human.** The action existed because nobody wanted to wait for an analyst. Removing it means a genuine new detection sits unactioned. Name the person or the on-shift role covering the queue and the criterion that overrides the suppression — if a host starts encrypting files, you isolate it and accept the tip-off. 4. **Time-box it and bind it to T-0.** The suppression expires at the planned cut. Put the re-enable step in the containment runbook as an explicit line item with an owner, because a suppression that outlives the incident is a permanently weakened control that nobody remembers creating. 5. **Record it.** Who asked, who approved, the window, the rule id, and the reason. This lands in the case file and in the post-incident review, and it is what stops the change from reading later like an insider action. 6. **Check the blast radius of the change itself.** Response actions are often chained: a quarantine may be what creates the ticket, notifies the owner, or triggers evidence collection. Suppressing the isolation can silently suppress the collection you were relying on. ## The judgment underneath The suppression is only defensible because it is temporary and paired with a plan to cut. If there is no cut date, you are not being quiet, you are leaving an automated defence off indefinitely for an adversary who is still working. Equally, if damage is accruing now — data leaving, files being encrypted — the tip-off cost is the cheaper of the two, and you let the action fire. ## What a strong answer adds A strong candidate names one more thing: verify the change took effect the way they think it did. A rule set to alert-only in the console may still be executing an action through a different playbook, and the only way to know is to observe a hit and confirm nothing happened to the host. That is a small verification, and it is the difference between believing you are quiet and being quiet. ## Distinguishing the two failure modes - Disabling the rule: you go blind, the case stops growing, and you may not be able to reconstruct which hosts were touched. - Leaving the action on: you contain one host loudly, in the middle of an incomplete picture, and hand the adversary the information that they are being hunted. Both are wrong, and the reason interviewers like the question is that the correct answer is a third option a surprising number of candidates never reach for.

  • What do you do if the suppressed rule fires on a host that is not part of your incident?
    You treat it as a live alert with no automation behind it: a human triages immediately and isolates manually if it warrants it. That is the point of naming who covers the queue before you suppress. If the new host turns out to be part of the same intrusion, it joins the scope and the cut list rather than being isolated on its own.
  • Why is a global suppression of automated response worse than a per-rule one?
    Because it removes the control for every adversary, not just the one you are managing. Your incident justifies quiet handling of one specific behaviour; it does not justify leaving the estate without automated containment for an unrelated commodity infection during the same window. Narrow scope also makes the change easy to describe, audit and revert.
  • How would you make sure the suppression does not outlive the incident?
    Give it an expiry in the platform where one exists, put the re-enable in the containment runbook as a named step with an owner, and check it as part of closing the incident. If the platform cannot expire it, the tracking ticket carries the date and someone verifies the rule is back to acting before the case is closed.

saying these in an interview costs you the question

  • Disables the rule entirely and loses the telemetry
  • Turns off automated response platform-wide during an incident
  • Leaves the suppression in place with no expiry or owner
  • Assumes an isolated host is invisible to the adversary
  • Never assigns a human to the alerts the automation used to handle

context