Nearly every time I turn around, a company is stating it can prevent ransomware! When I research it further, I see that it is not, in fact, prevention. Rather, it is recovery. These companies all make the same assumption: that ransomware can be detected long before it becomes a major problem. This is false reasoning. Ransomware is not detected until a person cannot open a file, or a system reboots and the screen shows a lovely ransomware message. How soon after ransomware hits does this detection take place? Moments, days, or months? Whether you can detect ransomware early enough depends on your practices, policies, and capabilities, not on storage or data protection that claims to prevent ransomware. What does it take to prevent, or even detect, ransomware?
That is the crucial question. How can you detect ransomware before it becomes a problem? But first, how could it become a problem?
Ransomware as a Problem
Many storage tools take snapshots or replicate data between sites, including the cloud. During replication, they may have multiple snapshots or retention policies. I.e., you may just keep the last seven copies of the data somewhere within the storage or data protection network. All software-defined storage can set retention policies. They either use storage snapshots or other mechanisms. Whichever mechanisms are used, eventually the older saved elements roll off. You have until all unencrypted elements roll away to detected ransomware. What if you miss that window, for whatever reason? You are sunk. I just hope you are comfortable with your backup procedures and keep many more recover points than hot replicas.
Anti-Ransomware: A Solution
Actually, there are myriad possible solutions for detecting ransomware long before it becomes an issue. I assume detection rates would be in moments, not days, weeks, or months.
In the above figure, we have three different subsystems in play to detect ransomware: one within the data protection realm, one within the storage realm, and one using canary files and shares. Any one of these could detect ransomware as it happens. By using all three, you can detect even the most intelligent ransomware. Let us look at all three options.
Canaries
Files: Canary files are well-formed files with known contents. These files should look attractive to ransomware, so they should have proper names and juicy contents, perhaps apparent accounting or personnel data. All of it should be false and unique to the organization. There is no reason to let anyone know what that data is, exactly. We then use tools to continually check the data and perhaps update it regularly so it does not look static. We are looking for any changes. A detected change, specifically the inability to decipher the contents, should trigger a ransomware red flag.
Shares: Canary shares are shares that are not normally used or even seen and that contain, once more, attractive files. If such a share is touched in any way, shape, or form, it should immediately trigger a ransomware red flag.
It is possible to do a number of things when canary files or shares are changed or touched:
- Log off the user
- Quarantine the desktop/server
- Mark a previous recover point within the data protection suite as potentially uninfected; those after it need investigation
- Redirect the user to a captured and deceptive environment
- Ban the user
The goal of using a canary file or share is to detect ransomware as soon as it hits.
Data Rate of Change
The last two items are the same within data protection and storage. Each contain the ability to report on data rates of change, but in different ways.
Storage Snapshots: Comparing current and past snapshots allows one to detect the copy-on-write rate of change. If there is a significantly larger amount of change, then the snapshot may be significantly larger than a past one. This could indicate ransomware in use.
Replication Rates of Change: As storage volumes replicate between one location and another, many techniques are used to limit the data transferred. If ransomware has infected a volume, then there will be an increase in the data rate of change.
Data Protection Rates of Change: As data protection backup or replication occurs, many techniques are used to limit the data transferred. If ransomware has infected what is being protected, then there will be an increase in the data rate of change.
If there is a rate of change detection, the previous recovery point, snapshot, or replica should be marked as not to be deleted. The recovery point, snapshot, or replica should be retained until the incident is resolved. Going even further, the retained recovery point, snapshot, or replica could be replicated to a quarantine area.
Closing Thoughts
By combining canary shares or files with data rate of change detection, we can remove false positives from ransomware detection and develop an anti-ransomware policy and procedure. There are a number of false positives to which we need to attend. One is the legitimate use of encryption on new files or volumes of storage. If we are properly encrypting data in a database, only rates of change detection will trigger. If we combine with a canary approach, we have a way to eliminate such false positives.
However, the bad actors continue to create ransomware that is more intelligent. As technologists, we need to work to make our detection harder to defeat.
If we can detect ransomware faster, then any solution that helps by keeping multiple copies of data will be more effective.