In general, you’ve prepared for disasters that range from a file server crashing, to a total loss of power, and maybe even a hurricane making your offices inhabitable. You’ve thought through various scenarios that could affect your business and developed plans and procedures to document those efforts. You’ve worked so diligently to develop Disaster Recovery, Business Continuity, and Incident Response plans.

That’s quite a bit of work you put towards protecting your business and its overall operations. Ask yourself this – How many times have you experienced any of the scenarios you planned for?  Maybe a couple of times, but certainly not all of them. Now ask yourself – Do we know how we would react to the most important scenarios, if any of them were to happen?

Oftentimes you develop plans because someone tells you that it is necessary, such as Investors, regulators, and members of your firm. But what good is a plan if employees aren’t familiar with it, or if it is not followed, especially in the time of need. The only way to be certain that your plans will be effective is to test them.

How do you test them? In this article we’ll focus on building an effective Incident Response Plan testing program that will strengthen your ability to respond to the ever-evolving cyber threat landscape.

First and foremost, to develop a concrete testing program you have to understand what an incident is versus an event. As an example, you get many phishing email attempts daily, are all of those email considered incidents? If you didn’t click on a link, or provide your password in a message reply, it most likely qualifies as an event. If your computer isn’t asking you for Bitcoin, nor is your IT team telling you that someone is trying to log in as you from the Netherlands, there is probably minimal to worry about. What if you are sending an email with personally identifiable information to a recipient, but by mistake you type in ‘Jan Doe’ instead of ‘Jane Doe’? Is that an incident or an event? The fact that it contains personally identifiable information, sent to a wrong individual, and you already know due to your extensive knowledge in privacy law that it meets the criteria of a breach, you can safely assume it qualifies as an incident. As we can see, identifying what true incidents are will help in developing a robust plan and tailoring exercises as realistically as possible.

Once you’ve determined what incidents are and you’ve identified the scenarios that are most likely to affect you, you want to compile a list of the people that will be instrumental in the response and recovery process. It is also important to identify the stakeholders that can make authoritative decisions when dealing with an incident. Remember, some of these parties may be external to your firm, such as vendors, regulators, or authorities. There is a belief that incident response is an IT and technical function, but the reality is incident response is a business problem that has to be solved by several parties including a team of business people. Sure, the IT group can be part of that team, but IT doesn’t make up the whole team. Think back to the ‘Jan’ vs ‘Jane’ incident above.

Now that you understand your potential universe of scenarios and built a team that will respond to incidents, you’re ready to test. There are different approaches to testing and some are provided below. Note, we will focus on the Tabletop for the remainder of this article.

  1. Seminar: A seminar is a training exercise where the participants are presented with new or updated plans, policies, or procedures, and example incidents are discussed. These ideas can be used to enhance a firm’s incident response plan. This tends to be less formal
  2. Operations based: An operations-based is a targeted exercise for a select group of people. As an example you may want to test a Public Relation team’s ability to respond to inquiries regarding a breach involving investor information.
  3. Tabletop: A tabletop exercise is a classroom setting where all members of the team responsible for handling incidents are present. A scenario is presented and the team works through the incident according to the plan. The goal is to uncover gaps in the plan, process and/or people

Conducting a Tabletop takes careful planning to make sure each exercise is successful. Following the steps below will help you understand how to run one yourself, or to make sure that one is being run for you in an effective manner.

  • Step 1: Define a goal and exercise objectives. There is no way to measure success if there are no goals or objectives.
  • Step 2: Identify the individuals or firm, if outsourcing, that will coordinate the design and planning efforts of the exercise. The design team should only include those individuals that will not be participants in the exercise.
  • Step 3: Develop the scenario that will be presented to the audience, determine who the participants will be and scope the event. The scenario should be based on your objectives.
    • You may want to use current events to help develop a scenario, if you feel those events are applicable to your firm. You may also choose a specific scenario because the likelihood of an incident happening is higher.
  • Step 4: Develop the exercise based on the scenario selected. Remember, the scenario has to be as realistic as possible so consider using real objects and people as subjects of the exercise. As an example, if your scenario is a malware event, you may want to include the users who are victims of the malware. Ensure you are spreading out your timeline based on how realistic malware events unfold.
    • A successful timeline depends on injects that a facilitator will provide over the course of the exercise. Injects are additional bits (event or circumstances) of information that are provided throughout the exercise. In a real-life situation you never have all the information, so injects are designed to control the flow of the exercise, direct and require responses or actions from participants.
  • Step 5: Assign a facilitator and data collector to run the exercise. The primary goal of the facilitator is to lead the discussion among the exercise participants to reach the goals and objectives. The facilitator’s role is an important one because they are controlling the scenario, providing injects, direction, and asking questions. In addition to those responsibilities, the facilitator will also redirect participants’ focus from the scenario and its contents back to accomplishing the objectives, should they stray from it. The data collector will gather all the actions and important discussion points during the exercise, to be used during the evaluation phase.
  • Step 6: Conduct a debrief, also known as a hotwash, to collect the final thoughts of the exercise. Usually in this step feedback is provided by the participants to the facilitator and data collectors.
  • Step 7: Evaluate the overall exercise to identify any improvements that need to be made to the plan, process, and/or people

If you have any questions about this article, feel free to send us a message.