7 Steps to Create a Data Breach Response Plan

Implementing an incident response plan can be time-consuming, but it is far less expensive than a data breach would be. Data breaches can haunt your organization for years to come, including very pricey lawsuits, loss of trust from previously loyal customers and even employees. When it comes to incident response plans, the benefits of implementing one outweigh the cost.

The Effects of Being Unprepared

Security incidents and data breaches can have very disruptive and devastating effects on an organization. In fact, according to the Ponemon Institute’s annual Cost of a Data Breach Report, the average total cost of a data breach is nearly $3.92 million, with an average of 25,575 records being stolen or compromised. 

Recovering lost data is only part of the equation. Extended downtime can quickly compound costs on an hour-by-hour basis. And more difficult to quantify is regaining lost consumer confidence and damage to an organization's brand, which can take months or years to repair.

Part of the challenge is that modern cyberattack strategies involve new techniques and technologies designed to evade detection. As a result, not only do initial data breaches sometimes go undetected but the average dwell time of a breach – the time a compromise goes undetected while attackers scan your network and exfiltrate data – is sometimes 209 days. And even then, it can take more than a month to conduct a thorough investigation and completely recover affected systems.

Proper preparation, however, can cut costs significantly. The National Institute of Standards and 

Technology has identified several critical steps for managing a cybersecurity event as part of the NIST Cybersecurity Incident Response Process, and this should be part of every organization’s cybersecurity strategy. 

Below are some high-level points to consider when creating a data breach response plan.

Data Breach Response Plans Are Critical for Preparation of Breaches

Preparing for an incident will eliminate confusion and missteps if, in the moment of response, things get overlooked and mistakes are made. This starts by identifying your incident response team, which should include not only technical team members and consultants but also executives, the communications team, members of the legal team, law enforcement, etc. Each of these individuals will have critical insights that need to be incorporated into any preparations.

A chain of command across all team members will also need to be established so that incident responses can be carefully coordinated. Each member of the team should not only know their roles and responsibilities but also the authority they have to make decisions.

In addition to having the right technology in place to of course detect a breach, such as Fortinet’s Intrusion Detection System (IDS), other equipment is needed to respond to an incident, and that needs to be identified beforehand. Much of that equipment will need to reside off-network so that it isn't compromised in the case of a ransomware or similar attack. Likewise, regular backups of data and systems need to be available and stored off-network, and routine system and data recovery drills need to occur so bringing systems back online can be a smooth and seamless process.

To determine which technology will be needed, you also need to understand the kinds of data you have in your environment and how it flows. In addition, you will need to identify any critical business processes and the assets that those processes ride over. Of course, you can’t protect and monitor everything, so focus on what’s important. Most importantly, determine if any of your data falls under any kind of regulation. Organizations subject to regulatory requirements need to ensure that official processes for documenting and reporting a breach are included in their preparations and strategies.

Detection and Analysis of Breaches

One of the biggest challenges organizations face is limited visibility across the distributed network. Not only do security tools and anomaly detection systems need to be in place, but they also need to be able to share information to detect events that would otherwise live under the radar.

This requires integrated security tools and a centralized system for analyzing and correlating data. Where possible, NOC and SOC operations should be tightly integrated so that security systems have a better opportunity to evaluate network data in real-time to detect suspicious behavior.

Your incident response team needs to implement the following seven steps to prepare and develop a data breach response plan:

