What must a behavioural EDR engine observe before it convicts a chain, and what does that delay cost?
answer
- It scores a story, not a file
- Step one looks exactly like backup
- Evidence must accumulate before it exists
- Measure the damage in files, not seconds
- Earlier conviction kills legitimate jobs
basics
~20 sIt must observe enough related events on one process tree to separate malice from administration. That evidence exists only once execution is underway, so conviction lands after files are already encrypted — which is why vendors ship rollback.
solid answer
~50 sA behavioural engine does not judge a file, it judges a story: process creation with command lines, file writes, deletions and connections, tied to one process tree and scored as they accumulate. The first step of the encryption chain — enumerating shares — is indistinguishable from a backup job, and even clearing shadow copies is something administrators occasionally do. The score crosses the threshold only once several steps have stacked up in a short window, and at that moment mitigation fires: kill the process tree, quarantine, isolate, then optionally roll back. The cost is measured in files, not seconds — whatever was written before the threshold was crossed is already encrypted. Lowering the threshold to convict earlier is not free either: it starts killing legitimate backup and deployment jobs. On a one-analyst estate with no overnight cover, the engine's unattended action is the entire response for hours.
go deeper
Know that a behavioural engine watches a running process tree rather than inspecting a file, and that it needs several related events before it can decide anything.
Be ready to explain the accumulation: which steps are individually ambiguous, why the score crosses a threshold only in combination, and what the engine does the moment it does.
Demonstrate that you can quantify the latency in files lost, and argue the sensitivity trade-off against the legitimate automation on a file server estate.
Own the policy question: which asset classes get autonomous kill and isolation, given that an adversary can deliberately trip an automatic response to cause the outage for you.
## The verdict pipeline, in order A modern endpoint agent runs several stages, and it is worth being able to name them in order because interviewers use the ordering to test whether a candidate understands *when* each control can act. 1. **Pre-execution, static.** Allow-list and block-list lookups, hash reputation, a file classifier. This stage can refuse to let the file run at all. It has no opinion about a legitimate signed tool. 2. **On execution, behavioural.** The agent instruments process creation, module loads, file and registry operations, and network connections, and attributes each event to a process tree. Events are correlated into a single story and scored. 3. **Mitigation.** When the score crosses a policy threshold, the engine acts: kill the process tree, quarantine artefacts, disconnect the host from the network, and on Windows optionally roll back file changes. 4. **Reporting.** The story is pushed to the console as one incident rather than as dozens of separate events. ## Why conviction cannot be immediate The engine's problem is that every early step of the encryption chain has an ordinary explanation. | Observed step | Ordinary explanation | | --- | --- | | Enumerating shares and mapped drives | Backup or inventory software | | Deleting Volume Shadow Copies | An administrator reclaiming disk | | Writing many files quickly | Any archiving, packaging or sync job | | Deleting originals after write | An archive-and-remove retention job | If the engine convicted on step one, it would kill backup software on every server nightly. So it waits for combination, sequence and rate — several of these on one tree, in one short window, from a process whose parentage looks nothing like a scheduled task. That accumulation is real evidence, and it does not exist until the adversary has produced it. Conviction is therefore structurally late. **Late by how much is the number that matters.** For encryption-for-impact the useful unit is files, not milliseconds: a chain convicted after four hundred files leaves four hundred files needing recovery. This is the single most useful measurement to take out of the incident, because it is directly comparable across products and directly connected to what the business felt. ## The fileless case the vendors talk about When the payload never lands on disk — code executed from an interpreter, or run in memory — stage one has nothing to weigh at all. There is no file to hash and often no file to scan. The behavioural stage is not merely better here, it is the only stage with an input. That is what marketing means by "convicts fileless attacks", and it is a real property; the honest version of the claim just carries the latency caveat with it. ## The threshold is a real operational decision Two knobs matter and they pull against each other. - **Sensitivity.** More aggressive scoring convicts earlier, so fewer files are lost, and it also kills more legitimate automation. On a file server estate, the automation it kills is backup and replication — the very things you need working. - **Mode.** In detect-only mode the engine builds and reports the story but takes no action. Nothing is killed, nothing is rolled back, and on a team with no overnight cover the incident simply waits until morning. Groups often sit in detect-only during a rollout and are then forgotten, which is worth checking before you promise anyone that the estate is protected. There is a defensive-automation trap here that is specific to security rather than reliability: an adversary who knows the engine auto-isolates on conviction can deliberately trip it across many hosts and cause an outage by way of your own control. That is a reason to scope automatic isolation by asset class, not a reason to switch it off on a file server. ## What to say about the small-team constraint With one analyst and no 24x7 cover, everything between 18:00 and 09:00 is whatever the agent decided on its own. That inverts the usual reasoning: for this estate the quality of *autonomous* action — how early it convicts, whether it kills the whole tree, whether rollback is enabled — matters more than console features an analyst is not awake to use.
- That server group was in detect-only mode. What changes about the outcome?Everything after conviction disappears. The engine still builds and reports the story, but it does not kill the process tree, does not quarantine and cannot roll back, because rollback is triggered by a mitigation decision. On an estate with no overnight cover, the encryption runs to completion and the analyst reads the story in the morning.
- Why not simply block the first step of the chain outright?Because the first step has no malicious signature to it. Enumerating shares is what backup and inventory tools do all night, and even shadow-copy deletion happens in legitimate administration. Blocking on step one buys earlier conviction at the price of breaking the automation the estate depends on — and on a file server that automation is the backup itself.
- What single number would you take from this incident to compare EDR products?Files written between the first step of the chain and the mitigation action. It is objective, it is what the business actually felt, and unlike an alert count it cannot be inflated by a noisier product. Pair it with whether the mitigation killed the whole process tree or only the convicted process.
A behavioural engine is a security guard who cannot arrest someone for carrying a toolbox. He waits until the toolbox, the cut lock and the loaded van are all the same person in the same five minutes — by which time some of the stock has already moved.
saying these in an interview costs you the question
- Claims behavioural prevention stops damage before anything happens
- Believes the engine convicts on a single suspicious event
- Thinks maximum sensitivity has no operational cost
- Confuses detect-only mode with prevention
- Assumes conviction always kills the whole process tree