In 2020, planning, preparing, and practicing for a Ransomware Recovery should be job #1.
The Problem with Ransomware Recovery
Predicting that ransomware is going to impact organizations during the coming decade is like predicting that it is going to be hot in August in Texas. It is an obvious conclusion based on current data. What will surprise most IT personnel, however, is how the scope of these attacks will change this year. Modern ransomware is not like the ransomware of 2015. The malware developers are quite sophisticated. Instead of encrypting as many files as possible as quickly as possible, ransomware now sits idle so that the trigger file is backed up by multiple backup jobs. When the malware starts the encryption process, it begins slowly, avoiding detection. In some cases, it starts by encrypting files based on last access date, encrypting the oldest data first, and working its way up to the newest files.
The goal is to encrypt data that users won’t notice right away. In some cases, the malware encrypts 80% or more of the organization’s data before any detection. Another element recently seen in ransomware attacks is that the slow encryption process continues for as long as possible. Once a user, however, opens an encrypted file, the trigger file moves into a rapid attack mode, encrypting as many files as possible before elimination.
I’ve been creating disaster recovery plans since the early 1990’s and have always avoided creating a plan for a specific disaster. Recovering from the loss of access to the data center was all that was necessary. But ransomware is different. First, the data center is not technically “lost.” Second, different backup sets may have different levels of corruption. While most data protection solutions now protect themselves by leveraging immutable (read-only) storage, they can’t help but to backup corrupted files or ransomware trigger files. IT needs a specific plan for ransomware recovery and practice in executing it.
The default response to most disasters is to recover the latest copy of data from the backup repository. The most current copy, however, may contain a high number of corrupted (encrypted) files. Many times, since ransomware is not a site-wide disaster, the organization will choose to recover from a snapshot or use an instant recovery from backup. The problem is these rapid recovery techniques will still recover many encrypted files and may restart the ransomware process, putting the organization in a worse condition than it was before starting the recovery process.
Creating a Ransomware Recovery Plan
No matter the nature of the attack, the first step is to find the trigger file(s) and remove them from the environment. The second step in recovery is to determine which type of attack vector the malware is using. If it is the older, rapidly encrypt everything approach, then recovery from one of the more recent snapshots or instant recovery from the last backup should work. If the attack vector is using a slow trigger and slow encryption rate, then IT needs to determine when the trigger file first breached the network and when it started encrypting data on the network.
IT needs to find files that stagnated for years and then were changed, probably once, within the attack period. In most cases, recovering from a protected copy of data before this date will enable the organization to restore a valid copy of 80% of its data. The problem is that in many cases, this process requires using a backup set that is weeks if not months old. Most organization’s storage systems can’t retain snapshots for that long a period without impacting performance. As a result, the backup software needs to be the source of the recovery.
With the ransomware file removed and the baseline set of data in place, the organization then needs to piece together the remaining 20% of their data. It should be relatively easy for IT to identify files that were encrypted recently, often caused by the rapid attack after the initial detection described above. These files, more than likely, **are** in the current backup or snapshot.
It is the in-between files that are difficult to identify and may be time-consuming to restore. These are files that users created and modified within the time of the attack. Our recommendation is to search for files created within the attack period, and then restore the second to last version of that file, the one before encryption. These three recovery steps, assuming a backup solution with a sophisticated search capability, should recover the majority of the data impacted by the ransomware attack. The remaining files, which should be few, should not be retrieved until specifically requested.
The final step is what to do with the backups that contain encrypted files. In most cases, the attack period tends to be about two to three weeks, but a couple of months are not out of the realm of possibility. What the organization does with the copies it has made during this time mostly depends on its retention policies. Once the organization knows it has recovered all or most of the data, IT should remove all snapshots taken during the attack period. In most cases, for most storage systems, IT will remove all snapshots. IT should also, at a minimum, quarantine all backup copies made during the attack period. If IT can determine that it has recovered all valid copies of data and it won’t violate retention policies, then it should consider completely deleting backup copies made during the attack period.
StorageSwiss Take
Ransomware is proving to be a profitable “business” for its developers. We’ve even seen some ransomware come with technical support on how to buy bitcoin. These bad actors continue to develop more sophisticated ways of holding an organization’s data ransom. IT needs to monitor these changes and adjust their recovery plans accordingly. Certainly, the concept of just restoring the latest backup is no longer an adequate response. Preparation, planning, and practice are vital requirements for a successful recovery from this decade’s iterations of ransomware.
George Crump is the Chief Marketing Officer at VergeIO, the leader in Ultraconverged Infrastructure. Prior to VergeIO he was Chief Product Strategist at StorONE. Before assuming roles with innovative technology vendors, George spent almost 14 years as the founder and lead analyst at Storage Switzerland. In his spare time, he continues to write blogs on Storage Switzerland to educate IT professionals on all aspects of data center storage. He is the primary contributor to Storage Switzerland and is a heavily sought-after public speaker. With over 30 years of experience designing storage solutions for data centers across the US, he has seen the birth of such technologies as RAID, NAS, SAN, Virtualization, Cloud, and Enterprise Flash. Before founding Storage Switzerland, he was CTO at one of the nation's largest storage integrators, where he was in charge of technology testing, integration, and product selection.
StorageSwiss.com - The Home of Storage Switzerland 