Staying Employed—Backup Strategies in the Age of Ransomware
It’s 2020—it’s not a matter of when your organization is going to be subject to an IT attack, it’s a matter of how you deal with it. Despite all the training, and all the anti-virus solutions you put in place, it’s just a matter of time before a well-meaning user gets emailed a copy of SecurityInstruxtions.docx from an official-looking email, and all heck breaks loose on your network. Once ransomware is in your network, the malicious code will attempt to encrypt whatever files it can touch from the computer where the code is executing. Smarter variants will attempt to stop running services to enable encryption of database data and transaction log files.
Let’s Talk About Your Network
You might ask—I thought this post was about backups, Joey? It still is, but hang on, I’m getting there. If your workstation, with your regular user credentials, can access the file share where your backups live, you need to stop reading this post and run screaming to anyone who will listen: you need to rearchitect your network. The concept of network segmentation is critical in limiting the impact of malware attacks. The malware can’t encrypt files it can’t traverse a network path to. This means if you’re running your regular computer with, say, domain admin credentials, you potentially see everything on the network.
What do you do to fix this? There are two major solutions, and one is easier than the other. First: all administrators (network, sys/domain admins, and DBAs) should have a second set of credentials they use for administrative activities. This limits what the malware can do if one of the administrators’ machines is subject to a malware attack. Secondly, the network subnets where your servers are should be nearly inaccessible to the user network. Management access should be performed via RDP through a jump host, secured with multi-factor authentication. Application access should only be through the specific ports which users need to communicate with application server front ends.
This sounds painful, and let’s be honest, good security is hard and a pain. It’s the only good way to limit the scope of what can be accessed from the user network. You should think of the user network as a pit of snakes you want to avoid at all costs. In all seriousness, the best way to think about security is the user network is inherently vulnerable, and probably already breached, so you need to go about protecting everything else.
Now on to Those Backups
Any data that changes in your environment needs to be backed up. Databases, domain controllers, file servers, and configuration tools all need to be backed up. Critical systems should have these backups restored regularly for test purposes (this is a great use case for the cloud, if you’re low on hardware), and most importantly, these backups need to be stored in a second location nearly inaccessible from your network. I saw a tweet the other week saying something to the effect of, “You can’t ransomware a metal case full of backup tapes,” and while I’m not suggesting you move all of your backups to tape (though there are worse ideas) moving them into a loosely connected cloud storage account can provide an additional layer of protection at low cost. (Now just don’t make the account open to the internet). Finally, test those restores (yes, I just told you this three sentences ago).
Your job as an admin is to protect the company’s data. Many of the steps I mentioned require changes in infrastructure and aren’t free to implement—you’ll need to persuade your business as to their importance. But, things like offsite backups and administrative accounts can be quickly implemented and can save your bacon if and when there’s an attack.