1. Afterword
My kids went to a private school. Not big, not fancy, just a small school where teachers and administrators were devoted to each student and given the time to help everyone shine. I was active at the school as a parent and occasionally helped with networking support and minor system administration tasks.
One day, the head of school, Elsie, called me. She had received an email from a job candidate who wanted to share their resume. Elsie opened the attached PDF.
Except it wasn’t a PDF. It was a script that ran CryptoLocker malware on her system.
Elsie had been the head of school for thirty years. She had seen students all the way through their school years, later watched them get married and have kids of their own, and then welcomed those kids to the same school. She was committed and dedicated like few people I have met, giving every student an amazing experience and supporting them in their pursuits long after they left.
Like me, Elsie is a photographer, and she has hundreds of thousands of pictures from her time as head of school. Every student, every teacher, every administrator. Every field trip, every fundraiser, every celebration. Every one of them was being ransomed.
Elsie called me, desperate for help recovering her photo archive. I asked her about backups. She had one, but it was attached to her system when she opened the email attachment. The backup was lost, too.
After some investigation and analysis, I told Elsie she had two options: pay the ransom or lose her files. We retained the encrypted files in case a decryption key ever becomes available, but to date, we have had no such luck. Elsie felt it was immoral to pay what amounted to extortion, and she lost the vast majority of her photography, the visual history of her time as head of school.
In the grand scheme of cybersecurity incidents, this was relatively minor. I have supported analysts on much larger ransomware cases, worked on the incident response team for large-scale breaches, and provided expert witness testimony for breaches involving more than a million compromised devices. But Elsie’s story is one that I think about often.
I was not responsible for her IT support, but I regret not being able to offer her more help before it mattered. I wish I had volunteered some time to help prepare her and the school’s IT staff for the threat of a cybersecurity incident, so they might have been better positioned to respond. A conversation about offline backups, a brief review of how the school handled email attachments, and even a short discussion about what to do when something goes wrong. None of that would have been difficult, and any of it might have changed the outcome.
That regret is part of why this book exists.
Incident response does not always involve nation-state adversaries, advanced persistent threats, or breaches that make headlines. Sometimes it is a school administrator who opened the wrong attachment and lost thirty years of photographs. The scale varies, but the pattern is consistent: organizations that have thought through preparation, detection, and response before a crisis have better outcomes than those that have not. That is not a complicated insight, but it is one we, as a community of cybersecurity professionals, have struggled to consistently put into practice.
The Dynamic Approach to Incident Response is my attempt to bridge that gap. This book is not a comprehensive guide to every forensic technique, every detection rule, or every cloud platform’s logging capabilities. Those topics deserve, and in many cases already have, dedicated resources. What I have tried to do is provide a framework for thinking about incident response as a discipline, one that adapts to the realities of modern threats rather than forcing them into a sequence of steps that made more sense thirty-five years ago.
No framework survives contact with a real incident perfectly intact, and DAIR is not meant to be followed from top to bottom like a checklist. The organizations and teams I have seen respond most effectively are the ones that take a framework like this, test it against their own infrastructure and threat landscape, and refine it through tabletop exercises, after-action reviews, and honest conversations about what went wrong. DAIR is a starting point, not a destination.
Incident response is difficult work, and the people who do it carry more weight than most organizations realize.
Throughout this book, I have written about analysts and responders in the third person, as practitioners applying a framework. But you, the reader, are not an abstraction. You are the person who gets the call at 2 AM, who has to explain to leadership what happened before you fully understand it yourself, who stays focused when everything around you is urgent and uncertain.
The work you do matters more than most people will ever know. When you respond to an incident well, the story ends quietly. Systems come back online, operations resume, and the organization moves forward. There is no headline for the breach that was contained before it spread, no award for the responder who caught the persistence mechanism on the second pass through the logs. The absence of disaster is hard to celebrate, but it is the direct result of your preparation, your judgment, and your effort.
You are going to face incidents where the framework does not have a clean answer, where the scope keeps expanding, and where you have to make a call with less information than you would like. That is not a failure of preparation. That is the job. Trust your training, lean on your team, and keep iterating.
I wrote this book so that the next time you get that call, you have a better starting point. I hope it serves you well.