All tabletop exercises
Cloud·Advanced·Technical audience
Your CI deploy role is being assumed from a repository you do not own
The prompt — read this to the room
Your platform team moved CI to keyless federated identity last quarter: pipelines exchange a signed token for a short-lived cloud deploy role. Tonight the SOC sees that role assumed 31 times in two hours. The token claims name a repository under an organisation you have never heard of. The trust policy, it turns out, checks the identity provider but not which organisation the token comes from. Using the role, someone has created two new identities, read your secrets store and changed a load balancer rule in production. Nothing has failed yet. Where do you cut, and what do you trust after?
Total duration
2 h 30 min
People to involve
6
Best fit
Saas, Finance
Who to involve
Most important first.
- Incident response lead
- Cloud engineer
- Developer / DevOps
- SOC analyst
- CISO / Head of security
- CIO / CTO
What it tests
- Contain abuse of a federated workload identity without halting every legitimate pipeline.
- Trace attacker actions across identities they created, not just the original role.
- Decide which secrets, workloads and network rules must be treated as compromised and rotated.
- Fix the trust-policy flaw and test that the fix actually rejects foreign tokens.
Outline of activities
- 1Detection: an identity used from outside your organisation
- 2Containment: tighten trust, freeze the role, preserve evidence
- 3Scoping: follow every identity and secret the attacker touched
- 4Eradication: rotate secrets and rebuild what was altered
- 5Recovery: restore CI with a verified trust policy
- 6Lessons: federated identity review across all clouds and pipelines
Run sheet (Pro)
The facilitator's timeline of execution, the detailed steps for running the session and the questions to ask each person.
Loading…