Data breaches have been big news lately. Hot on the heels of revelations by major retailers that hackers were able to obtain personal information about their customers, a vulnerability in Open SSL was made public on April 7. The vulnerability, known colloquially as Heartbleed,allowed easy access to sensitive information held by a host of major companies, including customer passwords. The Washington Post has a useful primer on the bug.
We have written before about data breaches and the patchwork of reporting laws governing them – see here and here. But this one is unique, in that (a) it affected so many businesses, and (b) exploitation of the vulnerability evidently leaves behind no trace that information was accessed.
This raises some interesting questions. At least as of today (April 9), nobody has come forward and acknowledged that their servers were actually exploited through Heartbleed. And companies may not know and may never know whether information was taken from them and, if so, what information was taken. So, must they disclose the risk of breach to customers? The way I read Missouri’s notice statute, the answer is “no,” because the duty to disclose arises only after “discovery or notification” of an actual breach. But, California’s data breach law requires notification if personal information is “reasonably believed to have been” acquired by an unauthorized third party, so a different result may obtain there.
The second question: assuming the Heartbleed vulnerability was used to obtain information from a company’s servers, how many “breaches” occurred? In California, for instance, additional requirements are imposed when “a single breach of the security system” mandates that the victim company give notice of the breach to more than 500 California residents. Heartbleed only allowed access to 64 kilobytes of data at a time, but an attacker could connect multiple times or maintain an active TLS connection that requested numerous 64 KB chunks of memory. In these instances, has one breach occurred or multiple breaches? This vulnerability highlights the need for clarity as to what, precisely, constitutes a discreet breach.
The third question: are companies whose data were or may have been stolen subject to liability? My thought is that they probably are not, for a couple of reasons. First, as noted above, exploitation of Heartbleed doesn’t leave a trace. So how would a plaintiff establish whether his or her information was stolen and, more importantly, whether it was stolen from the defendant’s website or some other website? In some instances, this may be clear (e.g., if the plaintiff’s stolen password was unique to the defendant’s website), but in others it may not (e.g. the defendant used the same password on multiple websites). Second, what would the cause of action be? Negligence seems a stretch when this vulnerability affected so many entities – was using Open SSL really a breach of some duty of care? Some data breach laws allow for private causes of action, but, for instance, Missouri’s doesn’t. Even suits against the creators of Open SSL don’t seem especially likely, given that it is an open-source implementation, and subject to an Apache License that disclaims warranties and all manner of liabilities.
Thus, the Heartbleed Paradox: the vulnerability that may have led to extensive data breaches in many companies and across many industries may not trigger any reporting obligations or successful civil suits. That’s not necessarily a bad thing – occurrence of harm need not lead to liability – but we must acknowledge that it is strange that lesser data breaches do lead to reporting obligations and potential liability, while this one may not.