Six-phase tabletop · groups of four
What participants should learn
The incident begins with weak identity controls, but the useful discussion is about what a valid identity can cause through data, tools, cloud roles and connected services.
Follow authority
Trace merchant identity into application authorization, agent tools, AWS roles and external OAuth grants.
Place the data
Separate model context, application data, workspace files, logs and connected-service content.
Bound the agent
Reason about combined actions, not just whether each individual tool is legitimate.
Prove recovery
Turn containment into testable queries and explicit conditions for restoring service.
Participant screen
Story context → system path → evidence
Every phase begins with a short, plain-language situation update: why the team has been called and what they need to establish next. It deliberately withholds the cause, technical conclusion and impact. A highlighted system path then connects the situation to the evidence. Each evidence tab defines what kind of system is being viewed, describes the activity and gives a small “look for” prompt without supplying the conclusion.
Facilitator screen
The same story can fill the room
In facilitator mode, a newly unlocked phase opens the story fullscreen for narration. Replay it at any time from ↺ Story in the sticky top bar or Replay fullscreen in the banner. The content is identical and does not create another game step.
Preparation · no extra round
Four organisational teams in the room
Teams choose four representatives once and leave two organisational groups out. Do not explain where a representative helps. Any participant may record decisions; these are recognisable incident stakeholders, not abstract security capabilities.
The live board reveals only encountered People, Data, Evidence and Authority markers. It is not a score and it never changes the shared phase timing.
Facilitator key
Hidden team reveals
- Phase 1 — Security Operations
- Phase 2 — Product Engineering
- Phase 3 — Platform / SRE
- Phase 4 — Communications & PR
- Phase 5 — Identity & Cloud Security
ML & Data Operations has no dedicated reveal after the customer-data phase was removed, but can still contribute to evidence and containment discussions. After each decision, the UI keeps the relevant team contribution or capability gap visible.
One shared operating picture
Four questions responders keep updating
| View | Question it answers | Examples in this incident |
|---|---|---|
| People | Who is affected, who must respond, and who needs support or communication? | Compromised merchant, phishing recipients and Communications & PR ownership. |
| Data | What information was accessed, exposed, moved, retained or put at risk? | Nikto output, phishing assets, shadow-file access and a captured credential submission. |
| Evidence | What records support the incident story, and what remains uncertain? | Authentication and application audit, CloudTrail, CloudWatch, DNS, flow, GuardDuty and Drive records. |
| Authority | Which identity, permission, grant or earlier decision allowed each action? | Merchant session, task and node roles, Drive OAuth grant, public folder permission and cached queue authorization. |
Keep claims bounded: one observation can update several lanes. Reading /etc/shadow concerns Data, Evidence and Authority. A merchant report changes People and provides evidence of public impact. Record what is known, what is inferred and what remains missing.
Facilitation map
One learning moment per phase
1
A campaign breaks the baseline
What happened: Cognito accepted a valid password from a new device and country. The same session then created an unusual number of assets containing account-verification language. None of those events proves compromise alone; their combination justifies investigation.
Engineering lens: authentication, transaction authorization and detection are different controls. A software team should emit stable merchant, session, device and campaign identifiers so identity and product events can be joined. An AI engineer should treat generated intent and bulk generation volume as application telemetry, not rely on the model to identify abuse.
Business lens: challenging every new login creates merchant friction, while doing nothing lets one stolen password use trusted brand and publishing features. The decision is which actions are valuable enough to require step-up authentication.
Ask: Which signal could be innocent on its own? What does the combination justify, and what does it still not prove?
2
Customer data enters the workspace
What happened: the merchant selects a legitimate audience and the audience service calculates 184 merchant-scoped matches. The model receives only a general description—customers inactive for 30 days—and an approximate count, which can shape the copy without identifying recipients. The preview job nevertheless reuses campaign_bundle_v2, whose default inputs include an audience-member export. The audience service creates the CSV and the workspace broker stages it automatically.
Engineering lens: asset creation and recipient selection are separate operations. Actual recipients are only needed when an approved campaign is sent. Every individual authorization returned ALLOW, but the chain only checked account state, tenant match, template input and staging permission. It did not carry the preview purpose through to a rule asking whether member-level data was necessary. Define separate, allowlisted input contracts for preview and delivery jobs, and propagate purpose as an authorization attribute.
Business lens: unnecessary customer-level data increases privacy, contractual, notification and merchant-trust exposure. The Drive connection existed, but content_loaded=false and its earlier last-access time do not align with this run; the application audit identifies the internal services involved in the CSV path.
Ask: At which authorization hop could the preview purpose have stopped a member export? Which service should own that decision, and what should be logged?
3
When a URL becomes a tool
What happened: a merchant-controlled GitHub Raw URL is downloaded and executed with Python. GitHub is legitimate; the unsafe property is the application composing retrieval and process execution without verifying the object or asking for approval.
Engineering lens: the model can propose actions but should not be the authorization boundary. Policy needs to evaluate the complete chain, bind approval to exact arguments and prevent untrusted bytes becoming executable. The technical outcome is remote execution of attacker-selected code in the workspace.
Business lens: a campaign-creation feature has become general-purpose compute. That expands abuse, cost, legal and brand risk far beyond the product promise merchants believe they bought.
Ask: Which component owns the decision to turn retrieved bytes into a process, and what exact event would it deny?
4
The five-minute workspace
What happened: the root-running ECS task installs Nikto and nmap, scans itself, reads /etc/shadow, contacts suspicious domains and reaches IMDS. It uploads the Nikto result and site archive to Drive, then makes the folder readable to anyone with its link. The local disk disappears, but the public SaaS state remains.
Engineering lens: separate the task role, execution role, orchestrator role and EC2 node role. Run as non-root, remove package managers and unnecessary capabilities, isolate IMDS, constrain egress and export runtime evidence before task deletion. Treat connector sharing as a high-impact operation: default to private, restrict allowed permission types and log the actor, file, inherited permissions and link state. Root was supplied at startup; the evidence does not show a lower-privileged process gaining additional privilege.
Business lens: the blast radius now includes public exposure in a merchant-owned SaaS account. Revoking the application session does not retract an already-public Drive link, and the scan may reveal details useful for further attacks.
Ask: Which event proves persistence, which proves public exposure, and which controls must contain each one?
5
Public fallout
What happened: artifacts restored from Drive are served through LocalTunnel. A second merchant submits an email address and password. The page writes that submission into the public Drive folder, and an anonymous link user downloads the file. The production frontend itself has not been modified.
Engineering lens: correlate the HTTP submission ID with the Drive object creation, inherited folder permission and anonymous download. The POST proves collection; the upload proves storage; the anonymous download proves external retrieval. Prevent sensitive form handling in preview infrastructure, prohibit public sharing by default and alert on public-permission changes or anonymous reads.
Business lens: confirmed credential theft changes merchant care, privacy/legal assessment and public wording. Internal Communications needs verified facts, a spokesperson, an affected-user action and a next-update time—not an improvised technical conclusion on Reddit.
Ask: What is confirmed, which people need immediate support, and what can be communicated without overstating wider compromise? Keep containment and recovery choices for Phase 5.
6
The session is gone. The job isn't.
What happened: account suspension stops the interactive merchant session, but a job authorised earlier still starts. Its service role and the independent Google OAuth grant let new work continue after the apparent containment point.
Engineering lens: a user token, refresh token, queued allow decision, STS session and OAuth grant are different authorities. Recheck account and policy state when delayed work executes, make queues cancellable, revoke connectors independently and define validation queries before recovery.
Business lens: restoring too early risks another public incident; pausing globally disrupts legitimate merchant revenue. Recovery needs an owner, a measurable safety gate and an explicit decision about acceptable residual risk.
Ask: Which authorities survived, how is each revoked, and what evidence would justify reopening the service?
AWS concept map
Connect the evidence to the platform
| Scenario evidence | Concept to teach | AWS connection |
|---|---|---|
| User URL → retrieve → process start | Prompt or input controls do not replace deterministic authorization around tools. | Bedrock prompt-injection security ↗ AgentCore runtime security practices ↗ |
| Task role, execution role, orchestrator role and EC2 node role | Different identities exist for application code, ECS infrastructure, orchestration and the host. | IAM roles for Amazon ECS ↗ IAM security best practices ↗ |
RunTask and service-role events | CloudTrail records AWS API activity, not shell commands inside the container. Data events may require explicit configuration. | CloudTrail data events ↗ |
| Application-emitted process and file events | Runtime evidence must be deliberately produced, retained and correlated before ephemeral storage disappears. | CloudWatch Logs Insights ↗ |
| DNS queries, accepted flows and blocked destinations | DNS, connection metadata and application-layer retrieval answer different questions. | Route 53 Resolver query logs ↗ VPC Flow Logs ↗ |
| Phishing-domain finding attributed to the EC2 node | A finding needs resource-to-task-to-merchant correlation before responders know the affected workload. | GuardDuty EC2 finding types ↗ |
| Drive folder changed to anyone-with-link, followed by anonymous download | Connector permissions can create durable public exposure outside AWS. Upload, sharing and retrieval are separate evidence points. | Google Drive sharing permissions ↗ AWS SaaS Lens · identity and access ↗ |
HTTP 200 from 169.254.169.254 | Reachability is evidence of an isolation failure; it is not proof that credentials were returned or used. | ECS task and host metadata ↗ |
| Access token, refresh token, STS credentials, Drive grant and queued authorization | Each authority has an independent lifetime and revocation path. A cached allow decision is not a credential, and temporary credentials can still cause durable harm. | Temporary AWS credentials ↗ IAM access keys ↗ |
Architecture note: Roaming Bites uses a custom application and ECS workspace that invokes an Amazon Bedrock model. It is not presented as a managed Bedrock Agent or AgentCore deployment; those links are useful comparison material for agent-runtime controls.
Evidence discipline
Keep these distinctions visible
- A legitimate GitHub host does not make the retrieved object trusted.
- A DNS request does not prove a response payload or exfiltration.
- A Drive upload proves storage; public permission proves exposure; anonymous download proves retrieval.
- Root inside a container is not automatically root on the EC2 host.
- IMDS reachability does not prove credential use.
- An ephemeral disk does not make actions, external state or harm ephemeral.
Debrief pivots
If discussion stalls
- Ask participants to draw the identity chain beside the data chain.
- Ask who owns each control: product, application, platform, IAM, detection or incident response.
- Ask for one event that would make the next phase easier to investigate.
- Ask whether a control limits one merchant, one workspace or the whole service.
- Ask for a query and a pass/fail recovery condition, not “monitor closely.”
Technical answer sheet
Reveal the meaning after teams commit
Use the separate HTML deck to explain important fields in CloudTrail, GuardDuty, IAM policy, runtime, network, Drive and queued-job evidence. It opens in a new tab and does not alter game state.
Open technical answer deck ↗Recommended placement
Keep it out of the participant path
Prepare it from this guide, then reveal only relevant slides after a phase decision. A second link lives in the facilitator-only debrief. The normal game sidebar deliberately does not expose the answers.
Desired closing insight
The compromised password is the entry point, not the full explanation.
The engineering question is how identity, data, tools and cloud permissions were composed into enough authority to create persistent, public harm.
Open the tabletop