While many organizations go to great lengths to set up effective security operations incident response plans, few proactively test their processes to ascertain how they will work when faced with a real threat.
Fifty-nine percent of incident response (IR) professionals admit that their organizations follow a reactive approach, according to a report from Carbon Black. Essentially, teams assume their processes work reasonably well to address the incident at hand … until they don’t. While organizations must have IR plans in place, it’s even more important that they a) work consistently and b) are updated and improved over time.
Testing incident response processes within the security operations center (SOC) should yield two important results: a clear understanding of whether your plan is likely to work and a list of gaps that should be addressed. There is no point testing them if the findings will play no role in optimizing your processes.
Lessons learned from your tests must be properly documented for them to have real, lasting value for your security operations team. Plus, you don’t want to find out your emergency plans don’t work when disaster strikes. What makes sense on paper or the whiteboard often doesn’t work as planned when put into practice.
Schools run fire drills, so everyone knows what to do when the bells go off. So, why aren’t we applying this logic more broadly in cybersecurity?
What is incident response?
IR refers to the systematic response to and management of events following a cyberattack or data breach. It involves a series of actions and activities aimed at reducing the impact of such an event.
A typical IR plan includes six phases which help the affected organization recover from an incident or simply contain it once it occurs: preparation, identification, containment, eradication, recovery and lessons learned.
When building an effective IR plan, security teams should determine the following:
The purpose of the plan.
Details on how to use the plan.
Your ability to respond to different incident types – including unauthorized access, malicious code, denial of service and inappropriate usage – and whether your information assets would be affected by such events.
Event handling protocols for each incident type and how to respond. This should include a checklist of which playbook needs to be triggered in the event of a cyberattack or breach. (A playbook, also known as a runbook, is common to the SOC and defines the flow of activities associated with a specific security issue and subsequent investigation and response. The goal is to build a consistent set of activities followed in every case, no matter the analyst assigned to it.)
Your ability to set up a “war room” for critical decision makers to receive and share information across the organization.
Testing the waters
Once you have a clear, documented plan in place, you should periodically test it through simulations to assess effectiveness and make continuous improvements. So, how can you put your processes to the test? Most security operations teams today use three methods:
1) Paper tests
The most theoretical and likely the first step for security operations teams who don’t have well-documented processes. However, paper tests leave too much room for error and should only be used to look for small process changes.
2) Tabletop exercises
These scenarios consist of company stakeholders sitting around a, you guessed it, table and running through a mock security event. While these exercises may appear informal, you should prepare well in advance, make sure the right individuals participate from across the organization and that the scenario is as real as possible. Allow for up to half a day to put key processes through their paces and troubleshoot as you go.
3) Simulated attacks
The most effective way to pressure test your processes is to simulate a real-world attack to see how your organization will respond. These tests not only evaluate what your team would do when faced up against a major incident, but how they would do it. Simulated attacks are often still done tabletop style, but an increasing number of security orchestration tools – via playbooks for common use cases – help teams automate the response to attacks, eliminating reliance on so-called tribal knowledge within the SOC. Security incidents are stressful enough for security operations teams who are prepared and on the same page, let alone those who start from scratch with every incident. Playbooks should always be updated after they’ve been used, whether as a testing tool or as part of a real security incident triage and remediation situation. As an added benefit, playbooks will help you identify opportunities to apply automation to your IR processes to expedite remediation and free up your analysts to focus on higher-value tasks.
Having a good IR plan becomes worthless if it fails to provide a suitable response to a threat. Your processes should be codified, documented and regularly tested for vulnerabilities. It is far better to be prepared for a disaster that never occurs than to find you are woefully unprepared when one strikes.