The first column in this series focused on the preparation phase of Incident Response (IR), while the second covered what I call the response phase. In this third and final installment, I will cover post-incident activity: the often-neglected phase where organizations try to answer the questions of what happened, why, and how can we make sure it doesn’t happen again?
The NIST 800-61 guidelines stress that IR is a cycle, not a linear process. This is exemplified by how post-incident activity feeds directly into the preparation for future events. Post-incident steps are generally quite obvious, but in the hectic world of incident response, there’s always another urgent priority that makes post-incident review seem inessential. This could not be further from the truth. If organizations want to improve their IR processes over time, they need to be committed to thorough and consistent post-incident activity.
On that note, here are five actions that you should not overlook during post-incident activity.
1. Conduct Root Cause Analysis. Surface-level remediation stops at the “what” – you find the threat, contain it, and eradicate it. Conducting root cause analysis helps you get to the “why”, and it is often overlooked, despite its potential to quickly reduce incident volume as recurring vulnerabilities are addressed. Establish workflows and playbooks that go beyond remediation to determine root cause. For example, following a phishing attack, ask how the person in your organization got targeted. If it turns out they used their corporate email address to sign up for a less-than-reputable website, is this accounted for in your policies? If it is, then why was the employee unaware of the policy? This analysis can lead you to the underlying issues behind attacks, instead of just treating the symptoms.
2. Use Metrics to Improve Procedures. If you’re using a strong IR platform to coordinate your response, then you should have access to lots of metrics related to your performance. I strongly recommend leveraging these metrics as the basis for procedural improvements, because they can reveal truths that you might not otherwise notice. For example, metrics can show you what specific phase of response is slowing down the entire process, as well as the team members that quickly resolve their tickets—and those that don’t. Using these metrics for trend reporting also helps you quantify improvements over time.
3. Decide What Evidence to Retain and for How Long. In the second article in this series, I touched on the importance of evidence collection. Now, in the post-incident phase, you’ll need to think carefully about what you keep and how you keep it. Don’t forget to assess what data might be necessary for future litigation or audits, what needs to be delivered to regulators, and what can be disposed of. It’s tempting to save everything just to be sure, but this might not hold up to a careful cost-benefit analysis.
4. Self-Assessment. Everyone knows that it’s a good idea to have a “lessons learned” meeting to assess IR performance, but NIST guidelines also suggest asking team members to assess their own performance, as well as getting input from the owners of the resource that was targeted in the incident. This input can also be used to assess the need for future user awareness training, if it becomes clear that resource owners need additional training to avoid similar incidents in the future.
5. Properly Implementing Changes to Existing Policies Based on Lessons Learned. As I said in the intro, post-incident activities fail from a lack of follow-through, not a lack of understanding. So, my final recommendation is to simply ensure that the lessons you learn are implemented into your policies, procedures, and playbooks moving forward. Without taking the time to use the knowledge you’ve gained, analysts will continue to make the same mistakes or follow the same unnecessary steps for future incidents again and again, without any progress. If you want to reduce incident volume and overall risk over time, fight through the temptation to start working on the next incident right away and prioritize the implementation of changes.
This concludes my three-part series on overlooked actions in incident response. I hope it brought to your attention some ways you can improve your IR processes and keep your organization safe from cybersecurity threats.
