Incident response and disaster recovery are both essential components of a comprehensive written information security program. However, too often these plans are implemented in a vacuum, without considering the potential synergies and improvements that can be gained when such plans are developed, deployed and tested together.
Incident response and disaster recovery tend to have the same goals, i.e., to provide a game plan that outlines how the organization will respond to and recover from an event. The key difference is often the type of events. Incident response tends to focus on events that impact computer systems and personal information, such as malware or network intrusion. On the other hand, disaster recovery tends to focus on larger, enterprise-wide events, such as earthquakes, hurricanes and terrorism. The fallacy is thinking these categories are mutually exclusive. Consider the impact of ransomware, which according to BakerHostetler's 2017 Date Security Incident Response Report, is one of the leading causes of security incidents. A ransomware infection has the same shutdown potential as an earthquake or flood, and the response is sometimes the same, i.e., switch to emergency operation mode, restore from backups, etc. But a disaster recovery plan that doesn't factor in the malicious nature of ransomware may result in critical backups encrypted or deleted by the malware. Similarly, incident response plans that do not consider the far-reaching impact of ransomware may not consider recovery response times, employee messaging and alternative communication methods typically covered in a disaster recovery plan. The solution is to develop both of these plans in tandem.
Consider the following steps to improve your incident response and disaster recovery plans:
- Expand the types of events that factor into your decision-making. Look beyond the natural disasters to include theft, widespread power outages and system failures, including hardware, software and communications.
- Too often, security incidents and breaches are viewed as an IT issue. Incident response teams should be expanded to include members from every department, including marketing, HR and customer service.
- When considering the impact of a security incident, expand its magnitude and view the potential impact on the organization as a whole. For example, the IT department may have detailed discussions on how to restore lost data, but often fail to consider a communication plan with customers or idle employees who are unable to work.
- When analyzing system outages from a security breach, perform time-to-recover calculations. If 100 percent of your data had to be restored from backups, how long would that process take? Does your calculation include the time necessary to wipe, restore, and reconfigure operating systems and applications? If a motivated attacker wanted to cripple your business, what would they do and which systems would they target?
- Evaluate the impact of a security incident or widespread outage affecting your third-party service vendors. Although these incidents are rare, large companies such as Google and Microsoft are not immune to incidents and/or system outages.
Practice, practice and practice! Most organizations perform yearly fire drills and disaster simulations, but sometimes overlook the much more likely possibility of a significant security breach. Incorporate security breach training and preparation throughout the entire organization so that if (or more likely when) an incident occurs, you will be ready.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
We operate a free-to-view policy, asking only that you register in order to read all of our content. Please login or register to view the rest of this article.