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.
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.