How to create a Table Top Exercise for Cyber Incident Responders

After a fair amount of hard work and collaboration with the OpenSSF and numerous proposed and scrapped scenarios, we launched the OSSF WG Vulnerability Disclosures TTX Documentation.

OpenSSF wanted to create, host and run an Incident Response scenario (IR) Table Top Exercise (TTX), in the format of a panellist discussion, held at SOSS Community Day North America, in Seattle. Let’s start with a look behind the scenes at what goes into developing and conducting an effective Incident Response TTX, what worked for us and what didn’t, and how we think these lessons can contribute to anyone else looking to carry out a similar exercise.

What is a tabletop exercise?

A tabletop exercise is a discussion-based exercise that is designed to test an organisation’s incident response plans and procedures. The exercise is conducted in a controlled environment and involves key personnel who are responsible for responding to a cyber incident. The exercise is designed to identify gaps in the organisation’s incident response plans and procedures and to improve the organisation’s ability to respond to a cyber incident.

Typically at a TTX level the policies and process are under scrutiny as a standard, however we wanted to spend time on technical investigation, response and resolution processes and guidance.

With that in mind we facilitated internal collaboration between our penetration testers, security architects, engineers and senior management, discussing and sharing ideas from past experiences, or ‘what if this happened scenarios”. The ultimate goal was to define a scenario that a panel of open source members and security experts can discuss and address real world work problems that SOC engineers, Security Analysts and Penetration testers face.

How to construct meaningful scenarios

Lesson #1; Tighten the scope and agree on it as early as possible.

For those of you who are looking to run a similar exercise, creative freedom is incredibly important and enjoyable, but leaving extremely creative people to their own devices can spark a lot of ideas and disjointed, or misallocated effort. If we had loosely defined each potential scenario and agreed upon the final outcome earlier in our process we would no doubt have saved a fair amount of wasted effort and time.

The scenario we agreed upon was codenamed ‘Andromeda Gales’ and raises the following question: what if somebody contaminated an open source test suite, within a popular tool, utility, or image? No one bothers to perform due-diligence on test suites, right? It’s not the developers’ problem to worry about a test suite, security analysts may or may not even know the purposes of them, and testers write and carry out tests with no security in mind (typically, please don’t hurt me testers/analysts if you’re golden eggs). Hurrah! We’d found our scenario (and apparently some others had the same thought, as we found a few months later with the XZ Utils exploit XZ Utils Exploit Gist).

The next stage was to split out our effort across three tracks to satisfy ourselves with delivering a quality IR TTX on the day:

Technical workstream
Panellist discussion workstream
Collaborate with OpenSSF

The Technical Workstream

The objectives of the technical workstream was to

