As DevOps or Development, there are vital points in the deployment of any software tool that pertain to both cyber security and privacy. Privacy law states that security safeguards need to be in place, and that the “current state of technology” will come into play. This means that the public expectation of security measures and the current state of what is seen as “normal” or “minimum requirement” needs to be taken into consideration. With that in mind, I’m listing 7 of the deadly sins that I see most frequently in production environments, both at small startups and within larger enterprise.
The fact of the matter is that dev is often rushed, deployment is stressful, and we are stuck repeating mistakes that are, in some cases, 20 years old. I recently had two panel discussions where this topic came up over and over, so herewith my 7 deadly sins of DevOps (or development)
Allowing SSH and RDP from the public web
This has to be one of the cardinal sins, and I see it so frequently. RDP or SSH open to the public web with no protection but the hope that strong passwords are in use. Brute force is very real, and neither protocol in its default state has enough protection or notification if someone is hitting it hard. RDP has had a number of vulnerabilities over the years (and recently), and SSH, while very secure, is not much more than a simple password in its default state. At the very least, you need to restrict access to these protocols by means of an IP restriction, but for a better approach you’ll want to have multiple layers of protection in place like tokens, certificate authentication, or locked down IPSec / SSH tunnels to access them.
For those that have the pockets for it, there are plenty of fantastic proprietary Identity and Access Management (IAM) tools out there for zero-trust models, and if you’re using Azure or AWS, there are far more modern ways to get onto these servers that make use of multi-factor authentication.
Placing databases on front-end servers
Front-end servers, as their name implies, are at the front of your network, and in theory would be the first to be compromised. Generally, a compromised application server where only static content is kept is not as big a deal as a database server where sensitive information is kept. If you combine the two onto a single server, you are allowing someone who’s just breached the edge of a network to get hold of the most sensitive information. You should have your databases completely separate from your application and web servers.
Leaving SQL ports open
Again with the ports! The reason this is a separate listing to SSH and RDP is that ODBC connections directly to SQL is certainly insecure by default. I’ve seen rich client applications connecting directly to MySQL over the web, and I’ve seen Microsoft SQL open to the web so that technicians can easily access SQL management studio. There is a fine line between convenience and security risk, and this is not something you should be taking a chance with. The only thing that should have direct SQL access is your application, and that should have its own security in place too.
To make matters worse, many different database servers do not encrypt connections by default, so you are then also wide open to man-in-the-middle attacks or someone snooping on a connection in a coffee shop. Stop opening these ports and start using secure connection methods!
Ignoring firewalls between tiers
In the SQL port example, I mentioned that only your application should be able to access SQL. On the surface, and at a basic level this is easy to do, but to take things up a notch security wise, you want to actually have firewalls between your tiers of servers. With this in place, you can effectively restrict which application servers have access to which database servers, and even take it to the level that only an application server can initiate a connection to the database server.
Part of what may happen in a hacking attack is that the attacker will try and traverse the network and map it out. Say you have an environment where you have an edge firewall on your hosted cloud, an IPSec tunnel from headoffice to the cloud, and a VPN connection to headoffice. If headoffice gets compromised, an attacker would be able to traverse the IPSec tunnel and effectively initiate connections from backend services to the frontend. This is something you want to restrict. In practice, your database server should never be initiating a connection to an application server, so why not put a firewall in place that only allows initiation of connections from the application server’s side? It’s not going to protect you entirely in terms of an inside attack, but it does go a way to ensuring more security!
Encryption of backups
So often I see that companies have taken a ton of security measures on live data, but completely ignore backups. Your backups contain all the data of a live production database, not encrypting them is effectively painting a target on an Achilles heel. When an attacker attacks, they are likely to scope out your backups before targeting your production data, because the backups are likely to be less protected. You have to encrypt your backups, and you have to do it from the start. It’s no use encrypting for shipping the backups, but still leaving an unencrypted SQL dump on the local drive that can be exfiltrated.
Not salting your hashes
This is more on the dev side than on the DevOps side, but if you’re going to be storing passwords, MD5 hashing is not the way to do it anymore. It hasn’t been for a while. You have to add a little salt to it. Hashes, while one-way, are easy to regenerate. There are things called “rainbow tables” out there where millions of hashes have been stored in text files. While you can’t unhash something, you can compare the hashes against a known database. On my 4th gen i5 lab computer, I can run about 11 million hashes in 15 minutes. If someone has compromised one of your databases and has the hashed values, they can run a comparison. A salt adds another value to the password before hashing it, thereby changing the hash that would be generated, making a rainbow table fairly useless. If you have different salts per user, you’d have different hashes even for the same password.
Copying production databases to test servers
Finally, much along the same lines as encryption of backups, we have the practice of copying production databases to test servers. I shake my head. Test servers, as their name implies, are for testing, and often the security that is in place on production does not make its way down to testing, or the security that was in place on test was broken by a junior developer 3 months ago and was never revisited. Again, copying your databases back is effectively copying the golden sensitive data to an insecure system – and that’s where the attackers are going to go first. You need to be working on dummy data in test, and STILL pay attention to security. I have a few clients that (thankfully) treat sandbox with the exact same care that they treat production, and it makes me and their CISO’s sleep better at night!
Ross G Saunders Consulting offers a number of solutions that can drive your compliance; from affordable 16 week group coaching programmes to comply on your own, through to advisory retainers and full programme management. To find out more about the offerings available, book time directly with Ross using the calendar below.