[BreachExchange] Is a Ransomware Attack a Reportable Data Breach?

[Destry Winant]

https://securityboulevard.com/2020/08/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.