You’ve probably read a lot about the EU’s General Data Protection Regulation (GDPR) and the enormous fines organizations could face for violations of the data protection and privacy law, which takes effect today. What you probably haven’t heard enough is how thoroughly the law could change IT security and data management practices, so I’ll go out on a limb here: GDPR could finally be the precipitating factor that changes the way companies think about security and protect our personal information.
First, some background. GDPR addresses data protection and privacy for all individuals within the European Union – and the law also addresses the export of personal data outside the EU. That’s a pretty broad mandate. The primary goal is to have common regulations within the EU for data privacy and to allow EU residents to control their personal data. It replaces the 1995 Data Protection Directive, and is a regulation, not a directive, so countries within the EU do not have to pass any enabling legislation.
The GDPR extends the current EU data protection regulations to all foreign companies processing data of EU residents, and it synchronizes data protection regulations throughout the EU to make it easier for non-European entities to comply with EU regulations.
The law defines personal data as “any information relating to an individual, whether it relates to his or her private, professional or public life. It can be anything from a name, a home address, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer’s IP address.” In short, the law covers just about any and every bit of data for anyone residing in the EU.
Why GDPR matters to everyone outside the EU
Some companies are trying to address GDPR compliance by segregating the data of their EU customers from everything else. Let me edge a little farther out onto that limb: It ain’t gonna work.
Let’s start with a simple fact of international law: EU citizens aren’t covered by EU law when traveling outside the EU. Here are two examples of how the messy nature of global commerce could create problems for companies:
1. An EU citizen travels to the U.S. for a conference and posts personal things on social media. Does that information stay in the U.S., with different laws, or is that data stored in the U.S. and accessed elsewhere? What if the data is cached in the U.S. and migrates back to the EU later and thus has dual residency? Let’s say that EU citizen travels back home and there is a data breach in the U.S. and potentially exposes that person’s data. Proving that the data is no longer cached in the U.S. is going to be a big deal for that company and a huge liability, as that citizen is back in the EU and the data need to be wiped in the U.S. Tracking EU citizens wherever they go and somehow segregating that data could prove so difficult and expensive that total global compliance might be a cheaper – and safer – option.
2. An EU citizen contacts a Japanese company about a new medical device. The citizen is unaware that the sensitive medical questions are being logged as part of a marketing rollout plan for the EU. All details of the exchange are stored on servers in Japan for the EU citizens, but copies are made and moved to the EU to help marketing plans. This happens routinely in large companies trying to market new products. Now a data breach occurs in Japan but all of the data is mirrored to the EU. The same answer may apply here: global compliance may be the best option.
The bottom line is that – given the worldwide nature of business and worldwide travel of people – knowing where your data is and how it is going to be used, it is virtually impossible to have different data policies in different locations. From a cost perspective, it makes the most sense to have a single inclusive policy for the company to follow around the world instead of lots of local polices that will be confusing to those charged with implementing them. A workforce that implements a single policy is much more cost-effective.
These are just two examples, but social media and medical pharmaceutical and device companies that depend so completely on their data are likely going to have to apply GDPR security, or at least most of its critical components, not just to the EU but worldwide as well. Why develop an architecture that only works for one region of the world?
Microsoft acknowledged the problem this week when it announced it would follow GDPR mandates globally for all customers. Expect others to follow.
And on the first day of GDPR compliance, Facebook and Google are already under pressure, with Austrian privacy advocate Max Schrems accusing the two in multi-billion Euro lawsuits of “coercing” users into accepting their privacy policies, as the debate begins over what GDPR compliance means.
GDPR’s likely changes
I think there will be a number of big changes that will impact the hardware and software stack because of GDPR.
Common Criteria
First and foremost, the Common Criteria, known by its acronym CC, will become required for almost all systems. It has been common in the U.S. and other government bodies for at least a decade, but my bet is this certification is going to be required not just for operating systems but for all components of a system. This has broad implications for things like CentOS and Debian, as they are not CC certified. When I say all components, I believe appliances, services, network adaptors and storage will all be required to be CC certified. CC doesn’t solve all security problems and vulnerabilities, but it does address known attacks vectors, and it provides a support framework and critical updates when vulnerabilities are found.
Encryption
Dealing with encryption on a file- and user-level basis is difficult because of the complexity of key management. You have to generate keys, ensure they are safe, and re-key files based on policy. This is all very hard and complex and it is likely that the key manager will need to be CC certified, as it is the attack vector. The most likely scenario in the short term is to have certified data encryption at rest and certified media sanitization. The U.S. National Institute of Standards (NIST) has certifications for both encryption and media sanitization. For encryption, the standard is FIPS-140v2, and detailed requirements for meeting the FIPS-140v2 standard and certified products can be found here. The standard for media sanitization standard is called NIST 800-88. This is not say that everyone is going to use FIPS-140v2 compliant storage, but I believe that encryption at rest with standard encrypted drives is going to become SOP, and just having encrypted storage without some kind of certification will be viewed as a vulnerability.
Security standards for all
GDPR is going to change everything about IT security and data management by standardizing certifications worldwide, if not for the right reason of data privacy, then to reduce liability and stave off attacks from attorneys after a data breach. It is much easier to argue in court that you have followed all the standards of the EU, U.S. and others and have certified hardware and software than to argue that having that certified hardware and software would not have prevented the problem. As we all know, security is about having multiple layers of protection, and GDPR I believe is going to up the requirements for certified products and improve standards and testing for products around the world, as data does not stay in a single place. This will require hackers to up their game, but as I have said before, security is the arms race of our time.
For more on GDPR compliance, see GDPR Enforcement Priorities: What Will Regulators Be Looking For?
Henry Newman has worked in high-performance environments for more than 35 years. The outspoken Mr. Newman initially went to school to become a diplomat, but was firmly told during his first year that he might be better suited for a career that didn’t require diplomatic skills. Diplomacy’s loss was HPC’s gain.
