Practical Tabletops

Introduction

Okay, it's been far too long since I opened this door, but here we go...

During the 2020 Covid-19 lockdown, I published a series of articles here on Threat Modeling. That was fairly well received, so I wanted to revisit what I'd previously written about tabletop exercises. That first dive into tabletops was pretty narrowly focused, so this one replaces it with a deeper and more practical dive. I invite you to join me in this discussion. I also invite questions and comments. Feel free to email or message me if you don't want to comment here on LinkedIn. I'll gladly keep your question confidential if you permit me to publish a response without attribution.

I'm expecting 8 or 9 articles in the series, and I'll publish a full index when the series is finished.

What is a Tabletop?

I've done various forms of tabletop exercises for many years. In my consulting practice, I started getting client requests for them in the mid 2000s. That has grown substantially, and tabletops -- or TTX for short -- are now my most frequently requested consulting service. It's not even close.

It seems a great many people want to conduct a "ransomware tabletop" these days, so they can see how they'd fare in a real ransomware attack. It makes sense, after all, because ransomware is generally outside the scope of other security testing like penetration testing, vulnerability scanning, and so forth. How do you "test" for ransomware? You simulate it in a TTX and see how your team responds.

And that is basically what a TTX is. You simulate a security incident and see how your team responds. You then analyze and critique your efforts and come up with an improvement plan.

I've seen TTXes driven by audit findings, board inputs, etc. There are myriad reasons for doing TTXes. Further, I work with several clients who run TTXes periodically, with different audiences, different purposes, etc. Done well, a TTX can be a fabulous tool at practicing your incident response skills, as well as your decision making, business continuity, and a slew of other related practices.

I've long been a proponent of drilling and practicing using TTXes. Use a TTX to push your team's capabilities. Push them to the breaking point. It's a lot safer to fail in an exercise than in a live incident. Find those breaking points and address them.

But, I'm getting ahead of myself. Let's start with the fundamentals.

What Do You Want To Accomplish?

It's a common scenario for me to get a phone call or email from a prospective TTX customer. Almost without fail, the customer's inquiry will include things like "we had an audit finding", "senior management wants us to", or "we have a regulatory requirement to TTX".

Those are all valid reasons for doing a TTX, but I always ask them what they're aiming to achieve. Explore that a bit, and chances are you can design and execute a TTX that provides real value to your organization.

For example, perhaps you want to expose your senior leadership team to the decision making process around a major and highly impactful security incident. Perhaps you want to assess how well your business continuity and disaster recovery plans will help (or hinder) you during a major incident. Perhaps you want to ensure your incident responders, whether they are full time dedicated incident responders or merely doing incident response operations as one of those "other duties as assigned" responsibilities, are ready for the rigors of handling a serious security incident. (Things like evidence handling, chain of custody, and so forth are often ignored until it's too late to put the whipped cream back into the can, so to speak.)

I could list TTX purposes for a long time.

Think long and hard about what exactly you're trying to accomplish with a TTX. Use that to guide how you design your TTX, whom you invite, and so forth. Trying to build something generic just to "see how we'd do" is a recipe for failure. Oh, it might be amusing, and you might actually learn a few things, but the chances of such a generic TTX producing meaningful results that translate to process improvements are slim.

One thing I always assess during a TTX is the responders' process maturity. We'll revisit this in a lot more detail later in this series of articles, but it is always helpful to take a critical view of a TTX and how each team handled the situation. Planning your TTX properly can ensure you are looking at the right parts of an overall process. Generic, "one size fits all" TTXes simply fail to address that effectively.

In my next article of this series, I'll address how to start your planning, now that you understand and can articulate why you're doing a TTX in the first place. See you then, and again, please email or message me if there are things you'd like me to address in this article series. With or without attribution, I'll do my best to answer your questions here.