The incident response loop

From detection to lessons learned.

Individual response actions come together in a repeatable incident-response process, so that under pressure you follow a plan instead of improvising. The widely-used loop has clear phases: preparation (before anything happens), detection and analysis (something fired — is it real, and what is its scope), containment, eradication, and recovery (stop it, remove it, restore service), and finally lessons learned (make the next one less likely). Each phase has a goal, and skipping or rushing one — especially scoping before eradicating — is how incidents recur.

Scope before you eradicate

The most important discipline is scoping the incident fully before you try to remove the attacker. If you clean one host while the attacker is on three, or you miss a persistence mechanism, they simply return — often more carefully. Use the fleet-wide tools (osquery, the central event store) to answer "where else is this?": the same indicators, the same persistence, the same credentials. Only once you understand the full footprint do you eradicate everywhere at once, rotate every credential the attacker could have touched, and rebuild compromised hosts from known-good media rather than cleaning in place.

Recovery and the post-incident review

Recovery restores service from a trusted state — rebuilt hosts, rotated credentials, patched entry vector — and confirms the attacker is gone, ideally with heightened monitoring for a return. Then comes the phase teams most often skip and most need: the blameless post-incident review. What was the root cause? Why was it not caught earlier? What detection, hardening, or process change would have stopped or shortened it? Every incident should leave the environment measurably harder to attack the same way — a new detection, a closed escalation path, a faster response step. That feedback loop is what turns painful incidents into a stronger posture.

This closes the arc of the whole Linux track: you learned to operate a host, to harden it, to understand how it is attacked, to see what happens on it, and finally to respond when prevention fails and feed what you learn back into prevention. That cycle — operate, harden, detect, respond, improve — is the entire job of a DevSecOps engineer defending Linux, and you now have the full loop rather than any single piece of it.