How to protect and prevent disasters such as ransomware
Now that we have discussed workload considerations, the 3-2-1 backup principle, and how PeerGFS can help you attain RPO and RTO goals, you may think that PeerGFS is reacting to file-level changes and copying files to the other side. Wouldn’t it also copy a ransomware-infected file too? Other DFS solutions may, but PeerGFS includes Malicious Event Detection, or MED technology as standard.
The MED technology combats ransomware in three different ways. We will refer back to Dennis is the IT Manager from the disaster recovery plan post of this series.
Firstly, it will look for the type of file activity patterns that a ransomware program would typically cause. If detected, it can immediately and automatically halt any file synchronization between the participant locations to prevent it from spreading around Dennis’ organization. It can also send email alerts to Dennis and his administration team to be aware of a potential malware strike that requires attention.
Secondly, PeerGFS can write bait files that act as a honeypot for malware. These are hidden files that the users wouldn’t see, and shouldn’t be touched by anything else. If they are, an alert can be triggered and synchronization can optionally be halted.
Thirdly, on Windows Servers, PeerGFS can establish directory traps, similar to bait files; they are hidden folders that the users wouldn’t see. These folders point back to themselves, so as a ransomware process is trawling through the files and folders looking for the types of files that it wants to attack or encrypt, it will get stuck in the directory trap. The unwanted process is now caught in a loop within that same folder, triggering an alert and buying Dennis and his admins time to investigate. Think of this like a fly getting stuck on flypaper, or as I like to call it, the Hotel California solution; “You can check in any time you like, but you can never leave.”
The MED technology prevents PeerGFS from spreading ransomware-infected files to other servers. Remember, PeerGFS is designed to react to file changes in real-time, so ransomware could spread quickly otherwise. So that is why Dennis’ disaster recovery solution also has the off-site copy, and it’s better than having just another copy of the data at the off-site location.
Using object storage such as Azure Blob, an AWS S3 bucket, or an S3-compatible storage solution at that co-location site in Frankfurt has helped Dennis with data security. Now, Dennis can have a copy of each VERSION of each file stored as a separate object AND stored natively so that there can be none of that nasty vendor lock-in. If Dennis decides to stop using PeerGFS, the files are still accessible in the usual way at each location. There’s no gateway, special file formatting, or vendor-specific technology to prevent Dennis or his users from getting at the data.
Dennis can set controls over how many versions of each file to keep, and for how long, to control the disk space required, and of course, rein in the ongoing cost to the business.
This means that if hit by ransomware, Dennis can easily restore a version of the file or files from a point in time before the ransomware struck. And rather than pay some evil a-hole a bunch of Bitcoin for the decryption key and hope for the best, he can simply overwrite the corrupted files with the last good version.
To summarize, public cloud and hybrid solutions definitely have their place. Certain workload types are perfect for cloud solutions, and some are cheaper and more sensible to keep within your data centers.
Whether public cloud should play a part in your disaster recovery strategy, well, that’s up to you. It can be very effective, but so can keeping an off-site copy in a data center or co-location site. When designing a good disaster recovery plan, which of the following would you choose?