Measuring Incident Response Success: Dwell Time, Scope, Eradication

What "worked" actually means

A response can feel busy and thorough and still leave the attacker with a way back in. This sub names the measures that tell you whether a Linux investigation actually worked, separating the response that closed the incident from the one that only felt like it did. These are not dashboard metrics; they are the questions an honest responder asks to know whether they are finished.

It is the standard you hold every technique to as you learn it. Knowing what success looks like before you learn the forensic moves means you learn each move knowing what it is for.

Feeling thorough is not being effective

The most dangerous outcome of an incident is not a response that fails visibly. It is a response that feels complete and is not, because that one closes the ticket, stands the team down, and leaves the attacker quietly in place. Linux makes this failure easy to fall into: you find the web shell, remove it, see the CPU return to normal, and everything looks resolved, while the cron job, the planted SSH key, and the second host the attacker moved to are all untouched. The cure is to judge the response against measures that an attacker still present would fail, rather than against how much work it felt like. Five measures matter most.

Four of these you can answer as you close the incident. The last, in terracotta, you cannot: eradication is proven only by the quiet period after, which is why a recovered host stays watched. Effort answers none of these questions; only evidence does.

Dwell time

Dwell time is the interval between the attacker's initial access and the moment you detected them. It is the single most telling number about a security program, because everything an attacker does happens inside that window, and the longer it is, the more they accomplished. A dwell time of hours means you caught the intrusion during its early stages; a dwell time of months, which is common, means the attacker had the run of the environment for a quarter of a year before anyone noticed. You establish it during analysis by finding the true entry point, the Stage 1 from Section 0.2, and measuring forward to detection. Reducing it is the point of the detection and readiness work in Modules 15 and 16: the faster you detect, the less an attacker can do. As a measure, dwell time tells you whether your problem is detection (long dwell, the attacker operated freely) or response (short dwell, you caught it fast but must now act well).

There is a revealing companion question: how were they finally detected? An intrusion caught by your own monitoring, an alert that fired on the attacker's behavior, reflects a program working as intended. One discovered only because a third party noticed, a hosting provider flagging outbound attacks, a partner reporting stolen data, the systems grinding to a halt under a miner, reflects detection that failed and was rescued by luck or consequence. The detection source, paired with the dwell time, tells you both how long the attacker had and whether you would ever have caught them on your own. A long dwell time ended by an external tip-off is the strongest possible argument for the detection-engineering work the course builds toward, because it means the only reason the incident was found at all was outside your control.

Scope accuracy

Scope accuracy is whether you correctly identified everything the attacker touched. As Section 0.7 stressed, under-scoping is the expensive analytical failure: declaring an incident resolved on one host while the attacker holds two others is not resolution, it is a pause. You measure scope honestly by asking whether you followed every lead to its end, every outbound connection, every credential the attacker could have stolen, every host they could have reached from the one you are on, or whether you stopped at the first compromised system. A scoped investigation can draw the boundary of the intrusion and defend it. An unscoped one assumes the boundary is the host that happened to alert, which is rarely where the attacker stopped. This is why so much of the course trains following evidence outward rather than fixating on the first finding.

Collection completeness

Collection completeness asks whether you preserved the evidence you needed before it decayed. It is measured against the order of volatility from Section 0.3: did you capture memory before the reboot that would have erased it, snapshot the network state before the connections closed, collect the temporary filesystems before they cleared? An investigation missing its volatile evidence is permanently limited, because that evidence cannot be recovered later, and the gap often is not visible until analysis, when you reach for the process that was running and find you never captured it. Completeness is partly a measure of the response and partly a measure of readiness: a host configured in advance to forward its logs off-box, as Module 16 covers, gives you complete collection even when the on-host evidence was destroyed.

Whether eradication held

The final measure is the one you can only take after the fact: did the attacker come back? Eradication that held means every foothold was removed and the door they entered through was closed. Eradication that failed shows up as the same attacker returning days or weeks later, usually through a persistence mechanism you missed or the original vulnerability you never patched. This is the measure that punishes the Section 0.6 failure of stopping at the first foothold, and it is why eradication is judged not at the moment you finish but in the quiet period afterward. A response is not proven effective when you close it. It is proven effective when time passes and the attacker does not return, which is why monitoring a recovered host closely after an incident is part of the response, not separate from it.

Containment speed

Between detection and eradication sits a measure that often matters more than either: how quickly you contained the damage once you knew it was real. Containment speed is the interval from confirming an incident to stopping the attacker's ability to cause further harm, by isolating the host, killing the active process, or cutting the attacker's connection. It is distinct from how long the full investigation takes, because containment and analysis are different goals: you can contain in minutes and analyze for days, and frequently should. The measure exposes a specific failure, the team that spent hours perfecting its understanding while the attacker continued exfiltrating data or spreading to new hosts, because it treated analysis and containment as sequential when they could have run in parallel. A fast containment that preserves enough evidence to still investigate well is a mark of a mature response, and the judgment of when to contain versus when to keep watching, since containing alerts the attacker, is developed throughout the response modules. The trade is real: contain too early and you may tip off the attacker and lose the chance to map their full activity; contain too late and they do more damage. Measuring containment speed keeps the trade honest.

Why measures, in an orientation module

Naming these measures now, before you have learned a single forensic technique in depth, is deliberate. They are the standard you hold every technique to as you learn it. When Module 2 teaches timeline analysis, its purpose is scope accuracy and dwell-time measurement. When Module 12 teaches memory capture, its purpose is collection completeness. When Module 7 teaches the full persistence catalog, its purpose is eradication that holds. The techniques are means; these measures are the ends they serve. Carrying them from the start means you learn each skill knowing what it is for, which is the difference between collecting techniques and building judgment. The orientation is now complete. The remaining sections set you up to practice: a brief note on the environment the course references, the toolkit and lab you will build, and an interactive exercise to put the triage sequence to work.