Perhaps it’s too melodramatic to claim that the debate over how to define a data breach "rages on" because we haven’t seen bodies flying out of windows yet, but it is a serious question with genuine financial ramifications now that the General Data Protection Regulation (GDPR) and its accompanying fines for mishandling data have arrived to save (and sometimes confuse) the day. The media and splashy headlines don’t help. To the average media outlet, if it involves data and sounds like news, it’s a breach. So before you form a suitably vile opinion of the heritage of the Regulation’s creators, let’s calm down and take a dispassionate look at the GDPR thought process as it went about placing firm rules on a nebulous topic.
Is it a breach, or isn’t it?
If life were so simple as to abide by cut and dried definitions, this article wouldn’t be necessary. But it’s not simple, and it is necessary. While most cybersecurity organizations would likely agree that a data breach involves some act of removing data from or viewing it on a system without permission, there is no all-knowing Data Breach Police Force to impose a definition. The closest we can come is the aforementioned GDPR because this organization has vested in itself the power to levy substantial fines on those who run afoul of the data protection dictates. Since the powers-that-be behind this new regulation currently swing a hefty stick, let’s analyze how they define a personal data breach. First, the big picture view:
“A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed.”
GDPR goes on to clarify that a data breach is a type of security incident but that not all security incidents qualify as a data breach. There are three controlling information security principles at play here, and any single one or combination constitutes a breach. 1. Confidentiality Breach – an unauthorized or accidental disclosure of, or access to, personal data. 2. Availability Breach – accidental or unauthorized loss of access to, or destruction of, personal data. 3. Integrity Breach – an unauthorized or accidental alteration of personal data. The plot thickens. Let’s look at some specific instances in the context of these principles.
Ransomware attack
If you think ransomware is no big deal – how to phrase this politely – you’re odiously wrong. This nasty little malware grows in popularity among hackers each year and can take credit for billions in losses by companies large and small. Ransomware typically gets into a system when an end-user clicks on a link in an email that appears legitimate but instead releases a program that encrypts a victim’s files and requires a ransom payment in order to receive the decryption key. Is this a breach? While the mere intrusion of ransomware uninvited in a system might only be termed a security incident – GDPR tells us the specific incident details matter – the moment personal data is accessed, a few different principles come into play. While the loss of access to data might only be temporary and not allow us to apply the availability principle (presuming you can restore from a backup plan), the “unauthorized access” part of the confidentiality principle could be invoked once again depending on the particular details. For all such incidents, we must look to the precise wording of the definitions. Does it count as a confidentiality breach if an employee clicks on a phishing email link and unleashes ransomware? That might fall under the “accidental access” clause. Then again, it might not.
The scourge of open S3 buckets
If you haven’t heard, the company Amazon is a pretty big deal that has made themselves even bigger in recent years with their cloud storage service. The problem, and it’s a big one, is that incorrectly configured security settings have given rise to an epidemic of data breaches thanks to open, unprotected buckets. Or are they just security incidents? Let’s apply GDPR’s three security principles. The problem is that stumbling across an open S3 bucket might be somewhat equivalent to visiting a random website. The site owner put it there on the open internet with no security in place and the expectation (and hope) that there would be visitors. Obviously, with the recent S3 data breaches, such as those suffered by Verizon, Localblox and GoDaddy, none of these companies intended to make millions of sets of personal data public. But what if a random researcher stumbled upon an open bucket and stopped to take a look? Are they instantly classified as an accidental hacker creating a data breach? We return to the confidentiality principle. You’d have to say our friendly neighborhood researcher was indeed authorized to look in the bucket by virtue of it being left wide open online. Guilt by that standard would make any of us who ever looked at something we didn’t own a criminal. But accidental disclosure or access? There might be something to this part of the principle. Presumably, GoDaddy didn’t intend for their trade secrets and infrastructure information to be made public, and therein lies the breach. Tech experts attribute the rash of S3 issues to bad product design, saying it’s too difficult for the average person to figure out and apply the correct settings that deploy the proper security. Amazon might argue in a theoretical sense that the simple fact the GoDaddy bucket was accessible didn’t constitute a data breach because no damage could occur unless it was copied or taken outside the system. However, GDPR regulators would likely respond that GoDaddy didn’t entrust their trade secrets to the Amazon service with the expectation that the information would be made freely available online.
“But I’m just making copies”
The previous section brings to light another question: is it a breach if you make a copy of the information in a system and remove the copy? By now, you should be getting the idea that the confidentiality principle is a harsh taskmaster, especially in the wording that forbids even accidental disclosure or access. In this case, it would be hard to argue that you made a copy of protected data without accessing it and thus – guilty! Maybe. Obviously, this application of the GDPR standards leaves a lot of room for interpretation by lawyers, courts and GDPR itself.
All the Ways You Collect Data
Let’s take a look at a few ways you might be collecting personal data under the GDPR regulation and not even realize it.
- Do you have an email subscription form? Any information (name, email address, etc.) collected by this means counts.
- How about a comment section? If visitors can leave comments that include their email address, website URLs, names, etc., you have just collected data.
- How much do you trust your web host? Unless you operate a completely self-sufficient server, there’s a good chance you are storing GDPR-covered files with a web hosting company even if you don’t think you’re collecting data via log files your host maintains as a matter of standard procedure that contains the IP address of your visitors.
These questions are tough to answer for many online cloud hosting and cloud storage providers. Companies like Amazon, Google and Microsoft may find themselves in violation of GDPR requirements, but they are large enough to “weather the storm” of financial penalties. Smaller service providers, not so much. Take, for example, Bluehost, an oft-recommended web hosting provider by US and Canadian SMEs based in Salt Lake City, Utah. They illustrate the complex relationship between a web host, client and clients’ sites. While Bluehost is unquestionably GDPR-compliant in collecting, handling and storing client data via a rock solid Privacy Policy, its Data Processing Agreement that covers data uploaded to their servers through a client website is not quite so cut and dry. It’s not unusual for such a host to simply forward GDPR end-user requests to, you guessed it, the site owner. This gets even trickier for SaaS companies, which rely on third-party hosts to keep their business running under the hood. What happens if, say, a SaaS application was to use a hosting service that was not GDPR compliant? Varonis co-founder Yaki Faitelson sheds light on the complexity of such cases in a recent Forbes article:
“[B]oth the SaaS companies and their cloud-hosting services must have contracts as spelled out in the GDPR’s Article 28. These contracts are designed to prevent finger-pointing where, say, the hosting service tells the SaaS they are excluded from liability for a breach and vice versa.”
The Bottom Line
Website owners should make it a top priority to read and understand the GDPR, focusing in particular on what constitutes a data breach and how to report it to customers who have had their data compromised. Pay attention to the 72-hour window because this is the time period you have to report a breach.
About the Author: Sam Bocetta is a freelance journalist specializing in U.S. diplomacy and national security, with emphases on technology trends in cyberwarfare, cyberdefense, and cryptography. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
