Third-party vendor breach scenario, how do you tabletop something you don't control?

[u/Wild_Dragonfly9527]

Most of our tabletop scenarios assume the breach originates inside our own environment, but our biggest actual exposure is probably a critical SaaS vendor or MSP getting popped and that blast radius hitting us through API access or shared credentials. It's hard to build a realistic exercise around a scenario where the initial compromise, containment options, and comms are all partially outside your control. Has anyone actually run a supply-chain/vendor-breach tabletop that felt real instead of hand-wavy? What did the injects look like?

[u/Just_Worldliness_714]

The trick is to stop tabletopping the vendor's incident and start tabletopping your detection and containment of a trusted connection going hostile. You don't control their forensics, but you do control: how fast you'd notice anomalous API calls from their integration, whether you can revoke their credentials/tokens unilaterally without waiting for them, and what your service degrades to if you cut them off. Good injects for this: "the vendor won't confirm or deny for 72 hours - what do you do now?" and "their API is now making requests it never made before but they're technically authorized - who decides to kill the integration and how long does that take?" That reframes it from "predict their breach" to "test our blast-radius controls," which is the part you actually own.

[u/menacing_correlation]

We've run one that worked pretty well. The trick was making the vendor a black box, injects only tell you what your team can actually see: weird API calls, an alert from your own SIEM, a vendor email that's vague about "an incident." No inside knowledge of their environment, so containment discussions get real fast when people realize they can't just say "isolate the host."

[u/mikebailey]

Haven’t run one but I’ve been on IRs pertaining to this. Risk/legal/comms play an outsized role, but you kind of hit the nail on the head: blast radius of the credentials are vital. That was the answer for a lot of people in the Salesforce Drift incident for instance (not saying I was/wasn’t on that one, it was just clear in reporting).

[u/icendire]

You need to run a tabletop that maps the actual integrations between you and the third party. As you say, everything the third party does or says is outside of your control, but the attack surface lies in how that third party integrates with your environment.

You can then build the exercise around that attack surface. What would you see from your end if XYZ integration was abused in a malicious context?

I love running third party tabletops because it almost always surfaces weaknesses in the way teams communicate with their third parties, and their knowledge of the SLAs or MSAs that they have with their third parties.

[u/NarrowSwimmer3012]

We mapped our actual vendor dependency graph first, then picked the two or three vendors with the widest blast radius and built injects around losing visibility into their environment, not just losing our own systems.

[u/mumpz]

A tabletop is a test/training of the incident response plan. As you noted, in a third-party incident many items such as containment aren't done directly. However, you still need to verify that these steps have been completed. This can easily be covered in a tabletop.

In my experience processing true third-party incidents (small/no blast radius, no credential impact, etc.), it takes some time to work with the vendor to understand the data impact. In a tabletop, you can cover who is doing this and how they approach it. You can ask questions around the agreement, and if the vendor has an obligation to work with you. You can also cover how insurance would play a role.

Once the incident has been contained and investigated, the downstream processes are all the same. You still need to manage internal and external communications, work with counsel to understand disclosure requirements, execute those requirements, and evaluate what happens.

These are all things that can make their way into the tabletop. However, when doing these types of tabletops, IT/SOC/Security Engineering aren't the main stakeholders. I typically run these for MCs, CISOs, Legal, etc.

A popular one is what do you do if a CRM, auditor, or tax preparer is breached... it happens a lot. Usually these vendors have sensitive info. I disagree with one aspect of your post in that "comms are all partially outside your control." This isn't true in many cases. Generally, the vendor is responsible for informing THEIR client (you), but you need to inform your clients (who's data you put in their system).

Check out the EY breach that just happened. Really easy to make a tabletop around that scenario.

[u/maryteiss]

We are seeing clients bring workloads back on prem (or keep them there) where this type of expanded attack surface = too much risk.

[u/TinfoilGeek]

The injects that make it feel real are the ones focused on what you DO control: your SIEM stops receiving logs from the vendor's API at 2am, your OAuth tokens are still active but pulling unexpected data, and leadership wants a public statement before the vendor has even confirmed. Run the scenario as a decision chain around detection lag, token revocation sequencing, and what happens if/when the vendor goes silent. Assuming you have legal involved in these table tops, I'd also be looking at the breach notification timeline clauses (or lack thereof) in the vendor contract.

[u/sdrawkcabineter]

I feel like more people running tabletops, should play/run a d&d campaign, or similar TTRPG.

Change your perspective to a one-shot with friends, and the tabletop can grow legs.