Practical Tabletops - Part 4

Technical Audience

In the last article, I spotlighted issues for those preparing tabletop exercises (TTX) for leadership audiences. Well, let's turn the attention now to a more technical audience.

Perhaps the most important guidance I can provide is to remember -- and to ensure your audience realizes -- this is not a penetration test. It isn't and shouldn't be the goal to find novel ways at compromising your target IT environment. Even if you have a deep knowledge of that IT environment, you'll invariably get caught in the tarpit of "well, actually...". That is to say that someone in your audience will find even the smallest technical implausibility in your scenario and the session will devolve into pandemonium. This is not where you want to be, trust me.

Instead, find a balance that works for you and your audience. Yes, it should be technical, and it should be plausible, but you should rigorously seek to avoid that kind of "debate". (It's never a debate...)

What I do to avoid that is I make extensive use of topical threat intelligence information. I take a great deal of time to follow what's going on in the IT security world, and I generally come up with plausible scenarios that are "ripped from the headlines," with a twist.

What do you mean, "with a twist"? I'm glad you asked. As an IT security practitioner, I read with great attention and detail all the information I can sponge up about new vulnerabilities, attack tools, and threat techniques. I look especially for "game changers". Things that aren't just the latest buffer overrun or cross-site script du jour. And then I look to see how that issue could be applied to my target environment for any given TTX.

For example, when "Moxie Marlinspike" published details about how he was able to compromise the Cellebrite forensic tool by tricking it into ingesting some carefully constructed data on an iPhone (in his Signal app), I was greatly interested. In a recent TTX, I made use of that concept and devised a scenario in which the client's security monitoring tool, itself an acclaimed and respected product, was compromised by way of a data poisoning attack.

In that example, there was a true 0-day vulnerability in the security monitoring product. The vulnerability had not yet been discovered by the product vendor, so they were called upon to fix the vulnerability. That, in and of itself, proved to be excellent fodder for the TTX because I told the participants once they notified the product vendor of the vulnerability, that the vendor reported it would take them 1-2 weeks to produce a patch. So now the TTX participants were stuck with deciding how to proceed in the meantime. They had to devise a plan to isolate and contain the problem while still conducting operations -- for which they relied heavily on the vulnerable product.

You can see how this course of action prevented any "well, actually..." debates, and yet it was entirely plausible. To use the Cellebrite concept on another product made the scenario realistic despite it being a fabrication.

So, keep up on your threat intelligence and look for the kind of scenario I've described here.

The Devil is in the Details

Another consideration when running a TTX for a technical group is to press them on specific details in their simulated response process.

For example, if the TTX participants declare they'll re-image all the affected systems in your scenario, press for details. How long will it take per system? How much will it cost? How many people will you need to accomplish this on "all the systems" you've proposed to re-image? What will the business impact be?

Having spent many hours at the pointy end of that stick, I know they're going to be hard pressed to realistically answer many of those questions. And yet, they are serious business questions that deserve an answer! Don't let them off the hook easily. Suggest they build a simple spreadsheet to determine the answers in the aggregate.

Other detail oriented questions to ask include:

• Course of action. What course of action is the incident response team recommending in response to the TTX scenario? How did they decide on that? Are there alternative approaches worth considering? Who is the decision authority?
• Tracking of actions. Who is responsible for the various actions discussed (inevitably) during the TTX? Are those actions being tracked? By whom? Show me.
• Reporting status. What has been reported of the incident and to whom? How about senior management? If there are regulatory actions that are required, like breach reporting laws, who is handling them?
• Interfacing with vendors. Who is communicating with affected product vendors and other pertinent external entities? If the parent organization has, for example, a cybersecurity insurance provider and the TTX reflects a ransomware attack, has the insurance provider been notified? Are they requiring their own people be brought in to handle the clean-up?
• Evidence handling. In a major incident, it's usually the case that the IRT will need to handle any information they gather as though it may be required in court some day. Are they proceeding under that assumption? Are they taking steps to ensure the chain of custody for every piece of information is unbroken?
• Communication and coordination. Overall, what steps are being taken to effectively coordinate and communicate the actions being taken by the IRT?

This sounds like a lot of details to track. It is. A mature IRT will be doing these things as a matter of course. What you're trying to ascertain here is the overall process maturity of the TTX participants. Pay close attention and keep good notes during the TTX itself.

I'll elaborate on these things in another article.

As always, I invite your questions and comments. Please comment here or drop me a DM or email. And, if you find these articles helpful, please share them with others who might benefit.