After-Action Review & Turning Incidents into Detections

You contained the host, eradicated the persistence, and recovered service. It is tempting to close the ticket and exhale. But an incident you don't learn from is an incident you've agreed to have again. The whole IR lifecycle — detect, contain, eradicate, recover — bends back here, to lessons learned, because this is the only phase that changes the future. Everything before it restored yesterday; this phase buys you tomorrow.

The deliverable of this phase is not a feeling that you did well. It is measurable improvement: detections that didn't exist before, a faster runbook, a shorter time-to-detect on the next event. If nothing about your environment is different after the review, the review didn't happen — you just had a meeting.

Think of an aviation accident investigation. When a flight has a serious incident, investigators do not convene to decide which pilot to fire. They reconstruct exactly what happened, second by second, and then they change the checklist so the next crew — who will be tired, rushed, and human in all the same ways — cannot make the same mistake. The output is a procedure change, not a punishment. That is precisely the mindset of a good after-action review.

The core artifact of the review is a timeline of the response: when the alert fired, when a human first looked, when containment happened, when the host was confirmed clean, when service was restored. Lay these moments out in order and three things jump out on their own — what worked, what was slow, and where the gaps were (the alert nobody saw for six hours, the runbook step that didn't exist, the credential that should have been rotated sooner).

The single rule that makes this work is blameless. You are reconstructing a system's behavior, not grading a person's performance. "The alert sat unacknowledged for four hours" is a finding about a paging gap; "Sam ignored the alert" is a finding about nothing useful and a guarantee that next time Sam quietly fixes things off the record so they don't get blamed again. The moment people fear the review, they stop telling you the truth — and a review built on hidden facts improves nothing.

A simple structure: what happened (the timeline), what went well (keep doing it), what was slow or missing (the improvement candidates), and action items (each with an owner). Note that the response timeline here is distinct from — but built alongside — the attacker timeline you assemble during forensics; cross-reference your timeline-building skill, because the two share the same discipline of ordering events by timestamp from your evidence sources (logs, auditd, file mtimes).

"We got faster" is an opinion. Metrics turn it into evidence. Three numbers, all derived from the timeline you just built, tell the story of an incident's handling:

• Dwell time — from initial compromise to detection. How long the attacker lived in your environment undetected. This is the headline number; lower is better and it is brutally honest about your detection coverage.
• MTTD (mean time to detect) — averaged across incidents, how long from the malicious activity occurring to your team noticing it. Dwell time is the per-incident version of this idea.
• MTTR (mean time to respond / recover) — from detection to the incident being fully resolved (contained, eradicated, service restored). This measures how good your response is once the alarm rings.

The split matters: a low dwell time with a high MTTR means you see threats fast but are slow to deal with them (a runbook/staffing problem); a low MTTR with a high dwell time means you respond well but are blind for too long (a detection-engineering problem — exactly what the next step fixes). The metric points you at which part of the program to invest in.

Every one of these is just a difference between two timestamps from the timeline. You don't need a SIEM to compute one — two ISO timestamps and date will do it. Suppose forensics dated the initial compromise (earliest attacker artifact, e.g. the persistence file's creation) to 2026-06-20 02:14:00, and your detection alert fired at 2026-06-23 09:40:00.

Here is the engine of improvement, stated as a rule: every concrete finding from the incident becomes either a detection or a hardening change. A finding you merely remembered protects you for about a week. A finding you encoded protects you forever, automatically, even at 3 a.m. when nobody is watching. This is what actually drives dwell time down on the next incident — you catch tomorrow what you missed today.

Work from the artifacts the incident handed you. Say forensics found the attacker established persistence by writing to /etc/ld.so.preload (a classic library-preload backdoor). That is a specific, durable indicator: legitimate software almost never modifies that file. So you turn it into an auditd watch rule that records every write to it from now on. The next time anyone — attacker or not — touches that file, the kernel's audit subsystem logs it, and your alert fires.

Let's draft (not install) that rule from the finding. We only print it here; loading rules is a deliberate, reviewed action you do separately.

Detections catch the attacker faster; the runbook makes the responder faster. Every "that step was slow because we had to figure it out live" moment from the timeline is a runbook gap. If isolating the host took twenty minutes because nobody remembered the firewall command, the runbook gets that exact command, copy-paste ready, so the next responder spends those twenty minutes on the actual investigation. The aviation parallel holds precisely here: you are editing the checklist so the next crew flies the procedure instead of improvising it.

Findings that aren't detections and aren't runbook fixes are usually hardening changes, and they belong in a tracked hardening backlog with owners and dates — not buried in a report PDF nobody reopens. "Disable library preloading where unused," "enforce MFA on the VPN the attacker phished," "remove the world-writable cron directory" — each is a backlog item that shrinks the attack surface so the class of incident gets harder, not just this instance.

The loop closes like this: timeline → metrics → findings → (detections + runbook + hardening) → measurably lower dwell time and MTTR next incident. Run it every time, and your program compounds: each incident leaves you better defended than it found you.

You have a real root shell. Everything here is safe and non-destructive — you'll compute a metric and print a detection rule, but you will not load anything into the audit system. The point is to make the closing-the-loop moves reflex: turn two timestamps into a number, and turn a finding into a draft rule.