What is a disaster, anyway?  According to our good friends at Merriam-Webster, a disaster is “a sudden calamitous event bringing great damage, loss, or destruction”.  Ransomware certainly meets that definition.  If bringing a company’s  IT systems and business operations to a screeching halt doesn’t constitute great damage, loss, or destruction I don’t know what does.

Ransomware is a disaster

I’ve been saying the phrase “ransomware is a disaster” for well over a year at this point.  For me the truth of the matter is I hate seeing organizations just fall over their own feet after they’ve been ransomwared.  It isn’t if you get attacked by ransomware these days, it is when.  I’ve been attacked by ransomware in one of my cloud labs!  It was like winning the lottery, and I was recovering my data within 6 minutes.

Now, in the real world, there’s a lot more to ransomware response than logging in, seeing ransomware, deleting the server, and restoring it.  Ransomware response ties in the greater information security incident response plan an organization has.

When it actually comes time to recover those VMs, it should be easy.  You shouldn’t be sweating, you shouldn’t be worrying if it isn’t going to work.

When it comes time to recover, you should be able to just use the disaster recovery plan you have in place today (you have one, right?)

Using a Disaster Recovery Plan for Ransomware Recovery

When it comes time to start recovering those encrypted VMs from backup (you have a backup, right), your disaster recovery plan is a great place to start, with a few caveats.

Disaster recovery plans can be used to recover from ransomware if they are:

• Well documented
• Up to date
• Recently and thoroughly tested

If you’ve got a current DR plan you know works (because you’ve done a real world test), you’re good to go, and I do mean a real world test, not one that is designed to give you a passing score.

If not, well the time is now to get one.

The problem with disaster recovery

The problem with disaster recovery planning is that it takes time.  Creating DR plans takes time, updating them takes time, testing them takes time.

It may even take money!  Besides the salaries of everyone it takes to put these plans together, you may discover you don’t have anywhere to recover to, or your workloads have increased in size and you don’t have the capacity you need at your DR site.

So, who do I know that has extra time and money laying around for disaster recovery when hey, maybe a disaster won’t happen?  We’ve calculated the cost of an outage, and the risk of it happening, and it is cheaper to accept this risk and roll the dice than to actually create a disaster recovery plan.

The sad part is, that is a common strategy that worked, until the rise of cyberattacks and ransomware.

Disasters are no longer statistically ignorable when you operate under the mantra that ransomware is a disaster.

Ready to get scared?  According to the Sophos State of Ransomware 2021 report:

• 37% of respondents were hit by ransomware in the last year
• 1.85 million USD was the average cost of fixing a ransomware attack
• ONLY 65% of encrypted data was restored after the ransom was paid

Start planning now to recover from disaster later

The time is now to start planning to recover from the disaster that is ransomware, before an attack occurs.  That means having a disaster recovery (or ransomware recovery) plan in place for what happens when you’re ready to recover.

It also means that you need to take a good long look at your environment and figure out what you’re missing.

It also means having a solid cyber incident response plan in place, so organizations know what to do when they are attacked before they hit the recover button.

Where do I start?

Ready to start planning?  I’m glad!  Here are a couple things you should think about to get the journey started.

Application identification and analysis

First you need to identify your applications, and what assets make up your application.  Then you need to figure out what happens if they break.  How much downtime can you tolerate (RTO)?  How much data can you lose (RPO)?

This is way harder than it sounds, and is called a business impact analysis.  It needs to be driven by business owners as well as the application owners and IT folks.

If you’ve never done this before, NIST has a BIA template to help guide you through the process.

This may be the hardest part of planning, but you’ll get the hang of RPOs and RTOs in no time at all.

Recovery resource identification

Where are you recovering to?  If you are going to plan for ransomware, is your plan to recover in place?  What if you can’t touch the environment due to law enforcement activities.  Know your options for recovery, and the resources you need for each one.

You’ll need to assess the resources your applications are currently using to get an idea of what you need in order to recover.

(Spoiler alert, I’m working on some ideas about recovering to VMware Cloud solutions – stay tuned for more on that!)

Protect your data

Next, you need to protect your applications.  HOW you protect them may vary based on the RTO and RPO of each application, but back it all up, and make sure you haven’t missed anything.

You may need to tweak things later, but a violated RPO because you weren’t backing up frequently enough is better than an RPO of NOPE.

Create a disaster recovery plan

Create plans based on applications.  For each application, identify each and every asset that needs to be recovered, and what steps need to be taken.  Does any validation need to be done?  How will you check if the application is functioning as expected.

Test your disaster recovery plan

Test recovery of your applications.  Work out the kinks of recovering each app, and make sure you update recovery plan documentation if needed.  Once you have everything working, keep testing.

By the way, the people who write the plan shouldn’t be the ones testing recovery because who knows what they’ll be doing during a disaster.

These plans need to be written so that anyone with basic IT knowledge can pick it up and run with it.

Test recovery of everything

Run a full scale recovery test.  Recover all the things.  This is what you will be doing if you’re facing a ransomware attack.  Identify anything that breaks during recovering at scale.  Do you run out of people?  Do you run out of data center resources?

Don’t forget, ESXi ransomware is a thing now too, so be ready to recover from bare metal all the way up the stack.

Not all recoveries are equal

Another thing to point out is not all recoveries are equal, especially when it comes to ransomware.  You don’t just discover ransomware, and immediately start recovering your virtual machines.

Your ransomware recovery ties into your greater security incident response, and there’s lots of analysis that is done before it is decided how and where to recover to.  Sure, you may want to recover in place and just restore to production, but what if law enforcement is involved and needs to finish their investigation before you can use the environment?

There are many things to consider when it comes to the recovery process, but the main thing to think about is how to make sure you can recover your data at any time, to any place.  If you have a solid data protection strategy in place, your data will remain secure and accessible, even if you end up not meeting your RTO.

Disaster proof your virtual machines

Disaster recovery planning doesn’t have to be hard.  It takes some up front planning, and you may need to change the things you’re doing today to make sure you can recover from ransomware, but it is not the impossible task it is often made out to be.  Be sure to hit me with your favorite disaster recovery questions on Twitter.  You can find me @vMiss33 and be sure to use the hash tag #RansomwareisaDisaster