Tabletop Scenario: Data Exfiltration¶
A SnowOps incident-response tabletop (
K5) — discussion-based, no real consoles. Facilitation method:facilitation-guide.md. Pack overview:README.md.
Exercises runbook: ../incident/data-leak.md — Data Leak / Exfiltration.
| Field | Value |
|---|---|
| Scenario | Leaked SAS token → abnormal blob egress of PII |
Incident class (K1) |
data-leak |
| Duration | 60 min |
| Participants | 4–8 |
| Difficulty | standard (+1 curveball) |
| Last run | <YYYY-MM-DD> |
Objective¶
Validate that the team can detect, contain, and remediate a data-exfiltration
event using ../incident/data-leak.md, correctly
engage legal/compliance for PII, and surface gaps in the runbook, the storage
configuration, and the breach-notification process.
Success looks like: the team cuts off the leak vector, scopes exactly what left and over what window, rotates the exposed credential, fixes the misconfiguration via GitOps, and starts the regulatory notification clock — citing the runbook at each phase.
Scope & assumptions¶
- In scope: the prod storage account
stsnowopscustholding customer exports (PII); a leaked SAS token found in a public GitHub gist. - Out of scope: the marketing CDN, non-PII telemetry stores.
- Assumptions (state at kickoff):
K2paging is live;K3SOAR in dry-run; Sentinel (J3) + storage diagnostic logs (StorageBlobLogs) enabled; GitHub secret-scanning + push protection on; compliance snapshot tool (E0) available. - Standing rule: discussion only — no real key rotation, no real notifications.
Roles¶
| Role | Played by | Responsibility |
|---|---|---|
| Incident Commander (IC) | <name> |
Declares severity, owns the response. |
| On-call responder | <name> |
Drives data-leak.md. |
| Data platform SME | <name> |
Storage, SAS/keys, network ACLs. |
| Legal/Compliance | <name> |
Breach assessment + notification obligations. |
| Communications | <name> |
Internal + client/regulator-facing messaging. |
| Scribe (optional) | <name> |
Timeline + decisions. |
Injects (timeline)¶
| # | T+ | Inject (read to the room) | Maps to K1 phase |
Facilitator notes (don't read aloud) |
|---|---|---|---|---|
| 1 | 0 min | GitHub secret-scanning alert: a SAS token for stsnowopscust was committed to a public gist by a contractor 5 days ago. Simultaneously, a Sentinel rule flags abnormal outbound egress from that account. |
Identification | The token is read+list, valid for 30 more days. The container holds customer PII exports. |
| 2 | ~8 min | StorageBlobLogs show ~4,200 GetBlob operations from a single non-corp IP (<185.x.x.x>, hosting provider, not a known CDN) over the last 4 days. |
Containment | Active exfil, ongoing. Network ACL is currently Allow all. |
| 3 | ~16 min | The token was minted by a service principal sp-export-job; the same SP's secret also appears in two other repos (one private). |
Eradication & Investigation | Scope creep — rotating one token isn't enough; the SP itself is over-shared. |
| 4 | ~26 min | The blobs accessed are confirmed to be PII (customer name + email + address exports) for ~12,000 records across two client tenants. | Recovery | Now legal/compliance + breach notification is in scope. GDPR 72h clock. |
| 5 | ~34 min | Network ACL set to default-deny, SAS revoked, SP secret rotated, container set to Private + AAD-only, change shipped via Terraform. No new access for 30 min. | Post-Incident | Drive Lessons-Learned: how did a SAS token reach a public gist? E0 snapshot for broader misconfig. |
| 6 | ~40 min | Curveball: one affected tenant is in the EU and one in the US — different notification regimes/timers. Who owns each, and what's the clock on each? | any | Hold for stretch; tests the comms/legal path. |
Discussion Questions (by K1 phase)¶
Push the team into
../incident/data-leak.md.
Phase 1 — Identification¶
- The runbook's Initial Triage says determine data classification (PII/PHI/ proprietary) and the leak vector. What's the classification here, and is the vector the leaked SAS token, the SP, or both?
- Two signals fired (secret-scanning + abnormal egress) — how do you confirm they're the same incident and that exfil is actually happening (not a false positive)?
Phase 2 — Containment¶
- Walk the Containment steps: for a leaking storage account — rotate storage keys, revoke the leaked SAS token, restrict network ACLs to default-deny. Which do you do first to stop the bleeding without breaking the legitimate export job?
- Secrets in source code: the runbook says rotate them immediately in Key Vault /
source system. The SP secret is in two more repos — what's the full rotation
scope, and would you suspend
sp-export-jobentirely?
Phase 3 — Eradication & Investigation¶
- Run the runbook's
StorageBlobLogsKQL (summariseGetBlobbyCallerIpAddress,Uri). What does it tell you about what was accessed and over what window? How do you bound the exposed record count? - How did the data leak (misconfiguration / insider / compromised app)? What's the root cause vs the symptom?
Phase 4 — Recovery¶
- Per the runbook: fix the misconfiguration (containers Private, enforce AAD-only via policy), rotate all credentials that could lead to further loss, and deploy the fix via GitOps / Terraform so drift is resolved. Walk that through — what's the Terraform change, and how do you confirm no drift remains?
- How do you verify the leak is actually stopped before declaring recovery?
Phase 5 — Reporting & Lessons Learned¶
- The runbook says engage legal/compliance immediately for PII and prepare breach notifications per regional rules (GDPR 72-hour window). Who owns the EU vs US tenant notification (curveball)? When did the 72h clock start?
- The runbook says run the compliance snapshot tool (
E0) for broader misconfigurations. What do you check, and which finding becomes a trackedK4action item (e.g. ban SAS tokens for PII containers, enforce push protection org-wide), with owner and due date?
Evaluation Rubric¶
Score 1–4 per dimension; total /20.
| Dimension | 1 — Ad hoc | 2 — Partial | 3 — Solid | 4 — Strong | Score |
|---|---|---|---|---|---|
| Detection & triage | Missed/dismissed | Spotted one signal | Correlated both, classified data | Fast + bounded scope early | |
| Runbook fluency | Didn't open it | Improvised | Followed data-leak.md |
Followed + caught a gap | |
| Containment decisions | Token left valid | Revoked token only | Revoked + ACL deny + SP rotated | All that + full secret-sprawl scope | |
| Roles & comms | Role confusion | Legal engaged late | Legal in early + clear IC | Crisp roles + correct per-region notification owners | |
| Recovery & learning | No fix | Manual fix only | Terraform fix + E0 snapshot |
Validated no-drift + breach process + K4 items |
|
| Total | /20 |
After-Action¶
Fill live; expand into
after-action-template.mdand route findings toK4(apps/post-incident-review/).
- Date / facilitator / attendees:
<…> - Rubric total:
<n>/20 - What went well:
<…> - Top gaps found (cite runbook step):
<e.g. data-leak.md doesn't address SAS-token sprawl across multiple repos; no per-region notification owner matrix> - Improvement items:
<item — owner — due date — destination>