Fundamental to your ransomware mitigation strategy is backup.
If your plan is to pay your way out of this, consider that not a plan. For one, you have no assurance the threat actor can actually recover your files. Two, you have no assurance the threat actor really will recover your files once you pay.
Backup is a complex science actually, but let’s distill a basic strategy into four digestible pieces.
Your data should be in a minimum of three places. The first version of the data is the working copy on the system it is processed on. The second is a backup to nearline (readily accessible) storage. The third, and critically important version, resides offline and off-site. Because ransomware compromises resources accessible from the infected system, it is well within the realm of possibilities that your nearline storage will be compromised. You have no assurance that it will not be.
When ransomware strikes, disinfect your systems, and then recover the contents of your offline storage.
If choose to improvise on the definitions of “offline” and “off-site”, you will get burned.
RPO (Recovery Point Objective)
You can see how important it is to determine the contents of your offline backup, and the frequency with which you perform that offline backup. This is your RPO – what are we trying to get back to. You need an honest conversation about how much data you can afford to lose, and how much you can afford to invest to bridging that gap. This will be bound by practical limitations, and those are different for everyone.
RTO (Recovery Time Objective)
After you know what you’re backing up, your organization needs consensus on how long it can take to restore that backup in order for the business to continue operations. This is your RTO. Not only does the organization need to know when things will be back to normal, but your RTO will directly impact the kinds of solutions you put in place to resurrect your data. RTO has a lot of moving parts. Effective throughput is more than just the speed with which data is copied back to working systems: it is the amount of time it takes technologists to restore that data to the application in which it lives.
All of these needs to be validated. You can’t pinpoint an RPO until you know you can actually restore files! And you don’t really know your RTO until you actually bring files back to a working state. These are exercises that need to be performed routinely, learned from, and performed again. Data recovery needs to be a well-oiled machine that, when required, is a second nature activity – one the entire organization has a comfort level with.