Phase 7 · DFIR — Investigation & Forensics
DFIR capability is not built during an incident. It is built before one. Forensic tooling pre-deployed, evidence preservation procedures documented, legal and communications protocols established, out-of-band communication plans ready. The organization that builds its incident response capability while the adversary is inside is already behind.
The most costly DFIR mistake — made repeatedly, across organizations of every size and sophistication level — is restoration before investigation. The affected systems go down. The pressure to restore is immediate and intense. The systems come back up from backup. The organization declares the incident over. And three weeks later, the adversary is back — because nobody understood the scope of compromise before restoring, and the initial access vector was never closed.
DFIR is not crisis management. It is intelligence collection under pressure. Every adversary technique confirmed during investigation is ground truth about how that adversary operates in your specific environment. Every pivot point that analysts traverse during the investigation is evidence about which log sources actually matter. Every gap in visibility that allowed the adversary to operate undetected is a detection engineering requirement. The incident is not just a crisis to resolve. It is the most accurate intelligence collection event your program will ever experience — and organizations that treat it purely as crisis response discard the most valuable output.
The evidence that tells you the scope of compromise exists only as long as the affected systems are preserved. Memory forensics, disk images, log captures, network flow data — all of this exists in a window that closes the moment affected systems are wiped and restored. Legal hold, regulatory reporting, insurance claims, and your own intelligence program all depend on what forensics can recover before restoration. The pressure to restore quickly is real. The discipline to complete forensic investigation before restoration is what separates organizations that recover once from organizations that get breached twice by the same adversary using the same technique they never fully understood the first time.
The scope-of-compromise questions that must be answered before restoration: How long was the adversary present before the triggering alert? What other systems were accessed? Was data exfiltrated, and if so what? Did the adversary establish persistence mechanisms that survive a restoration? Were other parts of the environment compromised that have not yet been identified? Restoring before answering these questions does not end the incident. It restarts it.
Sophisticated adversaries specifically monitor internal communications during the period between initial access and execution. They are looking for evidence that they have been detected, for the IR team's understanding of their presence, and for the organization's response plan. If your incident response coordination happens over the email infrastructure, the Slack workspace, or the collaboration tools that the adversary has access to — you are conducting your response in front of them. Out-of-band communication plans — a separate channel the adversary does not have visibility into — are a readiness requirement, not an advanced feature.
Every confirmed adversary technique becomes a detection rule. If the adversary used a technique and your detection did not fire, that is a detection gap. Every confirmed gap becomes an engineering requirement.
Every pivot point analysts used during the investigation validates the log sources that supported it. Every pivot that failed because data was missing or incomplete becomes a log strategy requirement.
Every confirmed adversary behavioral signature becomes a hunting hypothesis. The technique they used against you once is the technique they may have used earlier without triggering an alert — and the technique they will use against similar organizations next.
The intelligence value of a DFIR investigation is realized only if the findings are systematically fed back into the program. Detection gaps identified during the investigation become engineering requirements before the next threat intelligence cycle. Log sources identified as critical during investigation get their pipeline integrity verified. Behavioral signatures confirmed in your environment become hunting hypotheses for the next hunt cycle. This is the feedback loop that makes the security program continuously improve — and it starts with treating DFIR as an intelligence collection activity, not only as a crisis response operation.
Forensic tooling needs to be deployed to endpoints before an incident — not scrambled during one. Evidence preservation procedures need to be documented and tested. Legal and communications protocols need to be established — who is notified when, in what order, with what information. Chain of custody procedures need to be in place before anyone asks for them in a regulatory or legal context. And the out-of-band communication plan needs to exist and be practiced before the adversary is inside your environment.
DFIR readiness is tested before it is needed. Tabletop exercises that walk through realistic incident scenarios — specifically the scenarios your threat intelligence says are most likely — reveal gaps in the readiness program that can be closed before they matter. The organization that discovers its forensic tooling was not deployed to a critical server category during an actual incident has paid a far higher cost for that discovery than the organization that discovered it in an exercise.
The readiness principle: You do not build DFIR capability during the crisis. You activate it. The difference between those two statements is the difference between an incident that takes weeks to contain and understand, and one that takes days. The capability is built now. The activation is practiced in exercises. The real incident is when it all has to work.