Perhaps it is too melodramatic to claim that the debate about how to define a data breach is "raging" because we have not yet seen bodies fly out of windows, but it is a serious issue with real financial implications now that the General Data Protection Regulation (GDPR) and the corresponding fines for incorrect processing of data have arrived to save (and sometimes confuse) the day.
The media and smashing headlines don't help. For the average media output, it is a violation when it comes to data and sounds like news. So before you form an appropriate, dirty opinion on the heritage of the creators of the Regulation, let's calm down and take an unbiased look at the GDPR thought process while it was about setting firm rules on a vague subject.
Is it a violation or not?
If life were so simple that it would adhere to truncated and dried definitions, this article would not be necessary. But it is not easy and it is necessary. Although most cyber security organizations are likely to agree that a data breach is accompanied by the deletion or viewing of data on a system without any permission, there is no omniscient Datalus police force to impose a definition.
The closest GDPR comes closest because it has been empowered to impose significant fines on those who violate data protection rules. Since those in power behind this new regulation are currently slamming a big stick, we can analyze how they define a breach of personal data.
First, the view with the large image:
"A breach of security that leads to accidental or unlawful destruction, loss, alteration, unauthorized disclosure or access to personal information that is transmitted, stored, or otherwise processed."
GDPR goes further to clarify that a data breach is one type of security incident but that Not everything security incidents qualify as a data breach. Three principles for controlling information security play a role here and each individual combination constitutes a violation.
1 Confidentiality Violation – unauthorized or unintentional disclosure of or access to personal data.
2 Availability violation – Accidental or unauthorized loss of access to or destruction of personal data.
3 Integrity violation – an unauthorized or unintended change of personal data.
The plot is getting thicker. Let us look at some specific examples in the context of these principles.
If you think ransomware is not a problem – how can you politely express it – then you are wrong. This annoying little malware is growing in popularity among hackers every year and can set off billions in losses by large and small companies.
Ransomware usually enters a system when an end user clicks on a link in an e-mail that seems legitimate, but instead releases a program that encrypts a victim's files and asks for a ransom to receive the decryption key.
Is this a violation? While the mere intrusion of ransomware into an uninvited system can only be called a security incident – GDPR tells us the specific details of incidents – the moment personal data is opened, a few different principles come into play. Although the loss of access to data may only be temporary and does not allow us to apply the availability principle (assuming you can recover from a backup plan), the "unauthorized access" section of the confidentiality principle may be invoked, depending on of the specific details.
For all such incidents, we must look at the precise wording of the definitions. Does this mean that it is a breach of confidentiality if an employee clicks on a phishing email link and starts ransomware? That could fall under the "accidental access" clause. Again, maybe not.
The scourge of open S3 buckets
If you haven't heard it yet, the Amazon company is a pretty big deal that has made itself even bigger in recent years with their cloud storage service. The problem, and it is a major problem, is that improperly configured security settings have led to an epidemic of data breaches due to open, unprotected buckets. Or are they just security incidents?
Let us apply the three GDPR security principles.
The problem is that tripping over an open S3 bucket is somewhat similar to visiting any website. The site owner put it there on the open internet without security and the expectation (and hope) that there would be visitors. It is clear that with the recent S3 data breaches such as those from Verizon, Localblox and GoDaddy, none of these companies planned to disclose millions of sets of personal information.
But what if a random investigator stumbled upon an open bucket and stopped to take a look? Are they instantly classified as an accidental hacker causing a data breach? We return to the principle of confidentiality. You should say that our friendly neighborhood investigator was indeed allowed to look into the bucket because he remained wide open online. Feelings of guilt according to that standard would make one of us who ever looked at something we didn't have a criminal on.
But accidentally release or access? There may be something about this part of the principle. Presumably, it was not GoDaddy's intention that their trade secrets and infrastructure information be made public and that is where the infringement lies. Tech experts attribute the result of S3 problems to poor product design and say that it is too difficult for the average person to find the right settings that implement the right security.
Amazon could theoretically argue that the simple fact that the GoDaddy bucket was accessible did not constitute a data breach because no damage could occur unless it was copied or taken out of the system. GDPR regulators are likely to reply that GoDaddy has not entrusted their trade secrets to the Amazon service with the expectation that the information would be available online for free.
"But I just make copies"
The previous section reveals another question: is it a violation if you make a copy of the information in a system and delete the copy? In the meantime, you should get the idea that the confidentiality principle is a hard task leader, especially in the formulation that prohibits even unintentional disclosure or access.
In this case, it would be difficult to claim that you made a copy of protected data without having access to it and therefore – guilty! Could be. Naturally, this application of the GDPR standards leaves much room for interpretation by lawyers, courts and GDPR itself.
All the ways in which you collect data
Let us look at a few ways in which you may collect personal data under the GDPR Regulation and not even realize it.
- Do you have an e-mail subscription? All information (name, e-mail address, etc.) collected in this way counts.
- How about a comment section? If visitors can leave comments with their email address, website URL & names, names, etc., you have just collected data.
- How much do you trust your web host? Unless you use a fully self-sufficient server, chances are that you will store GDPR files at a web hosting company, even if you think that you are not collecting any data through log files that your host normally holds that contains the IP address of your visitors.
These questions are difficult to answer for many online cloud hosting and cloud storage providers. Companies such as Amazon, Google and Microsoft may violate the GDPR requirements, but they are large enough to withstand the storm of financial fines. Smaller service providers, not so much.
This becomes even more difficult for SaaS companies that rely on external hosts to keep their company under the hood. What happens if, for example, a SaaS application uses a hosting service? not GDPR compliant. Yoyo Faitelson, co-founder of Varonis, highlights the complexity of such cases in a recent Forbes article:
"(B) whether the SaaS companies and their cloud hosting services must have contracts as set out in Article 28 of the AVG. These contracts are intended to prevent finger pointing where, for example, the hosting service informs the SaaS that they are excluded from liability for breach and vice versa. "
It comes down to
Website owners must 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 compromised their data. Pay attention to the 72-hour window, as this is the time period that you must report a violation.
About the author: Sam Bocetta is a freelance journalist specializing in American diplomacy and national security, with accents on technological trends in cyber warfare, cyber defense and cryptography.
Publisher's note: The opinions expressed in this article about the guest authors are solely those of the author and do not necessarily reflect those of Tripwire, Inc.