1. Data: Quickly determine what data and resources have been compromised or stolen and what critical business processes were affected. You will also need to analyze any systems compromised with malicious software to determine its intent and to glean IOCs, logs, and transactions. 
2. Compliance: Review what regulatory requirements need to be addressed. Because of the dwell time for most breaches, all critical data and logs will need to be saved off-line for a minimum of a year.
3. Authorities: Determine whether you need to contact the authorities, including law enforcement and regulatory bodies. This is especially critical for organizations bound by regulatory requirements. GDPR, for example, can exact significant fines for failure to report an incident in a timely manner.
4. Evidence: Preserve evidence in case the incident becomes a legal issue. Law enforcement should have already been included in your preparation and planning, so steps for preserving the crime scene should already be part of your response plan so that any evidence is admissible in a court of law.
5. Quarantine and Redundancy: Because impacted systems will likely need to be quarantined, redundant systems need to be available so that forensic analysis can take place. Quarantine capabilities are important to avoid spread.
6. Trace Attack Chain: Tools need to be in place that enable you to trace an attack path back to its point of entry. This will require determining the malware used and the dwell time of the attack. Once the attack chain and malware have been identified, every device along the attack path will need to be analyzed. Indicators of compromise (IOCs) will need to be used to identify other devices that may have been compromised.
7. Training: Employees, even those outside of IT or security roles, need to be cyber-aware and trained. Rarely do security incidents not affect the broader employee base. In addition, training will help facilitate proper response and could help with preventing incidents. 

Contain, Eradicate, and Recover - Incidents

To prevent the lateral spread of an incident across the network, organizations should already have intent-based segmentation and zero-trust protocols in place. Intent-based segmentation logically separates systems, devices, and data based on business requirements, and is critical in preventing a system-wide incident.

Once malware or other elements of a breach have been detected, care needs to be taken to ensure that they are entirely removed from the network. Tools that modify shared libraries or files, that modify applications or code, or that exploit existing software tools – a technique known as living off the land – can make it especially challenging to identify and remove all elements of an attack. As a result, quick mitigations will need to take place to ensure that the attacker is not able to compromise the system again. This is accomplished by taking the information gleaned from prior steps and immediately addressing issues that led to the breach, such as reconfiguring a device, installing a missing patch, or resetting compromised credentials.

Finally, after an incident has been contained and eradicated, recovery needs to take place using good backups. Recovery teams should be able to bring essential systems back online as soon as possible. IT teams should also be aware that It can be difficult to totally eliminate embedded threats, especially those designed to evade detection, so it is always a good idea to increase security monitoring for several weeks after a breach recovery to ensure the threat is completely removed. 

Post-Incident Handling for Data Breaches and Security Incidents

This is a much longer mitigation process that will reduce the likelihood of an incident from reoccurring. Lessons learned need to be incorporated into security policies, points of compromise need to be repaired, hidden malware needs to be found and removed, and instances of the same weakness in other parts of the network will need to be hardened.

This is also when you may need to not only take a hard look at the security tools and systems that you have in place but people and processes as well. What security elements are missing that could have caught the breach but didn’t? What processes broke down? What skillsets were missing that could have sped up the discovery of a breach or the incident recovery process? This may mean adding additional tools to your security architecture, updating or replacing systems that failed to do their job, and providing additional training for critical security personnel.

Visibility is a critical element of that process. Critical gaps often exist between security devices, and you will need to assess where communications between different systems broke down. An event detected by one device that is not correlated to a related event detected by another, or that fails to trigger a response, can result in a serious incident that can go undetected for months.

Addressing this challenge not only requires consistent security across the distributed network but tools designed to share and correlate threat intelligence in real-time. You will need to assess what you can see and not see, and make changes to expand visibility and improve your network's ability to respond to events automatically.

Finally, lessons learned need to be turned into education for different groups within the organization. If the breach began with a phishing attack, for example, all employees should receive heightened education on preventing future incidents. Likewise, a breach due to a flaw in an internally developed application should trigger security best practices training for your DevOps teams.

Responding to a Future Data Breach Starts Now

Often, this requires a shift in thinking. It can start by assuming that your organization may have already been breached. If that's true, what issues exist in your security architecture right now that prevent you from seeing it? Are your existing solutions able to detect even the most subtle anomalous behaviors? How quickly can your network put two and two together and come up with a response? Do you have data breach response plan and a team in place ready to respond once a breach is detected?

Answering these questions now, combined with regular wargaming, incident response drills, assessments of your current security technology capabilities, and ongoing training will help ensure that you can minimize the impact of your eventual cybersecurity incident.

Expert investigation and recovery from cyberattacks: Learn more about Fortinet’s FortiGuard Incident Response Service.

Learn more about Fortinet’s FortiGuard Labs threat research and intelligence organization and the FortiGuard Security Subscriptions and Services portfolio.