Ransomware has made disaster recovery (DR) way more important than it used to be. It has become so prevalent – and consequently damaging to companies – that I believe not preparing for it is nothing short of professional malpractice. This is especially true because it’s not even that hard, at least not with today’s technology. When you consider that some companies are even suing their own employees for breaches, it should hopefully make you take notice. So please take this blog as a wake-up call, or use it to wake up someone else to the real risks that your company faces from today’s malware attacks. Fix things now before your company suffers irreversible damage.
A little victim blaming
I really hate it when people blame the victim for an attack. There is no such thing as someone “asking for it.” But in the case of IT systems, I feel very differently. While the blame still lies with the attack and no security system is perfect, I do feel an IT professional is responsible to prevent attacks as much as possible. This is why I get frustrated when I hear about companies ignoring basic best practices for protecting their systems and data.
Has no one heard of two-factor authentication? Do companies not understand how much more vulnerable they are to an attack if they are running ancient versions of operating systems – especially ones that are not patched? Do companies not know that their backup systems should be separated from their primary systems? Every one of the attacks in recent memory could have been stopped, or at the very least minimized, by these basic IT best practices.
VFEmail’s Email servers and backup servers were wiped out in such a way that showed the attacker had the privileges to access the servers. Since the attacks were done remotely, they could have been stopped by two-factor authentication. In addition, the same passwords and methods used to attack the main servers were also used to attack and delete data on the backup servers. There was no separation of powers or any kind of air gap – virtual or otherwise. Arizona Beverages was attacked because their systems were running ancient, unpatched versions of Windows. Their backup system was also a complete failure; they are now rebuilding their systems from scratch. And even though I rolled my eyes when I learned that people were still storing data on MySpace, they lost 12 years worth of users’ data because they had no data protection system of any kind.
I’m thinking of you, Office 365
I’ve been engaged in a lot of debates lately, both online and off-line, about why someone would want to backup Office 365. Doesn’t Microsoft back it up for you? Don’t they have built-in data protection functionality?
The first answer is, no. There is no backup of your Office 365 data that you can leverage for the traditional things you use backups for. I would be happy to be proven wrong if you can find the words “backup,” “restore,” or “recovery” anywhere in the Office 365 SLA. Trust me; they aren’t there. And what does take the place of backup (retention policies) would not meet its most basic definition.
Second, the data protection features that Microsoft does have are integrated into the product itself. They are essentially a very fancy recycle bin. They are additional records in the same database that is driving Exchange, SharePoint, and OneDrive. Since when is it a best practice to protect a database by storing additional records in the same database? That might be the worst backup design I’ve ever heard of, and it doesn’t protect against the kind of things that I’m talking about here – specifically ransomware and rogue admins attacking your environment.
One person who I’ve been talking with online doesn’t see the bogeyman that I’m describing. He thinks I’m making up FUD just to sell data protection for Office 365. This isn’t FUD; it’s an acknowledgment that the threat of ransomware gets worse every day, and the ways that attackers try to damage your data grow more sophisticated just as quickly. Just because you can’t think of a scenario where someone can destroy your Office 365 data today doesn’t mean that they can’t think of one tomorrow. As I often like to say, “there are more ways to destroy your data, Horatio, than are dreamt of in your philosophy.” And ignoring basic IT best practices of separating your production and backup copies is a surefire way to get hacked.
This isn’t that hard
Druva has very straightforward mechanisms for protecting against ransomware. If you are using our service, we will actively scan your data for signs of a ransomware attack. While we believe you should use an intrusion detection and prevention system, we become an extra line of defense looking for signs of something that made it through.
Once a ransomware attack has been identified, it can easily be remedied using our service. But while it is being remediated, a copy of any user’s data is available in the cloud. It can be accessed via the web, or any laptop/mobile device running our software.
For servers, we make sure your VMs are completely and frequently protected – as often as once an hour. Backups are immediately sent off-site and stored in the cloud, which means they are separated from whatever may attack your data center. Our system uses completely different protocols and operating systems than what you use in your data center, which means that they are impervious to the things that would attack your data center. Note that unlike Druva, the majority of other backup solutions use the same operating systems and protocols that you use in your primary systems, and their systems are in your data center right next to the systems being attacked.)So, short of cutting a tape and physically disconnecting it from the network, I can’t think of a more secure way to store your backup data than what we do.
Once your VMs are protected in the cloud, we can also perform disaster recovery-as-a-service (DRaaS) for those VMs as well. If your data center is attacked the way some of these other data centers have been, you can simply bring up your data center in an AWS VPC with the push of a single button. It will be up and running within 15 minutes and will be using a backup copy that is at most one hour old. (You can, of course, run an older copy from before a ransomware infection occurred.) Run your data center in the cloud as long as you need to, and then fail back to your data center once you have mitigated the ransomware. (We support automated fail-back and permanent relocation to AWS.)
We do all of the above without requiring the customer to install on-site hardware, or virtual versions of hardware in the cloud. Customers access our service via a web portal, and data is sent to us directly from servers, laptops, and SaaS services, without the customer having to create, pay for, or maintain backup servers of any kind (we do support a local cache of customer data, but this is optional and is not in the critical path for recovery. If a CloudCache device fails, the restore will simply come from the cloud).
Please get ready for ransomware
It’s time to stop joking about those few servers that are running an ancient version of Windows. It’s time to stop accepting that it’s okay your backups are stored on a device that is running the same operating system that is being attacked – and sitting right next to the server that is being attacked. You need to start using basic data protection techniques like the 3-2-1 rule (three copies of your data on two different media, one of which of stored off-site). It’s an old rule, but it’s still around for very good reasons. Prepare for ransomware before you become the next company that someone is writing about.
“You’ve Got Ransomware, Now What?” — Read this checklist and discover what steps you can take to tackle ransomware challenges.
See what you can do to “End Ransomware Threats With Good Backups.”