A recent survey of 4,100 cybersecurity pros by the international insurance company Hiscox reported that 73% of organizations are unprepared for a cyberattack.
That’s a startling statistic because the global enactment of strict regulations requires organizations to quickly identify security incidents and notify affected parties—within 72 hours for breaches under GDPR.
In order to meet these tight timeframes, organizations need to have incident response plans that are documented, consistent, and fast-acting. These plans are the foundation for meeting a company’s security and compliance obligations, and not having an effective plan in place can result in tremendous fines, such as the recent $4.3 million HIPAA penalty against the University of Texas MD Anderson Cancer Center.
Incident response plans provide a step-by-step blueprint of what your organization needs to do when an incident or breach of any kind occurs. With so much focus on automation and orchestration, sometimes incident response planning gets overlooked, which can cause problems at the worst possible time—when an incident hits.
How Should You Structure Your Plan?
There are publicly available frameworks that can be valuable resources when building your incident response plan. One of the most widely used is the NIST 800-61 Computer Security Incident Handling Guide. NIST breaks incident response into four distinct, yet integrated, phases:
- Preparation
- Detection & Analysis
- Containment, Eradication & Recovery
- Post-Event Activity
For more detail on these steps, check out our previous blog on the subject.
Who Should Be Involved?
Incident response planning should not be limited to the security team. To develop a comprehensive plan, involve people from other teams that might be involved in response procedures, such as HR, IT, PR, and legal. You can leverage the skills of each team in the plan, such as having a PR representative write breach notification templates or having the legal team review outbound documents.
You should also keep a list of external stakeholders, and how they might be involved in the plan, such as law enforcement, regulators, forensic consultants, and external counsel. Have you made the necessary arrangements to facilitate their involvement, such as creating secure ways to share information with them during the response process? Do you have alternate resources in place, in case a key vendor or third party is unavailable?
How Should You Train Your Team?
All employees should get some training related to the incident response plan, not just the people who will directly carry it out. Incident response orientation should be a regular part of the onboarding process for new hires, along with regular security hygiene training around data handling and how to spot and report a phishing attempt.
The security team can prepare itself through simulations and table-top exercises. For inspiration, take a real security incident that made the news recently and walk through how you would respond to it. How would your plan measure up?
When Should You Add Automation and Orchestration?
Automation and orchestration are powerful capabilities, but instead of simply shoehorning them into your plan, understand first what you’re trying to gain. Talk to your security analysts—they can identify bottlenecks and reporting gaps and tell you their pain points, which are often repetitive tasks that can be automated. You should also decide in advance what critical business requirements need to be prioritized—such as compliance procedures, audit readiness, SOC KPIs, and SLAs.
Map your existing tools and processes to identify possibilities for easy improvements, as well as silos that could be eliminated by orchestrating between systems. Who “owns” the tools to which you will need access? The security team won’t necessarily have ownership over all the tools that are involved in incident response automation and orchestration, such as Active Directory, which is often controlled by the IT team.
What Metrics Should You Track?
For automation and orchestration specifically, as well as for the incident response plan as a whole, it is important to know how you will measure success. Is your goal to respond faster to threats? To reduce the amount person-hours required to operate your SOC? Or to lower incident volume over time by minimizing vulnerabilities?
Useful SOC metrics to consider include mean time to detection, mean time to resolution, response times for each incident type, response times for each playbook. Some other good metrics are the percentage of recurring incidents and the percentage of incidents with compliance implications.
How Can You Improve Your Plans Over Time?
When you are developing your incident response plan, there are a few things you can do that will set you up to easily make improvements in the future. One is to ensure you have strong trend reporting, so that you have visibility into how your security posture is changing. Another important step is to make sure your plan gives you the ability to easily create new incident types and incorporate changing compliance obligations, so you aren’t stuck with an obsolete plan in a few months. Finally, look at the contracts you have with your vendors, as they can compromise your security. Does the contract require them to notify you of security incidents on their network? Are they obligated to work with you during a security incident in the way that your plans expect?
As a leader in full-lifecycle incident response solutions, D3 can be the cornerstone of your plans, helping to address all of the elements we’ve covered here. D3 comes with a full inventory of guided and adaptable playbooks built to the NIST standard, and provides tools to support secure collaboration with other teams. D3’s award-winning SOAR (security orchestration, automation, and response) features harness the power of your entire security infrastructure to enhance response playbooks. D3 also offers unmatched flexibility and configurability to adapt your plans to changing threats and requirements.
Schedule a demo with one of our incident response experts to see the platform in action.
