Jamie's Blog

Ruby developer. CTO. Swimmer. Always trying to write more

Security Threats Introduced By GDPR

GDPR is supposed to protect the privacy of individuals but it also opens up new security threats which can threaten a company.

I’m not a lawyer, or any sort of GDPR expert, but like lots of people I’m becoming very interested in the GDPR rules as the enforcement date looms.

The following is the result of a short thought experiment:


The first threat is a variation of swatting but instead of heavily-armed militarised police officers kicking down your door, you get a phone call inquiring about your data protection compliance and then your nightmares start.

Ok, let’s back up a bit.

Let’s think about the GDPR rules. What do we know about them? Companies are getting worried about them — and those that aren’t worrying are ignorant of the GDPR. Oh, and everyone is getting really worried about them because the technical implications are not at all clear. Given that, the compliance rate is likely to be abysmal. In fact, I’m debating whether the typical SaaS app can ever be compliant.

But there’s also a good chance that non-compliance will go unnoticed until things going terribly wrong. From what I understand, data protection authorities can’t be patrolling around looking for compliance violations except in for the largest companies in the most high-risk industries. Instead, the data protection authorities will respond to complaints made by individuals.

So assuming that’s the state of the world, you can probably see how GDPR-swatting will work.

First, you target a competitor company that you have a reasonable suspicion is non-compliant with GDPR (basically, everyone). You hand over some personal information by signing up for their app or subscribing to their mailing list.

Then you do something GDPR-ish, like asking for all the information they hold about you. Or maybe asking them to remove all the personal information they hold about you. Or just short-circuit this work and notice that their email provider (MailDripMonkeyKit) is not GDPR compliant.

Hey presto! It’s time to call in the (data protection) cavalry. So you lodge a complaint with your local data protection authority — bonus points if this authority is located in a different country to your competitor as the language barrier will make things more “fun”.

Now, at best, your competitor is going to go through a pretty stressful phone call and maybe several weeks or months of an audit. It’s pretty hard to be competitive when you have a data protection audit distracting you and forcing your to codify those vague GDPR rules into your company processes and tech stack.

At worst, your competitor could be fined 4% of their global revenue or €20m. Something like that. The exact fines don’t really matter as much as they are Scary As Fuck™ to most businesses.

Is GDPR-swatting likely? I don’t know — and this is a thought experiment so likelihood doesn’t really come into it.

I think it would probably be a zero-sum nuclear death match for the likes of Google and Facebook to engage in it. On the other hand, it could be pretty damn effective against your former employer, or a competitor consultant, or a small SaaS that had started to encroach on your market.

All your base belong to us

You’ve probably heard that the GDPR includes the “right to be forgotten”, which allows an individual to tell a company to remove all personal information about them. From their databases, from their mailing list provider, from their analytics, from their log files, from their backu… oh, you didn’t consider backups? Yeah, it seems likely that we’ll have to remove the data from backups too.

At this point my head is exploding because an edited backup is… well it sure as hell isn’t a backup. I don’t know what it is. In fact, in many cases you can’t edit a backup without corrupting it: disk images, tarsnap backups, incremental backups. Even if you could edit a database dump to remove all personal information, can you ever trust that data dump?

One increasingly likely method of complying with the right to be forgotten is simply to delete any backups containing that personal information.

And… this means there’s probably a brief window of time where one or more systems have no complete backup. That sounds like the right time to launch your hack against their system or social engineer your ransomware into their organisation.

The absolute best case is that the company will have been smart about the order in which the deletion occurred (databases first, create a new backup, remove the old ones, etc). But a hack & ransomware is still a holy nightmare and you can still GDPR-swat them.

Potentially they can recover from the attack using a backup they didn’t delete, which does still contain the personal information. In which case, we’re GDPR-swatting.

At worst, the attack happens at a moment when one or more critical systems have no backups. And the attack removes or corrupts the primary source. The company is highly unlikely to survive such a catastrophe.

Is this likely? It seems pretty damn hard to pull off as you need to coordinate several things at once: the GDPR right-to-be-forgotten request, the deletion of backups as a response, and the coup-de-grace of a hack against the primary data source. That said, most successful hacks depend on compromising multiple layers of security and your GDPR response is just another thing to be exploited.

Phished breach

Please send me a copy of all the personal data you hold about me
— I. M. Poster imposter@example.com

In all our panic about the GDPR fines we can be in a rush to ensure we comply with the rules. One area I often see overlooked is support emails.

Should you trust any user that emails you asking for their data back? Oh, hell no! Faking an email address is so easy that it’s not even “hacking”. You also shouldn’t be cancelling accounts either since under the GDPR that would seem to involve irreversibly removing all their data too. That would be a nice way to e.g. destroy your competitors account records or contact list.

If you were to respond to the fake GDPR data request and hand over personal information, well… that’s a GDPR violation and I guess we’re back to GDPR-swatting your company.

Is this likely? It’s happening already — it’s just that the GDPR has added some extra “oh fuck!”-ness to it.

It seems clear that GDPR requests must come through some authenticated channel, ideally from inside the app after confirming their password and ideally a 2FA code. You’re about to hand over the data which you’ve been so worried about protecting. Now is not the time to slack off just because you’re so worried about complying with the GDPR request.

I’m not sure if the GDPR says anything about the lengths you are required (and allowed) to go to when verifying the identify of a request. There’s probably a happy middle ground but companies shouldn’t be so eager to comply, or too fearful of being found obstructive, that they allow a GDPR phishing attack to compromise them.

Final thoughts

Yes, a lot of the words written about the GDPR are scaremongering and/or trying to flog Mr. Conapopalos’ Very Good GDPR Cure. I’m kinda adding to that scaremongering here but I also want people to think about their whole business, and their whole system.

Complying with the GDPR is going to really really difficult and it’s worth spending more that the 15 minutes I had in the shower to come up with your own scenarios.

I oscillate between “GDPR doesn’t change that much” and “a solo freelancer needs a 3-person full-time data compliance team”. I’m sure things will become clearer over time.