Is a Ransomware Attack a Reportable Data Breach?

One question that vexes security engineers, incident responders and lawyers is whether a ransomware attack constitutes a reportable data breach under any of the various data breach disclosure laws, regulations or other requirements. As with anything else in the law, the simple answer is, “it depends.”

Once More Into the Breach (Notification)

Whether there is an obligation to notify about a “breach” often depends on the nature of the information subject to the “breach” and the geographical location of either the entity that suffers the “breach” or of the data subject about whom the data is “breached.” Different laws and regulations apply to different kinds of data. For example, health data in the U.S. (well, some health data, depending on who collects it and why) is protected under HIPAA, which requires notification of most data “breaches.” The regulation defines a breach as “the acquisition, access, use, or disclosure of protected health information … which compromises the security or privacy of the protected health information.”

For other kinds of “personally identifiable information” (defined by statutes), each state has a law that defines what constitutes a “data breach.” For example, California expands on the breach of “personal information” and requires notice of “the breach in the security of the data to any resident of California (1) whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person, or, (2) whose encrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person and the encryption key or security credential was, or is reasonably believed to have been, acquired by an unauthorized person and the agency that owns or licenses the encrypted information has a reasonable belief that the encryption key or security credential could render that personal information readable or usable.”

New York’s statute defines a “breach” as “unauthorized access to or acquisition of, or access to or acquisition without valid authorization, of computerized data that compromises the security, confidentiality, or integrity of private information maintained by a business.” While each state definition may be different the general rule is that something is a “breach” if either the protected data is “accessed” or “obtained” without authorization, or if the event compromises the “privacy” or “security” of the protected information.

Easy Peasy, Lemon Squeezy, Right?

Whether a ransomware attack is a breach depends on the nature of the attack, its methodology and its impact, as well as the statutory definition of the breach involved. If the attacker exfiltrated and encrypted protected data (that was previously unencrypted), then it’s pretty easy. That sounds to me to be a breach. The attacker “stole” (or acquired or accessed) the data.
If they exfiltrated data that was otherwise encrypted and, say, added their own overlay of encryption to it, then whether that is a data breach may depend on the strength and ubiquitous nature of your internal encryption scheme.

If the attacker did not exfiltrate data but merely prevented you from accessing the data, then whether this meets the definition of “breach” may depend on whether the prevention of access in any meaningful way constituted a breach of the security of the data—as opposed to a breach of the security of the system that contained the data. It’s a subtle but meaningful distinction and one that should not be overlooked or overplayed. The problem with ransomware is that either the threat actor directly or the ransomware (software) indirectly has some level of “access” to the target’s computers and computer networks. This may mean that they also have access to data contained on those computers and networks, but it may not. This is why it is critical to understand how the ransomware entered the system, what it did, and often, what it did not do. If a thorough investigation of the methodology and behavior of the ransomware demonstrates that no protected information was “seen” or “accessed” or “compromised” (that is, that the attacker did not and could not have violated the confidentiality of that data), then a good case can be made that a “breach” did not occur, although the “security” of the data (from a denial-of-access point of view) may have been impacted.

We have to keep in mind the purpose of data breach disclosure laws. They are to say to customers, “You know that data that we said we wouldn’t let others see? Yeah, well … we need to talk …” Presumably, the customer can take remedial efforts to prevent harm from the disclosure of that data—new credit card, new PIN, new password, new liver and spleen? If the data has not been “accessed” or “compromised” from a privacy standpoint, it’s not clear that breach disclosure serves any purpose other than that served in “Animal House” when the boys destroy Flounder’s brother’s car, and Otter says, “Face it, you (messed) up … you trusted us.” (And he didn’t say “messed.”)

What You Don’t Know Will Kill You

The real problem comes when a forensic investigation is not feasible or is inconclusive—where there is no evidence that protected data was exfiltrated, but also that there is no evidence that it was not exfiltrated. Remember, at this point, you have some sort of “intrusion” and violation of the security of the system that has impacted the “security” (well, the availability) of the protected data. It’s like coming home and seeing that the windows and locks have been tampered with. Everything inside looks fine, but is it reasonable to assume that nothing was “stolen” or “copied?”

Each circumstance will be different. The more monitoring and forensic you have available, the better you will be able to answer that question. If you find your data floating about and for sale on the Dark Web it’s a pretty good bet that you suffered a breach. If you receive a notification from a processor that you are a “common point of purchase” for fraudulent transactions, it’s also a good bet that there was a breach.

The important thing to note is that an attack—whether DDoS, ransomware or other—is not necessarily a “breach,” but it’s not necessarily not a breach.

Incident Response

It’s called “incident” response and not “breach response” for a reason. A security “incident” may be much broader than a breach, and may involve any actual or potential event which does or could compromise either the confidentiality, availability or integrity of data. Even attempted exploits (unsuccessful) might be considered to be an “incident” or an “event.” While the data breach laws typically don’t require notification of “events” or “incidents,” many data-sharing contracts do. These may include cloud storage contracts, data processing contracts, data transfer contracts or other agreements. So just because a statute doesn’t require “breach” notification of a ransomware event, that doesn’t mean you are off the hook. You need to know what other obligations of disclosure you may be subject to. These may be regulatory, contractual or may be imposed by duties to prevent harm to third parties under tort or negligence law.

Suffice to say, there are no easy answers here. As a general rule, a ransomware attack, such as a DDoS attack, demonstrates a vulnerability in a system but probably (always equivocate) does not result in the exposure of the data. But remember, your mileage may vary.

Featured eBook
The State of Cloud Native Security 2020

The State of Cloud Native Security 2020

The first annual State of Cloud Native Security report examines the practices, tools and technologies innovative companies are using to manage cloud environments and drive cloud native development. Based on a survey of 3,000 cloud architecture, InfoSec and DevOps professionals across five countries, the report surfaces insights from a proprietary set of well-analyzed data. This ... Read More
Palo Alto Networks

Mark Rasch

Mark Rasch is a lawyer and computer security and privacy expert in Bethesda, Maryland. where he helps develop strategy and messaging for the Information Security team. Rasch’s career spans more than 35 years of corporate and government cybersecurity, computer privacy, regulatory compliance, computer forensics and incident response. He is trained as a lawyer and was the Chief Security Evangelist for Verizon Enterprise Solutions (VES). He is recognized author of numerous security- and privacy-related articles. Prior to joining Verizon, he taught courses in cybersecurity, law, policy and technology at various colleges and Universities including the University of Maryland, George Mason University, Georgetown University, and the American University School of law and was active with the American Bar Association’s Privacy and Cybersecurity Committees and the Computers, Freedom and Privacy Conference. Rasch had worked as cyberlaw editor for SecurityCurrent.com, as Chief Privacy Officer for SAIC, and as Director or Managing Director at various information security consulting companies, including CSC, FTI Consulting, Solutionary, Predictive Systems, and Global Integrity Corp. Earlier in his career, Rasch was with the U.S. Department of Justice where he led the department’s efforts to investigate and prosecute cyber and high-technology crime, starting the computer crime unit within the Criminal Division’s Fraud Section, efforts which eventually led to the creation of the Computer Crime and Intellectual Property Section of the Criminal Division. He was responsible for various high-profile computer crime prosecutions, including Kevin Mitnick, Kevin Poulsen and Robert Tappan Morris. Prior to joining Verizon, Mark was a frequent commentator in the media on issues related to information security, appearing on BBC, CBC, Fox News, CNN, NBC News, ABC News, the New York Times, the Wall Street Journal and many other outlets.

mark has 88 posts and counting.See all posts by mark