Data Breaches: All Your Fault

One part of my job is to understand the compliance landscape. This means that I read a lot about the GDPR and related similar laws. I also have to read a lot about data breaches in order to understand how and where laws like the GDPR apply to them, and how they happened so that I can better prepare people through good DevOps practices to prevent them.

The more I read about data breaches, the more I realize:

It’s You. It’s your fault.

Don’t believe me? Let’s walk through a few recent data breaches together.

Passwords? We Don’t Need Stinking Passwords.

The Collection #1 data that represents 21 million unique email addresses and passwords for a combination of up to more than 700 million, was found by Troy Hunt… on a data store with no password. Granted, this wasn’t a business. It’s actually a hacker collection of previous data breaches, but still.

Fine, let’s talk about a business then. How about 24 million loan records, including bank account information, email, phones, social security numbers and all the rest. Yeah, that was sitting on an Elasticsearch database with no password of any kind. Oh, and the S3 storage was completely open too. Security? Is that still a thing?

How about exposing your entire client list because you left the password off the database (Elasticsearch again, is it hard to add a password to Elasticsearch). How about stacks of resumes (ElasticSearch, again, and MongoDB).

Those are just breaches from this year. If we go back, we can find more and more. Please, put a password on your systems. Speaking of passwords…

Passwords. They’re my only weakness.

According to IdAgent, 63% of all data breaches come from weak or stolen passwords. But hey, don’t believe them. Let’s talk to the Dudley Council who has evidently not had a data breach (but how do they know), but nonetheless is reporting poor security in their systems.

What about getting hacked in your home. Nest is actively encouraging everyone to start using stronger passwords. How about 800,000 people’s blood data?

SQL Injection? I thought you were dead.

We’ve known about SQL Injection and the possibilities it opens up for hacking since 1998. That’s longer than my kids have been alive. Surely, in all that time, we’ve figured out how to deal with SQL Inection, right?

Nope.

How about 1.3 million records breached, from a college no less (can you say FERPA) due to SQL Injection. What about if you’re using Magento (better get that patched)? Are you a gamer? Might want to check your Epic Games account then, because they’ve been hacked through SQL Injection. Toyota has suffered from an attack in Tokyo that came from SQL Injection, not Godzilla.

PATCHES!

And upgrades. You know main stream support for SQL Server 2014 is ending soon right?

This one is actually tough. This blog got hacked a couple of years ago because I wasn’t keeping up with security patches. Yeah, I’m telling you that it’s not just you, it’s me too. It’s us. Patch management is the first line of defense to protect against data breaches, and we’re not doing it.

How do I know (except for my own data breach)?

Remember the Equifax data breach? The information about exactly how everything went down almost two years ago is just now getting now. What do we know? They found the breach AFTER they applied a patch that they had put off for over a year.

What we do now? Game over!

None of this addresses phishing, insider hacks, accidentally losing laptops and all the other things that are going wrong and causing these data breaches.

I get it. It’s probably not you directly. You told the boss that putting the database out without a password was a bad idea. You showed the organization how all the code they were writing was leading to exposure through SQL Injection. You’ve got a password that’s a little stronger than ‘password’ or ‘123456’. What else can you do?

It’s all about education. Sure, pass on the link to this blog or to one of the data breaches listed above. However, you, and your organization, have to do more. My strongest piece of advice? First, do a full blown security assessment as outlined in the GDPR. Next, start implementing smart processes using DevOps as a model.

When you’re ready to do the DevOps, I’ve got another suggestion. You should be talking to Redgate Software. We provide tools geared towards Compliant Database DevOps. My job is to learn how best to help you prevent the horrors I’ve listed above. We have the educational content too. We’re hosting a series of events in the UK and the USA called SQL in the City Summit. I’ll be presenting a session in the London event next week, on April 30th, talking about how to prevent non-production environments from getting production data.

If you want to get a discounted registration for the event, use the code ‘GrantFritchey’ to register.

Let’s fix the things that we can in order to make these types of data breaches a thing of the past.