An incident response plan is the cornerstone to preparing for what is coming: an incident (a bit obvious, really). Incidents are those little things that tear businesses up. At it’s core, the Equifax breach was an incident. The Yahoo email scandal was… an incident. The Shadow Broker’s ‘hack’: an incident. Your data center just went down because of an air conditioning malfunction, guess what? Incident! They are everywhere, and cause disruption everywhere they go.
So the policy that outlines how an organization should handle incidents is extremely important. It requires time and a lot of thinking about ‘what ifs’. What I have found as great starter questions for an IR Policy, are actually pretty simple questions.
- Who needs contacted in the case of an incident?
- What constitutes an organizational wide incident?
- What legal or regulatory mandates is the organization under?
These obviously are not an exhaustive list of options, but they are a good start. Answering them can help you begin building a framework for an immature IR team to respond to an incident. Of course , by immature I mean inexperienced. Which is not a bad thing, everyone has to start somewhere!
Almost as important as having the policy though, is being specific and practicing! The more specific examples that can be generated, either through in text examples or by using playbooks, the better understood your policy will be. Which will mean the team will be in a better position to respond quickly and efficiently.
Tabletop scenarios are a huge driver of IR success as well. These practice labs allow your team to gather together and pick apart your carefully developed policy and tell you everything that is wrong with it. So that you can turn around and make it better! Always think positive! After the policy has been picked a part though, the team should run through it. Even just sitting at a table and sending fake communications to each other, across the table, is good. It will feel silly, but by practicing those actions the team will find even more problems with the policy and playbooks you have designed.
One of the final things to remember is that your policy is not written in stone. After every major incident your team should reconvene to look at how the response occurred. Did it follow the IR plan? Did it go completely off the rails? Did the support team notice better communication avenues? Maybe you found that your email was compromised and you could not actually send secure messages! These things should be addressed and added to your policy. That way the next time you can do better!
Guided Security 