table-top-exerciseHave you ever conducted a tabletop exercise for your disaster recovery plan?

Ransomware. I know it’s something no one wants to experience. And I see so many vulnerable networks after auditing hundreds of MSPs.

While your network’s susceptibility to malicious attackers is something always on my mind, another worrisome piece to the whole ransomware puzzle is how to recover from an event. Nearly every MSP I’ve spoken with has had trouble communicating to me their recovery plan.

They might say they have backups or that their cloud solution handles it, but hardly anyone has actually been able to walk me though steps to validate that they’re doing enough on the recovery side that they actually have disaster recovery handled.  Their plan might have been well-thought (that is when they have one in the first place), but after years of neglect, many are unable to satisfy a critical requirement.

They’ve put off testing their plans (and updating them) though tabletop exercises to make sure they will actually work.

Even when folks simulate an attack or talk about the ‘what if’ scenarios, they aren’t actually testing it live and most often are not revisiting their plans on a regular basis (maybe as your tech stack or team changes) to make sure the plan is still viable.

Today I want to walk through setting up and executing a tabletop exercise that will test your plan.

First, what is a tabletop exercise?

Your tabletop exercise should be a way to further test and facilitate discussion around concrete plans that will manage and mitigate any sort of disaster—ransomware to Mother Nature and beyond. You are probably thinking the main test will be to evaluate your business continuity and disaster recovery plans.

Most often, your team will help define a couple of scenarios most likely to occur and test (in theory) the efficacy of your plans step by step.

What you should take away from your tabletop exercise is insights into how well your plan will likely perform in a real-life scenario and identify weaknesses to correct before an event actually develops.

What happens in a tabletop exercise?

Your tabletop exercise should be a discussion-based session where your team informally meets to discuss their roles during an emergency. You will have a facilitator that takes ownership of guiding participants through resolving issues from various scenarios.

If you already have a response plan in place, one of these exercises might only eat up a couple of hours—simply validating that your current approach is effectively addressing all issues coming up in the incident and figuring out any ways to improve.

Essentially, most tabletop exercises should follow this type of schema:

  • Set goals
  • Select functions or plans to be tested
  • Choose participants from each department
  • Establish ground rules
  • Develop a disaster scenario, related to your local environment
  • Confirm assumptions involving available resources, such as phone, internet and staffing
  • Conduct the exercise
  • Determine whether the exercise is tied to any key vendors
  • Document and discuss the results

After you’re done with an exercise, evaluate whether your goals and objectives were met and receive any feedback to improve the meeting.

I go through running a security tabletop exercise in detail in our SecOps call this week.

If you’re interested in actually improving your disaster response plan, here are a few things you should consider:

Identify your stakeholders—who will be involved in the event? Consider who core members of your crisis team are. I would think of the main processes for your business and make sure to include each of the process owners (they all will be involved at some level in the recovery). Also note that different scenarios will likely require different stakeholders, so when you are planning out your event, make sure to identify what parts of your company and what expertise you will need on hand to help participate.

Understand what you will talk about—inviting a whole bunch of people to the meeting is one thing, but providing them with a sound business justification for why they’d want to think about imaginary hackers is an entirely different beast. Until you’ve communicated your WHY, you might not have buy-in from leaders on your team as to why they should be spending (or in their minds, wasting) their time on the exercise.

Identify your business impact—when running through each scenario, understand what mission-critical applications or data will be impacted by the event? Will you be able to operate (at least getting the mission-critical stuff done)? What would your output look like? Review the impact by major department within your company and focus on where the problems will arise from that scenario.

Execute your tabletop exercise—begin mapping the malware attack (or other disaster), along with its damage. As you move through the attack, you will probably uncover steps and details you will have to act on. Make sure to ask questions like: will it be feasible to restore? Can we restore from backup at this point? Who will get notified? When to inform the leadership team?