create an attack flow using Center for Threat Informed Defense (Which can now be found at SOSS Community Day NA 2024 Attack Flow, feel free to import it into the attack-flow tool developed by the Center for Threat Informed Defense.
adorn the attack flow with what we deem to be essential information for IR; Indicators of Compromise and any relevant Data Sources for collecting required events and information.

We decided on leveraging Center for Threat Informed Defense as our attack flow tool and took our ingredients of open source security, an organisation being exploited, and everything and everyone involved within the entire enterprise process that facilitates day to day operations. The biggest factor into all of the following work was the scenario must be realistic, or as close to as possible, as opposed to another far fetched or cheap way out.

As with any attack flow we needed to consider our attack vectors, threat/malicious actor, kill chains and ‘actions on’ once a target resource was exploitable. In our scenario we went with a test suite infected with a backdoor (Command and Control (C2) beacon in our case, think something like Cobalt Strike) by our nefarious Captain Hλ$ħ𝔍Ⱥ¢k (If you’ve read any of Andy’s books you’ll be accustomed to this villain of the digital high seas, shameless plug of Hacking Kubernetes).

Rather than having a high level attack flow we decided to flesh it out in detail, and align each stage to MITRE Tactics, Techniques and Procedures from their ATT&CK Framework, fairly commonplace across any IT Security issue nowadays. This allows consumers of the scenario to divulge information from our scenario, and use accompanying knowledge to plug any gaps from MITRE or other 3rd party sources.

The scenario itself consists of 8 stages, or Tactics in MITRE ATT&CK terminology, which can be found in the earlier link at the vulnerability working group repo.


Stage 1	Initial Compromise and Establish Foothold	Captain Hλ$ħ𝔍Ⱥ¢k being a general nuisance, contaminating a test suite in a well-known open source tool, developing capabilities and the malware itself.
Stage 2	Execution in Build	We decided in our scenario to have the backdoor implanted onto any container image build pipeline that gets ultimately deployed to production. With images in the CICD pipeline being signed at source (and already having the backdoor artefact implanted) we took advantage of inherent trust most organisations place in their pipelines and build processes themselves.
Stage 3	Execution on Target	The beacon/backdoor has been embedded as an artefact, and is consumed as part of build automation. It is now ’live’ within a target environment. We have the normal fun and games here, system and process discovery, creation of fallback channels, obfuscation and masquerading as legitimate processes.
Stage 4	Discovery	Captain Hλ$ħ𝔍Ⱥ¢k aims to use tooling native to the target environment to carry out recon, enumeration and eventually look to privilege escalate to modify various services (if required) and prepare for lateral movementTypically a poking/prodding phase (tends to be noisy), or is specifically aware of target resource they’d like to compromise, and will establish a direct attack-path to retrieve and exfil, as an example.
Stage 5	Lateral Movement and Privilege Escalation	Once persistence has been established and credentials are gained (If required, through priv esc) lateral movement commences, aiming to carry out actions on crown jewels/high value targets.
Stage 6	Collection	Once target resources are exposed the collection stage begins, harvesting valuable information such as creds, PII, sensitive data, IP etc.
Stage 7	Exfiltration	Data has been collected and/or identified. At this point it’s staged for exfiltration and moved externally, or centralised onto a single exfiltration point.
Stage 8	Impact	Data has been previously exfiltrated, now captain Hλ$ħ𝔍Ⱥ¢k decides to carry out all sorts of nuisance, because he can.

Lesson #2; Don’t get too hung up on your scenario being perfectly executable.

It’s fair game to rely upon some form of misconfiguration, a compromise inside a repository, or ultimately the fallback is always ‘just use a 0 day’’. If it’s something you’re fairly new to and looking to carry out internally, as part of a small dev or security team, you can make use of previous exploits or vulnerabilities and break them down into actionable items for your teams to skirmish against. There’s a common response from defensively minded security individuals, typically ‘an attacker couldn’t do that, because we’ve implemented x security measure’, however we should always assume compromise as a standard practice, security countermeasures and defensive measures should never supersede ‘what-ifs’.

Panellist Discussion Workstream

The objective here is to create a play-by-play for the day. We want to create a template that includes how to select panellists and roles (e.g. an open source maintainer, an ‘end user’ (consumer of open source) or contributors such as SOC analysts etc), discussion topics and associated questions, lessons learned and Q&A (here is an example template).

Once our panellist roles had been identified we set out on collaborating in an excel spreadsheet. We set out a number of breakthroughs throughout the scenario itself relevant to an IR TTX, which typically come in the form of ‘An important event has happened and make change the steer of the panellists, or the scenario itself’.

This was a little easier for ourselves, as we were able to reverse engineer our attack flow (as this would typically be the viewpoint an organisation would be exposed to, the latter tactics within MITRE ATT&CK as opposed to instantly identifying a compromised test suite within a pipeline).

Lesson #3; Start with the technical scenario.

For our group it was easiest to start from a technical perspective, and being able to reverse the process, as opposed to coming up with questions for a fictional scenario.

Collaborate with OpenSSF

The objective of this workstream was to collaborate with Dana Wang to align, contribute and review the workstreams, reaching out to potential panellists, organising the day in its entirety and general oversight of the IR TTX.

Many thanks to Dana Wang, and the OpenSSF, for taking the leap and hosting the IR TTX as part of their community day. The recognition that there simply isn’t enough focus or emphasis on Incident Response not only as a process, or policy, but as something that needs to be tried and tested much like anything else was respectable .In the months prior to the event we shared everything from technical expertise, to stakeholder management, policy breakdown and processes surrounding IR, and how we could facilitate it into the TTX for the community day. The vulnerability working group (many thanks to Christopher Robinson aka CRob) provided a home for the TTX, and all its documentation and attack flows for anyone to run through at their own leisure.

We’re extremely grateful for having the opportunity to collaborate with the OpenSSF, and look forward to seeing how the IR space evolves over the coming months/years as hopefully more people in the industry look to its importance akin to wargaming exercises, to be tried, tested and prepared for what they will likely face at some point in time.

How to Run your Own IR TTX

IR exercises are something everyone with a vested interest in security should look to facilitate as part of their security program, dynamically across their organisation. If you want to download the discussed templates or looking for a step by step guide - visit the github repo.

If you’d like assistance, advice, or even passing the reins to facilitate an IR exercise, whether it be a TTX ‘discussion’ based exercise, or a technical exercise to have some realism to prepare for a specific event, ControlPlane can help. Contact us and mention IR/Incident Response.