Let the EDR act on its own when the cost of being wrong is lower than the cost of waiting. In practice that leaves very few signals: mass file encryption, deletion of backups, and tampering with the agent itself. Anything that depends on a legitimate account or an administration binary goes through a person, until you have a tested rollback and someone on call.
What does each response action break if it fires wrongly?
The actions an EDR with live response offers do not carry the same risk as each other, and not the same risk on a laptop as on a domain controller. It is worth knowing what outage each one causes when the detection is wrong.
Isolating the host cuts its traffic to the rest of the network: it stops lateral movement and exfiltration from that machine, and it is the action that buys the most time. When it fires wrongly, the user loses the network mid-task, and if the isolated machine is a server, everyone who depends on it loses it too.
Killing the process stops execution in progress. The usual failure is not that the process dies, it is that it dies mid-write: a database halfway through a commit, a document halfway through saving, an installer halfway through applying. And killing the parent takes the children: terminating a service process can drop something that was not in the alert.
Quarantining a file takes it out of circulation with its hash and its chain of custody. This is the action that most often takes down a line-of-business app: vertical software tends to be signed by a publisher nobody recognises and installed outside Program Files. The app stops launching and, two hours later, nobody connects the outage to the quarantine.
Blocking the account cuts the session and subsequent logons. It leaves a real person locked out of mail and VPN, and the unblock depends on the identity team, not on the analyst. It has the longest way back.
| Action | What it stops | What it breaks if wrong | Safe to automate? |
|---|---|---|---|
| Isolate the host | Lateral movement and exfiltration | The user loses the network; if it is a server, so do its clients | Only for narrow patterns and on user laptops |
| Kill the process or tree | Execution in progress and its children | Half-written data; sibling processes that needed the parent | No, unless the behaviour has no legitimate equivalent |
| Quarantine the file | New executions of that binary | A line-of-business app is left without an executable | No, not without exclusions for your vertical apps |
| Block the account | The live session and subsequent logons | A real person with no access, unblocked by another team | No; the way back is far too long |
| Roll back file changes | The changes made by the stopped process | Legitimate later writes lost if the window is miscalculated | No; it depends on getting the window right |
Which signals can be automated without much argument?
The test is not how much you trust the detection, it is what happens if it is wrong on that machine. The signals that tolerate automation are the ones with almost no legitimate activity that looks like them, because there the expected cost of a false positive approaches zero. In practice those are signals of impact or of sabotage of your defences, not of suspicious execution.
- Mass file encryption by a process that is not your backup software. MITRE ATT&CK documents this as Data Encrypted for Impact (T1486), under the Impact tactic. A user process rewriting hundreds of files per second on a share has no administrative equivalent, and every minute of waiting costs files.
- Deleting volume shadow copies or turning off system recovery. ATT&CK covers this as Inhibit System Recovery (T1490), and its page cites
vssadmin.exe delete shadows /all /quietamong the examples from families such as WannaCry, Ryuk, Conti and LockBit. No administrator runs that on a salesperson's laptop. - An attempt to stop, uninstall or degrade the agent itself. ATT&CK describes this in Disable or Modify Tools (T1685), which covers killing EDR processes, changing their configuration and cutting telemetry to the SIEM. With no declared maintenance window open, an automatic response is defensible.
And which signals should you not automate?
Use of valid credentials is the clearest case. The Valid Accounts (T1078) page notes that an attacker may skip malware altogether, because the legitimate access those credentials give makes their presence harder to detect. A logon from a new IP at three in the morning is a salesperson in another time zone as often as it is an attacker.
The same holds for PowerShell and signed system binaries. ATT&CK documents their abuse in T1059.001 and in System Binary Proxy Execution (T1218), whose description points out that the binaries involved are often Microsoft-signed. They are the same tools your MDM uses to push packages and your scheduled tasks use to take inventory.
Two qualifiers matter as much as the signal. Asset class: the same mass-encryption detection you would automate on a laptop is not automated on a hypervisor, because the cost of a false positive changes by an order of magnitude. And rule age: a detection written last week has no false-positive history yet. Automate pairs of signal and asset class, never bare signals.
How should a small team start?
With everything on approval. That is Protoxol's documented position: playbooks propose the action, queue it and explain it, and a person approves before anything runs, as set out in how the platform is built and in the response automation module. For narrow patterns such as mass encryption, isolation can be configured to run on its own and notify afterwards.
- Weeks 1 to 8: approval for everything. The goal of this phase is not better containment, it is accumulating history. For each alert, record which action was approved, how long approval took, and whether it turned out to be right. Without that, deciding what to automate is an opinion.
- One automation, as narrow as you can make it. One signal, one asset class, one action: isolation on mass encryption on user laptops, with servers excluded by name.
- Review at 30 days. If there were no false positives and containment time dropped, add the next pair. If there was one, understand why before adding anything.
One factor upsets this plan and is worth settling early: the time of day. At three in the morning nobody will approve anything for six hours, and a mass-encryption detection that waits six hours is useless. Teams without an on-call rota often end up with two rules for the same signal: approval during business hours, automatic with notification outside them. EDR for small business has the context for why a team with no SOC starts here.
What has to be in place before you switch anything to automatic?
- A tested rollback. You have isolated a real machine, taken it out of isolation, and you know how long that took. If you have only done the outbound leg, you have a ticked box, not a rollback.
- The scope in writing. Which signal, which action, which asset class, and the explicit exclusion list: domain controllers, file servers, hypervisors.
- A named on-call owner with a phone number. Somebody receives the notification of the automatic action and knows what to do. A shared mailbox is not an owner.
- An exportable audit trail. What fired, which rule fired it, on which machine, at what time, and who reverted it. It lets you review the decision and answer the user asking why they lost the network on Thursday.
- A communication path to the affected person. The text they see when their laptop loses the network, and a reply channel that is not corporate mail: that is on the machine you just isolated.
- Declared maintenance windows. Deployments, patching and migrations produce behaviour that looks a lot like an attack. If the EDR does not know about them, you will be containing them yourself.
- History for the signal. A few weeks of that detection running in approval mode, with false positives counted, not estimated.
- A switch-off criterion decided in advance. How many false positives send that automation back to manual approval. Deciding it in the middle of an incident never goes well.
How do you review the decision afterwards?
Every automatic execution gets classified within 24 hours, with three labels rather than two: correct, false positive, and correct but excessive. The third is the most informative: the detection was right and the action was disproportionate for that asset. The fix there is not disabling the rule, it is changing the action or excluding that class of machine.
Once a month, two numbers are enough: how many automatic false positives there were, which is the cost, and how far time-to-containment dropped, which is the benefit. If the first rises and the second does not move, that pair goes back to approval. Every live automation should also have an owner and a review date, so it does not outlast the threat that justified it by years.
The question was never whether to automate response. It is which triples of signal, asset and action you have earned the right to automate, and how often you look at the list again. The scope of the available actions is on the EDR module page; what each plan includes is on plans and pricing.