In-Depth

The Data Breach Game: The 9 Worst IT Security Practices

How many of these data security offenses is your organization guilty of, and how can you correct them? Play the Data Breach Game and find out.

• By Joey D'Antoni
• 10/09/2019

As news of yet another data breach breaks this week, I thought it would be fun to make a game out of the various ways data gets breached.

I even decided to get fancy and made a pretty graphic; you can enlarge it below or print out the .PDF version so you can play at home, since the ransomware your CEO downloaded to his iPad has locked your company out of its office badging system.

Let's walk through each of these vulnerabilities. Some of these are more real-world than others, but they are all terrible practices.

1. Credential Reuse
Do you have one service account for all of your production servers? Or worse -- I saw this at a client once -- do you have linked servers between all of your database servers, and have those accounts logging in as the system admin?

To take this a step further, in your personal life, do you reuse passwords across Web sites? It's not good to do that, even at sites that don't impact your finances. Those small sites are the most likely to get breached, and then the password you used at your favorite cat-grooming message board and your bank is now out there on the dark Web.

Get a password manager and create a unique password for every site you log into. I use 1Password, but there are other good password managers out there. Your passwords should look like this:

wzFKFwVc(XrMpiquEfq/2=nNWJViE63j3Q;t6  

Not like this:

Tigers0$

2. Service Accounts Are Domain Admin
Did you have issues getting your SQL Server Failover Cluster Instance to create a computer object that your domain admin "fixed" by elevating the permissions of the service account to domain admin? (Note: Hire a new domain admin if this happened.)

Congratulations! Now everyone who has system admin rights on that SQL Server is effectively a member of the domain admin group.

Microsoft publishes a handy document listing all of the permissions that SQL Server needs to run properly -- and you should use it.

3. Port 1433 Open to the Internet
This was less of a problem in the pre-cloud world, but between cloud virtual machines having the option of public IP addresses and the easy ability to open ports, it's somewhat more prevalent now.

In case you don't know why this is a bad idea, here's a log from SQL Server that had port 1433 open:

You'll note that I have a bunch of failed log-ins for the system admin user. This is because there are bots running on the Internet looking for open SQL Servers and trying to log in as the system admin. (SQL Server versions all the way up to, and including, early releases of SQL Server 2000 allowed blank system admin passwords. You can still create SQL Server accounts with blank passwords, but if you're reading this and you do it, I'm going to call your boss.)

This one is easy to fix. Segment your network properly -- this means not giving a public IP address to your database servers -- and don't open port 1433 to the Internet.

4. Spear-Phishing
As always, be careful what you click on, especially in e-mail. E-mail is one of our biggest productivity tools, but it's also the biggest security vulnerability in any organization.

To be helpful, use a managed e-mail service like Office 365 or commercial Gmail and multifactor authentication (MFA). Bonus points if you don't use text messages for MFA.

Finally, make sure that your network is segmented in a way that your CEO opening an e-mail can't infect your domain controllers or database servers.

5. Public Amazon S3 Bucket
You'll note that a lot of these vulnerabilities entail putting sensitive data in public places. Think of this like putting all of your valuable jewelry in a bucket on the street in front of your house, except you're doing this on the Internet.

Here's the screenshot for how not to do this on the Amazon Web Services (AWS) cloud, but you also have this option on Microsoft Azure:

There's no reason to ever make these cloud storage buckets public. Your Web site can connect to private blob stores without making those stores public.

6. Public MongoDB with No Password
If you do a search for "MongoDB no password public," you'll find a lot of breaches; here's a link to just one of them.

The solution to this problem is easy: Put a strong password on your database and don't expose it to the Internet. This isn't hard.

7. SMB 1.0
Is your shop partying like it's 2003? Do you still run Windows XP and have domain controllers running Windows Server 2003? If so, then there is a bunch of malware waiting to attack you. 

Modern versions of Windows Server need just a couple of mouse clicks to disable SMB 1.0. Even on older versions, it is a minor registry change.

Solutions to this problem may be challenging outside of your Windows Server environment, because the vendors on this long list provided by Microsoft don't care enough about your security to update their products.

8. Private Keys in Public GitHub Repositories
GitHub and continuous integration and continuous deployment (CICD) have changed the way we deploy software. It has also made it very easy for open source projects to share and integrate code with other committers and contributors.

Unfortunately, people aren't always careful with their code and leave in things like hard-coded passwords, cloud keys, IP addresses and hostnames, and SSH keys in their public repositories. You shouldn't store any of this stuff in your code; you should use a tool like Azure Key Vault or Vault from HashiCorp for secrets management. You should also use .gitignore templates that exclude common private .JET files that your organization uses, and scan for them in your CICD process.

People have already solved these problems, and you should use the tools they've built.

9. SQL Injection Attack
If you don't understand SQL injection, this very famous Web comic called "Little Bobby Tables" explains it very clearly. SQL injection happens when the code you are passing to a database is not parametrized properly, in conjunction with having too many database permissions.

SQL Server expert Denny Cherry does a good job of explaining how to prevent it here. If you are using Azure SQL Database, Microsoft can also monitor your database for potential SQL injection attacks.

I Got B-I-N. What Are the Fabulous Prizes?
Congratulations! You have been hacked, and probably got hit with some ransomware.

This is a good test to see if you can restore your backups. (You have been doing test restores of your backups and storing them offsite, right?) If so, you should be able to get your business back to where it was a couple of days ago.

Oh, and as for the prize, it's a large General Data Protection Regulation (GPDR) fine. I hope you saved some euros from that European vacation!