Designing An Effective Incident Response Plan

Let's face it; cybersecurity is no picnic. Despite the fact that we work ceaselessly to protect, monitor, and defend our networks, cybersecurity incidents still occur. From data exfiltration due to insider threat to disclosure of your users’ credentials via external attack, it's a given that you need to maintain situational awareness at all times in order to be able to detect and respond to the myriad potential incidents that can arise.

Incident response: The elephant in the room?

We don’t always speak of cyber security incident response, but when we do it’s in hushed tones, hoping that we never have to do it. We should be facing this beast head on. The reason why many organizations fear cybersecurity incidents is because they do not have an appropriate plan in place. The best way to shrink the elephant - and sleep better at night - is to have a tried and tested incident response plan in place.

“Plans are of little importance, but planning is essential”

Winston Churchill was onto something. Although the best laid plans can be rendered useless when an attack is successful, proper planning will make the attacker’s job harder and keep your blood pressure that much lower. If you currently don’t have an incident response plan in place, you might not see the benefits to having such a plan, or the risks associated with not having a plan in place. It's at this point that to carry on reading will prove useful ...

What’s in it for me?

Creating a cybersecurity incident response plan can be a pain. Publishing and establishing maturity of said plan can be harder. If you have a good incident manager, however, they'll be steadily improving the plan by ingraining themselves into core business requirements and working with stakeholders to ensure that the plan is accurate and accessible. Proper planning and incident management leads to:

• Decreased response time due to established process flow and cybersecurity incident response team rules of engagement - when the alarm bells ring, we can all keep calm and refer to the cybersecurity incident response plan. Process flow also helps define measurement of your security incident response efforts, which is a huge win.
• Increased visibility into various business processes - if we know how the business operates on a daily basis, we can identify attack surface, stakeholders, and various gaps in organizational information security (ie: lack of education leading to potential increase in unintentional insider threat)
• Develop key relationships between information security team and the rest of the organization - performing regular testing of the incident response plan allows the security team to meet or reconnect with colleagues from other areas of the organization with whom they may not have much business on a day-to-day basis. Rapport with various stakeholders and actors can be a catalyst in ensuring that incident response activities flow smoothly.
• Integrate with organizational crisis communications, legal, and public relations teams - When things go south, understanding who to tell and when can be the difference between showcasing your incident response prowess and apologising to the world for your mistakes.

Still not convinced?

If there’s a chance that you still don’t think that an incident response plan is a priority for your organization, here are some of the risks that come with not having a proper cybersecurity incident response process.

• Increased reaction time - not having documented, published process in place can turn a potentially orderly, successful incident response into a cat-herding party. Lack of formal escalation path, contact lists, or stakeholder information can make the smallest security incident seem like (or bloom into) the next big breach.
• Lack of visibility - if your security operations center escalates a potentially serious security incident to your incident response manager, the absence of an incident response plan means that said manager now needs to either refer to their notes (if they have any) from previous incidents, or they need to start from scratch. To whom do we escalate? Where is that sort of information stored?
• Inability to be proactive and collaborative - life without an incident response plan can amount getting caught with your proverbial pants down more than you might think. Simple incidents can lead to confusion, and even degrade to bouts of infighting due to lack of roles and responsibilities. It’s quite annoying, really.
• Trouble relaying pertinent information - if you aren’t prepared to perform cybersecurity incident cleanup procedures, you might find yourself in front of a panel consisting of your executive, legal, and PR teams asking a lot of difficult questions. Having a security incident response plan in place can help you better prepare for those tough questions, and make you look like a rockstar.

Writing the sacred scroll

It's really easy to overthink response planning, it’s true. The best way to get prepared is to just start writing the plan. One of the main principles to follow throughout the creation, testing and improvement of an incident response plan is the iterative OODA principle: Observe, Orient, Decide, Act. Let’s break it down:

Observe: Watch what happens on a daily basis. How does your security operations team monitor for and react to security events? Does the greater information security team have any key relationships? How does the business run? How are other teams organized to help the information security team? How does your incident response plan look when put to the test?

Orient: Get your bearings. Understand how the information you gathered through observation can be used to your favour when it comes to activating an incident response capability. Are you more susceptible to an insider threat or external attack? Who seems to know the most about the Linux servers in your domain? Do you have executive buy-in to do the needful in case of emergency? Is there a link between information security and the crisis communications team? How long does it take to respond to a typical security event or incident?

Decide: Map out how you are going to improve (or start building) your security incident response plan. Who will be key members of the cybersecurity incident response team (CSIRT)? How will security events flow from the security operations center (SOC) up to the CISO? Which relationships need to be restored, improved, or created among other teams? Do sufficient policies exist to back up incident response actions? Where will new efficiencies be created?

Act: Publish the security incident response plan. Get your observations and ideas down on paper. Ensure that you take into account all of the decisions you have made based on observations and the context that you have wrapped around them. Then get ready to start the loop over again!

This is not a test… well, actually it is.

Once you have a response plan in place, you need to ensure that you test it, lest it grow stale. In the early stages of development, you may engage your incident manager and play by the book for every routine security event. Operationally, this can seem a bit onerous, but getting your teams exposed to incident response in your environment is never a bad thing. This also helps keep your incident manager productive, busy, and happy… mostly...

While operational testing is great, formal testing is a must. Generally, you'll need to gather a relatively large team of stakeholders, actors, attackers, responders, and executives to perform this test. Create a scenario that will fully test the plan, pull your responders out of their comfort zone, and help build the required rapport between various teams.You may find out that you don’t quite know as much about your organization as you thought - and that’s great! Learning is a staple to progress, and each of these exercises should be about learning. Some teams might want to use this test to showcase their incident response plan to the executive team. The best tests, however, are those with a bit of a curve ball, resulting in a better understanding of the organization as a whole, how it works, how it can be breached, and how well equipped the greater team really is to respond.

Cybersecurity itself is a process, not an end-state; incident response is no different. With good planning, robust testing, and enough spins through the OODA loop, you can have a fairly decent incident response plan published and ready for action. It may just save you the hassle of explaining to the world on public television why you were not quick enough to contain the breach that landed a million of your clients’ credit card numbers on the Internet.