IT’s goal should be to never pay a ransom as a result of a ransomware attack. To achieve that goal requires prevention, preparation and practice. Unfortunately, practice is the element most overlooked but potentially the most critical.
Why Ransomware Testing is Different
Most organizations have some sort of DR testing strategy but these tests assume a major disaster where the entire data center becomes unavailable. Additionally, most IT professionals have to recover individual files on a daily basis. Ransomware is somewhere in between. The entire data center is not lost but it is necessary to recover more than just a few files. In most cases, thousands of files need to be restored. Ironically, many backup applications are faster at restoring an entire file server than they are at restoring a few thousand files.
Preparing for a ransomware test requires several steps. First and foremost, make sure the test systems are in a sandbox and it is impossible for the ransomware to hop over to a production network. Ideally, the test should be done in a totally separate facility.
The second step is to find a simulator. Eventually nothing beats the real thing, being infected by visiting suspect sites. Google for a list and they will come up. Initially though a simulator is a better and safer way to go. Make sure the strategy can crawl before you make it run. When selecting a simulation program look for something that will actually encrypt files not just scan them.
The test environment should have at least several servers, mostly Windows. A few of those servers should be file servers loaded with as many individual files as your organization has. The best way to simulate production is to replicate data from the primary file servers to the test network. Again, remember to disconnect the test environment from production before the test.
What to Test
There are three aspects of an attack you should test. First, how quickly can IT identify and stop the attack? Counting on users to call up IT screaming for help may not provide as rapid attention as you might think. There are specific applications to detect the attack and several backup applications are adding this capability, which is ideal.
The second aspect to address is how to recover those files that are encrypted. Part of this aspect is to test how frequently the data protection solution can perform backups of the test systems. Ideally you would want to capture data changes every 30 minutes or so. A narrow capture window requires the data protection application have the ability to perform very efficient backups with techniques like change block backup, source side deduplication, or at least incremental forever backups.
Also, understand how you will identify all the impacted files and how you will feed that list of files to the data protection process for recovery. Will you need to manually search and find each file, provide a list of folders or can you automatically create a list?
Also, even if your detection method works and stops the ransomware software before it can impact more than a dozen files, simulate a rapid detection and a slow detection. An important aspect is to measure how much time it will take to restore those files. Some backup applications are better than others at handling a thousand individual restore requests.
Finally test a complete infiltration of a server, a situation where it is faster to recover the entire server instead of just the files. For this test you’re looking to see how well the recovery-in-place capabilities of your data protection solution will work.
The last aspect of the test is to make sure the infection is truly gone. Unlike a full-scale disaster where a restore can be started and you can walk away, the ransomware recovery has to be closely monitored to make sure that infection is not occurring again.
Reviewing the Results
After the test, review the results. To eliminate any temptation to pay the ransom there should be no more than 30 minutes of data loss and it should take less than two hours from the point of infection to have the infection eradicated and put users back to work. These are aggressive goals but with practice and modern software, they are achievable. If the current solution does not meet these requirements, then it’s time to either replace or complement the current data protection solution.