If your company hasn’t had a data breach, it’s only a matter of time until it happens. Unless you begin to make a big investment in security, have regular audits and penetration testing, and instill a culture that values customer data, breaches are bound to happen. Even companies that value security and want to host your data in
their cloud have issues. With all this in mind, there are a lot of common faults across big data breaches.
1. Using Simple/Default/NULL Passwords
Elasticsearch is a common vector in many data breaches. Elasticsearch is part of a wonderful stack of open-source tools for search and log processing and visualization. However, Elasticsearch also offers the option to disable authentication, or in many data breaches, it’s left to the default value. In general, you should avoid using passwords where possible in your development and deployment (certificates, tokens, and service principals are much better), but you should have a secure password and not a default or NULL value.
2. Public Amazon S3 Buckets
I don’t mean to pick on Amazon Web Services—I think the ubiquity of the use of S3 object-based storage speaks to the success of the platform. However, many security breaches have resulted from customers having left their storage buckets open to the internet. Azure Blob Storage also gives the option of publicly exposing containers to the internet, but it seems to be a far less common breach vector. The best development practice here is to keep your storage locked down and private and grant access as needed using REST-based authentication.
3. Elevated Service Accounts
This is mainly a Windows phenomenon, and I typically observe it with poorly designed independent software vendor (ISV) software packages requesting their software run at the highest permissions, all the way up to and including the all-powerful domain admin role. This means if you have any sort of a breach or malware running on a machine with a domain admin service account, your entire Windows domain is completely and easily taken over by the attacker. You should ensure you minimize the privileges to any given service account, and ideally use managed service accounts (which are scoped to specific machines) where possible, so you can limit the reachable surface area in an attack.
4. Ports Exposed to the Internet
If you want to see the dangers of having services directly exposed to the internet, build a SQL Server in your favorite cloud provider, with port 1433 open to the internet. Immediately, in your error log, you’ll begin to see failed logins from IP addresses all over the world. If you enable the SA account and set a password like “password” (don’t do this on a real server!), your server will be hijacked within an hour, if not sooner. SQL Server isn’t the only software this vulnerable—it’s just highly visible. It’s also important to have a proper DMZ for your resources facing the internet, like your website. This protects your business network from attackers and vectors from internet-facing services.
5. SQL Injection
This is an oldie, but a goodie, and sadly a still current problem. If you don’t understand how SQL injection works, I recommend reading the very topical “
Little Bobby Tables” comic, which explains a sample case. As a point of reference, Bobby Tables is old enough to drink now, which tells you how long this has been a problem. Many web application firewalls can monitor for
SQL injection attacks, but more importantly, you should parametrize your code properly, so you’re not vulnerable to attack.
Data breaches don’t have to happen. These are five common practices I’ve seen across data breaches and are awful. Building a security culture is hard, but the principles of least privileges and network isolation can protect your systems from breach when the inevitable attack hits.
