Photo by Markus Winkler on Unsplash
Recently, I have been noodling about the qualitative difference between Ransomware and other forms of cyber attacks.
Ransomware is fundamentally a form of reversible sabotage. When someone encrypts your data, the data is there, it’s just destroyed. When you pay them, the data becomes undestroyed.
If you have a backup that has some of the data that is unencrypted and safe, then the question becomes:
_ How much data will I lose?
_ How much will that affect my business?
_ How long will it take to recover my business given the lost data?
Because the current active data is destroyed, the first step is to determine how much data you still have. To do that, you need to restore your data from a backup.
The problem with doing a restore is that the bad guys will have penetrated several of your systems, and so if you blindly restore a backup, the bad guys will destroy that copy.
So you need to restore the backup in a safe environment.
And so a critical question in any ransomware event is – “What is the last known good backup?”
And once you have that backup, the next question is – “How long will it take to rebuild the information that has been lost?”
Having, once again, entered the enterprise storage space, what I find interesting is how DR planning and preparation doesn’t include DR preparation around “recovery from backup.”
Not from yesterday’s backup but from a backup that is 30, 60, or even 90 days old.
If you routinely wargame that problem, you’ll uncover databases that are not backed up. Yes, I know a huge company that 6 years ago had super critical production databases in a DR configuration but no backup.
But more importantly, when a ransomware event occurs, you can quickly determine whether it’s worth paying the fee.
Testing backup recovery of old backups isn’t a nice-to-have in today’s world; it’s a necessity.
Or, as I like to say it, the IT teams that practice recovery from backup will be the only ones that are currently employed.
As to why I am so invested in this topic, at Zynga, two weeks before our IPO, a game of ours got destroyed because of an operator error.
Thankfully, we were able to recover from backup in less than 12 hours.
That experience taught me to think about backup differently.
And it’s why when I say Single Point of Failure, I think about recovery from backup not a server crashing.
When I talk to IT professionals and technical leaders, this need for backup to work is not understood.
Leave a Reply