Trusted Intermediary Compromise Tabletop¶

Response rehearsal — instantiates Transitive Trust Boundary Hardening

Walks a team through the assumed compromise of a trusted intermediary to rehearse the response — who is notified, what may be bypassed — before a real one forces those decisions under pressure.

Finding the exploitable path is one problem; knowing what to do the day it is exploited is another. Trusted Intermediary Compromise Tabletop is a facilitated, discussion-based exercise that stipulates a trusted intermediary — a software vendor, a managed service provider, a signer, an update mirror — has been compromised, and walks the real responders through the reaction step by step. Its distinctive focus is response readiness, not attack feasibility: it stresses the human and organizational machinery — who decides, who is told, what controls may be bypassed and under whose authority — and surfaces the gaps in that machinery while nothing is actually on fire. No system is touched; the deliverable is a list of places the plan breaks.

Example¶

A mid-size firm runs a tabletop in which its managed service provider — which holds standing remote-admin access across the firm's fleet — is assumed to be compromised, with attacker activity now flowing through that trusted access. Around the table sit IT, security, legal, and communications. Two gaps surface fast. No one is certain whether the firm is contractually or legally obliged to notify its own downstream customers, or on what clock. And the "break-glass" administrative bypass that responders would need to cut the MSP's access turns out to have no logging and no defined approver — the very control they would reach for in the crisis is ungoverned. Both are findings a real incident would have exposed at the worst possible moment. (Third-party-provider compromises are exactly the scenario such exercises exist to rehearse.)

How it works¶

A facilitator selects a trusted intermediary and injects an escalating compromise scenario, revealing new information in stages ("injects") as the discussion proceeds. Participants — the actual people who would respond — talk through detection, decision, containment, and communication using the existing runbooks and authorities, not idealized ones. The facilitator's job is to press on the seams: who has the authority to act, who must be notified and when, what may legitimately be bypassed. Where the plan stalls or contradicts itself, that is the output — captured as gaps, not resolved on the spot.

Tuning parameters¶

Scenario severity and escalation — how bad it gets and how fast. Harsher, faster escalation exposes decision-making under real stress; a milder run builds fluency first.
Participant seniority and breadth — who is in the room. Including decision-makers and legal/comms tests authority and obligations that a purely technical group cannot.
Injects — how much new information is revealed mid-exercise. More injects better mimic a fog-of-war incident but make the session harder to steer.
Fidelity — pure discussion versus partially exercising real tools or notifications. Higher fidelity finds more, at greater setup cost and disruption.

When it helps, and when it misleads¶

Its strength is exercising the half of incident response that technical drills skip — decision rights, notification duties, and bypass governance — cheaply and safely, and doing so before an incident forces those calls in real time.

Its failure mode is that talk is not doing: a tabletop can "go well" and the real response still fail, because discussion smooths over friction that live systems and real clocks would not. It discovers gaps but does not fix them; and it can drift into scripted theatre if participants perform the answers they think are wanted. The classic misuse is running it for a compliance checkbox with no follow-through. The discipline is to log every gap as a tracked, owned action, close them, and re-run against a fresh scenario so the exercise keeps finding new seams.

How it implements the components¶

downstream_notification_obligation — the exercise rehearses exactly who must be told when an upstream compromise propagates — customers, partners, regulators — and on what clock, surfacing obligations that are otherwise discovered too late.
emergency_bypass_governance — by forcing responders to reach for the break-glass path, it tests whether that path is governed, logged, bounded, and owned, rather than an ungoverned back door invoked in panic.

It does not find the exploitable path in the first place — that is Trust Chain Red Team — nor perform the actual key revocation and re-issuance the scenario calls for, which is Key Rotation and Revocation Drill.

Instantiates: Transitive Trust Boundary Hardening — it rehearses the response for when a trusted intermediary turns out to be the attacker's entry point.
Sibling mechanisms: Trust Chain Red Team · Key Rotation and Revocation Drill · Quarantine Release Workflow · Sandboxed Payload Execution · Transparency Log Monitoring · Multi-Source Release Corroboration · Artifact Signature Verification · Provenance Attestation Check · Software Bill of Materials Review · Reproducible Build or Derivation Check · Content Disarm and Reconstruction · Dependency Lockfile and Allowlist · Package Namespace Confusion Guard · Canary Rollout with Kill Switch · Trusted Update Channel Pin

Notes¶

The tabletop produces findings, not fixes. Its entire value is realized downstream: a gap in notification duties or bypass governance is worth surfacing only if it becomes a tracked action that someone closes before the real intermediary compromise arrives. A tabletop whose findings are filed and forgotten has rehearsed nothing.