One of the hottest topics at last week’s RSA Conference was GDPR. Over twenty sessions covered GDPR from various angles and many more touched upon the subject in some way. This was hardly surprising – with the May 25th compliance deadline looming, companies are frantically trying to understand the implications, their responsibilities and actions they need to take.
Let’s be clear though, GDPR is not about cybersecurity, it’s about protecting personal data and data owner rights. Of course, cybersecurity plays an important role in keeping this information safe from attacks and theft. And the regulation mandates that data must be processed with security safeguards in place. However, it is deliberately vague. In the entire 99 articles of the document, the only specific security approach mentioned is data pseudonymization (the separation of data from any identifiers that can link it back to a data subject). It uses terms like “appropriate security,” setting out concepts and a framework, not explicit measures.
What is considered personal data?
Exactly what constitutes personal data is still being debated. The official GDPR definition is:
Any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
It’s generally agreed that this should be interpreted broadly to include login IDs, IP and MAC addresses and browsing data. Which is where things get murky. What about security solutions that monitor, collect and transmit information about user and system behavior? To the extent that this telemetry includes personal data, it would be subject to GDPR. Businesses need to look deeply when determining the impact of the regulation on their systems, applications and processes.
One thing is certain - If you have any European data anywhere in your system, whether on-premises or off, GDPR applies to you. Take the example of a U.S. based bank with U.S. citizen account holders now residing in Europe; GDPR applies for those customers. Same with a U.S educational institution processing applications from European students. Or any data processed by an EU located facility – even if the data subject does not live in the EU. This is why Facebook just announced they are moving all accounts from non-EU users that are currently processed by their international headquarters in Ireland to their U.S. headquarters in California.
What Can You Do with Personal Data?
GDPR states that data must be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures.” It’s easy to view GDPR as yet another set of compliance rules, with a list of boxes to check off, but it is much more than that. Its aim is to give people control over their personal data, to ensure it’s not abused in any way, and that it is not treated carelessly.
It’s also easy to get hung on the reporting aspects of GDPR: How to audit, how to store, how to delete, how to ensure you’ve audited, how to ensure you know exactly what to report, how to do so in a timely manner. But GDPR is not really about reporting. It’s not about compliance. It’s about putting the rights of data owners first, in particular their right to data protection. It’s about doing all you can to prevent the loss or misuse of information.
In Case of Breach?
One thing about GDPR is crystal clear – breaches mean big fines. Especially if you cannot demonstrate that you have “technical and organizational measures to ensure a level of security” in place. Organizations must report unauthorized access to personal data within 72 hours of detection. But when does the clock start running? If an incident alert gets lost in the noise of your reporting system, and the attack is only discovered at a later stage, is it reportable from the time of the initial alert? Even if the more lenient view holds, companies still must assess damage and describe planned mitigation measure within that 72-hour window.
With stakes this high, attack prevention becomes critical. If an attack is stopped before it can enter the system, then notification becomes a moot point.
Morphisec and GDPR
Morphisec helps organizations reduce their GDPR risk by preventing breaches and related data loss. It stops attacks at their earliest stages, before they can access any system resources or user info that could be considered personal data. Morphisec itself is GDPR-proof – it does not generate or store any additional private data other than the user login which is encrypted in the repository. It creates no risk to user information as any personal data transmitted is pseudonymized.
Morphisec also can protect other security solutions that themselves may be exposed to attack. Like any application, most major security tools contain vulnerabilities. These can lead to telemetry data leakage or worse until they are patched. Last year, a zero-day dubbed DoubleAgent was discovered that could basically hijack any antivirus or next-gen antivirus to deliver malware. Luckily vendors issued fixes before it could be exploited. That wasn’t the case with the CCleaner hack, where millions of systems were infected before it was discovered. Under GDPR, businesses using these tools as well as solution vendors would be held responsible for any data leaks.
According to Forrester, more than 80 percent of companies affected by GDPR will not comply by the deadline. GDPR does not mandate specific security solutions and security does not make you GDPR compliant. But the right prevention strategy can ease some of the pressure.
.png?width=571&height=160&name=iso27001-(2).png)