Both Disaster Recovery (DR) and Security/Compliance are critical aspects of your business, but many fail to see how these strategies relate to each other. For example, many security/compliance standards have requirements that speak to the state of the backups you’re running – i.e. Are they encrypted? How long are they kept?
Beyond this simple example, many of the tools and processes used in one area directly apply to the other, and the best way to achieve your goal – 100% application uptime – is to use them in conjunction with each other.
Let’s take ransomware as another example, one which has been on the rise over the last few years and predicted to continue its rise in 2017. The recent WannaCry attack, impacting over 100 countries, is one such very painful example of ransomware’s capabilities and alarming rise. We won’t recap WannaCry here today, in part because I can almost guarantee that most of the articles covering the attack also focused on common protective measures such as antivirus, intrusion detection, and the importance of regularly updating your OS.
There are alternative mitigation techniques, which take advantage of Disaster Recovery services, that I’d urge you to consider along with these common suggestions:
Regular backups of your data, including the OSIf the ransomware is trying to hold your data hostage, it won’t matter if you have other copies of that data. And all the better if you have the ability to perform bare metal restores as well.
Replication technology with JournalingSome technology used for replicating servers and virtual machines, such as Zerto, has a journaling feature that allows you to fail over to your DR site in a historic state rather than a current one. Similar to using backups, but potentially much less downtime if you have a complete DR solution that is regularly tested.
In both examples above there is one caveat – you have to accept the fact that you’re not using the most absolute recent version of your data, but potentially something hours (or days, or weeks) old in order to failback to a time before the ransomware was installed.
So we’ve seen how DR can be applied to enhance Security – is the converse statement true? Absolutely. While having a DR site and the ability to failover to it is nice, there is always a price to pay. Whether in loss of data (which could be minimal, admittedly) or in the time it takes to complete the failover, which grows in exponential proportion to the complexity of the environment, DR is not likely the whole solution.
Case in point, most companies address DR by considering only potential catastrophes such as natural disasters and by ensuring they only need to failover in an absolute emergency, e.g. a natural disaster at the primary datacenter. But, you know what’s not a natural disaster? Being hacked, that’s what. And though it’s not natural, it can have the same disastrous potential. That’s where Security, applied with DR, provides some good news – if you’re addressing both as part of your Cloud DR strategy, you’re covering as many bases as you can.
To sum up, both categories of service should go hand in hand, and significant investments in one should lead to similar investments in the other, or else you’re just shifting your risk from one bucket to another one, and hackers don’t care about your buckets. Too often I see companies put artificial limits on their spend based on categories that are meaningless – i.e. “We can spend 10% of revenue on Security, but only 5% on DR”. That’s like choosing whether to leave your front door unlocked or your windows wide open (pardon the pun there). In either case, be prepared to lose some furniture.