Table top exercises are a critical part to any incident response program. One of the toughest components to design in a table top is a realistic scenario that generates not only discussion about how incident responders would react, but to generate the right discussion about possibilities that maybe had not been originally considered. Practice of procedures is not the only goal of table tops; finding the holes in your plan around a potential scenario is much more important to making us all better responders.
A great topic to design a scenario around is the after-effect of an exploited vulnerability. Not only does it bring perspective to a wide variety of participants (from technical to management), but the topic keeps the impact of such an exploit top of mind. To get started, I suggest making friends with your vulnerability management team and/or penetration testing team. Grab the latest reports either team has generated and find something that could be realistically exploited. Good targets include legacy systems or applications that are difficult to patch. If nothing sticks out from those reports, perhaps look to your current internal audit reports.
Then check out at the MITRE ATT&CK matrix. What is a potential next step post-exploit of the vulnerability? These pivot options make excellent injects as your table top progresses. Look for areas that haven’t been tackled by your response team lately to ensure that the latest valuable response options are considered.
"Once your vulnerability-based table top is complete, do not forget to wrap up with a Lessons Learned review, preferably before the session ends"
Once you have your main vulnerability and injects, look at your overall audience. Are you exercising with your technical Security Operations Center? Partners within your company such as Legal, HR, IT, Privacy or Communications? Or are you going to work with management? If the answer is all of the above, you will need to carefully craft the language of your scenario to be comprehensible for the audience.
For example, you may want to focus on standard operating procedures (SOPs) used within the SOC. In order to test properly, find out what those SOPs say and purposefully make some of the scenario fit around them, but then perhaps pivot outside of the SOP to see how the teams behave. Are they still applying good critical thinking to arrive at the action plan? Are they asking questions? Are they challenging each other in a positive way to ensure all potential paths are considered and the best chosen?
When you have a more non-technical audience, you will want to ensure that enough technical explanation is included, but not too much to overtake the entire exercise. With this audience, you will want to focus on potential customer communications, bringing in external parties (third party legal or incident response forensics teams), data breach notifications as well as other business decisions.
One critical discussion question posed in your exercise every time you test (no matter how often) is whether a security incident has actually happened. Testing your severity ratings and if they still align with your business’s risk tolerance is much more challenging than you would think. I suggest making this one of the questions asked of the participants at each inject of the scenario.
Once your vulnerability-based table top is complete, donot forget to wrap up with a Lessons Learned review, preferably before the session ends. If too much time lapses between your exercise and the review, valuable improvements to the overall process may be lost.
Happy table topping!