You probably already have this for your own organization. That’s great!
What I want you to do is create a checklist—whether it is of some of the points I’m laying out, ideas that pop into your head, or concerns that you might think of. And then I want you to compare it to the one you already have for your organization.
If you have other people in your organization reading this, I want everyone to create their own checklist and then compare them when you’re all finished. This is going to eliminate that pesky group thinking.
I guarantee you’ll end up with a much better plan.
When there’s a ransomware event, there are always several steps in the process of cleaning up an incident.
First is preparation.
Do you know how to respond to an event? You should know what tools to use and how to even evaluate (as in make decisions) if you need to continue down a certain path. Make sure you have some assembly of a decision tree laid out so that your team understands how to respond to very common incidents and scenarios. I would highly recommend putting some preparation work together in a tabletop exercise on ransomware recovery. Start with a scenario of an attack and dive deeper into what your response will look like. Having preparation under your belt will make everyone quite a bit more comfortable in dealing with the real thing.
Next is identification.
What I mean here is you’re going to want to determine if an attacker is actually in the environment or if you may have a false alarm. What would it look like if an attacker were in your environment? Define the picture or signature of a hacker. What are the nuanced pieces of someone trying to sit ‘dormant’ in wait on a network? And how can you evaluate for false alarms? Having a plan for identifying network breaches is super critical.
Then, containment.
How will you get the attacker to stay in one spot to make sure they can’t move to other places within your network. You basically will want to lock them down. If you have a managed disaster recovery (MDR) tool you should definitely listen up here. You should still be thinking about strategy, in case the MDR response isn’t what you expected.
Followed by eradication.
This is getting them out of your environment. You’ve got the attacker and they're contained within a small piece of your network. You know what devices that they've impacted, and you're now going to move them out of the environment. I don't like to move computers into a brand-new environment that are completely pristine, so this would be a good time to ask some questions and I suggest you think about the longer-term play with the client.
Last is recovery.
You sit down with them and say, look, is it time for us to make a transition?
Is it time for us to go in and move to our Azure solution? Is it time for us to add new hardware? Ransomware events are really expensive, and it's expensive from an amount of downtime.
It's expensive on the clients, employee morale. It's expensive on your morale.
All of those pieces, is it time to just invest a little bit more, and get you all back on the hardware? So this might be something to consider when you're doing the rebuild process.
Don’t forget to review.
The most important step of them all is review. Reviewing and figuring out what worked and what didn’t so that your team can improve their process the next time this happens.
It's really important that you think about a ransomware event as a series of individual responses.
Just a couple of gotchas that I see often when implementing a recovery strategy. Things that I see people missing that maybe aren't clearly communicated enough.
The first one is user training. This is your biggest defense when it comes to protecting your clients. That's training your clients. Make sure you're training your clients. I'm going to tell you the three areas you should really train them on.
You don't have to train them on how to, like, look at a firewall or looking at event log or anything like that. You need to train them on these. three very simple things to be cautious. First things first. Always be cautious when clicking links. Opening files or sending money to somebody, whatever. Just be very cautious. Make sure that you expect what you're getting in your e-mail.
Communicate to your users to slow down. This is really important.
Attackers are really counting on users being in a hurry, and if you spend a little bit of time communicating to users that they should slow down, that they should spend a little bit more time maybe looking at an e-mail or maybe reviewing or maybe even picking up the phone and calling somebody.
I always say call before you wire.
Most importantly, and I think this is the hardest one for us to communicate, especially because we know that getting help means more tickets for us.
Getting help is this is the most important thing that you can do for your users when it comes to having them prepared for a ransomware event.
Make sure that they feel comfortable picking up the phone and talking to you. If they see something strange, if they click that link, they know immediately to contact the service decks to get some assistance. That's the different pieces that we have when it comes to users and user training.
One of the biggest problems I see within MSPs is teams overlooking parts of their cyber stack. Many over-invest in one layer. Or don’t test or inspect whether certain pieces are working. One of the easiest ways MSPs have checked their stacks is through a cyber stack evaluation.
