5 Ways to Protect Your Databases From Ransomware

Ransomware attacks are on the rise—it feels like not a week goes by where you don’t hear about some company or municipality being the victim of a ransomware attack. While these attacks are prevalent, there are some things you can do to protect your database environment. While some of these approaches may be hard to implement by yourself, you can drive behavioral change in your organization.

1. Lock Down the Network—Software firewalls aren’t the end-all or be-all of network security, but they’re better than nothing. The only computers that should be able to connect to your production database servers are application and web servers that need to make a connection. You still need to be able to manage your databases, but you can lock it down by using jump hosts in a secured subnet to perform. This isn’t a replacement to true physical (or virtual) network segmentation, but it’s something you should implement on your database servers without having to run cables.
2. Be Careful with Credentials—One common attack vector is being able to get domain admin credentials out of memory on a user’s workstation and using them to get anywhere within the network. Or worse, having a service running as domain admin. You should have a separate account for administrative tasks, and the user account on your local PC (where you’re most vulnerable to an attack) should be low privileged. Some firms take this to an extreme and have a separate domain just for their servers. Also, you should be careful with the permissions on the service accounts for critical services. Reference vendor documentation and only allocate the privileges the service needs to run.
3. Get your backups offline—My new favorite quote on this topic is “you can’t ransomware a metal case full of backup tapes.” While I’m not suggesting you revert to tape backup (though Azure Archive storage uses tape as a medium), getting those backups to a truly offline or disconnected location is a critical component of security. This can be challenging as you must have connectivity to take your backups. You can consider security options like just-in-time access or short access tokens for the purposes of copying backups to the archive location.
4. Two-Factor All the Things—This ties back into our discussion about credentials, and I know it’s challenging and makes application development significantly more challenging. However, having two-factor authentication can quickly limit the spread of attacks. Users may complain this makes their life harder. It does—that’s the point. Good security is always difficult, which is why it works.
5. Don’t Do Stupid Things—This is a bucket of bad behaviors I see across a lot of major data breaches:
   1. Running old, unpatched, unsupported versions of software
   2. Using Elasticsearch without a password and leaving it open on the internet (it always seems to be Elasticsearch)
   3. Leaving data in a public-facing storage account
   4. Broadly distributing high levels of access like domain or global admin
   5. Having endpoints on the internet connected directly back into your business network

All these behaviors are problematic and are attack vectors for either data loss, or an easy way for an attacker to gain access into your networks. While all these actions can help you survive an attack, by far the most important thing is to ensure your backups are secured and locked down from the network. Everything else helps, but if you get attacked and your backups are gone, you’re dead in the water and potentially out of business.