How the builder track works
Eight sessions, 45 minutes each, one artifact: a defended graph of one real data estate. Tonight the inventory. Then credential paths in session 2, misconfiguration in session 3, the supply chain in session 4, exfiltration detection in session 5, destructive events and backups in session 6, detection engineering in session 7, and in session 8 the whole set is scored by counting the paths that remain open and how many of them nobody would see. The estate throughout is Ironwood, a mid-size retailer whose warehouse holds a customers table that is worth stealing and a backup that is worth destroying.
★ What you walk out with tonight. A node-and-edge inventory of one warehouse that fits on a page. The three doors every path goes through, which turns an endless list of threats into three things to check. And the uncomfortable count: before any control is switched on, Ironwood has nine distinct routes to its customers table, and its backups go with the admin login.
LiveWhy a graph and not a checklist3 min▶
A checklist says whether a control is on. A graph says whether it mattered. MFA on every human login is a fine line on a checklist; on Ironwood's graph it removes three of nine paths and leaves six, which is the number a leader needs and the checklist cannot give.
The graph also makes the two failure modes of security spending visible. Closing doors nobody uses (paths that did not exist) and closing doors while leaving the room dark (paths that remain and cross no logged edge). Session 8 puts numbers on both, and the numbers only exist because tonight's inventory does.
Ironwood's platform team had a 40-item hardening checklist, 31 items green. The path that mattered was not on it: a service key committed to a public repository two years earlier, still valid, authenticating from anywhere. No checklist item said "count the keys in git history", because whoever wrote the list had never met that door.
Self-studyThe vocabulary for the whole track4 min▶
- Node - anything an attacker can be, hold or reach: a starting position, a credential, an asset, the target.
- Edge - one move: a phished password, a key read from a repo, a SELECT with a broad role. Every edge is closed by a specific control or seen by a specific log, and knowing which is the whole design.
- Crown jewels - the small number of tables whose loss is the incident. At Ironwood it is one table. Most estates have two or three.
- Path - a chain of edges from a starting point to the crown jewels. Session 8 counts them.
- Undetected path - a path that crosses no logged edge. The attacker completes it and nobody knows.
- Recoverable - whether an attacker who reaches the admin login can also destroy the copy you would restore from. Time travel and snapshots go with the account; a backup the account cannot delete does not.
- Tactic - MITRE ATT&CK's word for the attacker's goal at one stage: initial access, credential access, exfiltration, impact. Session 3 maps the fifteen of them onto a warehouse.
Everything an attacker can touch, in five lanes
9 min liveThe inventory is not long. Five categories cover a warehouse estate, and each has a place you go to enumerate it. The discipline is doing all five, because the door is always in the lane somebody skipped.
LiveIdentities and credentials are different lanes on purpose3 min▶
An identity is who the warehouse thinks is asking. A credential is the thing that proves it. The two drift apart constantly: one identity with four active keys, three of which nobody can account for; one key that three pipelines share; a human account that a script has quietly used for a year.
Enumerating identities tells you the shape of access. Enumerating credentials tells you where the doors actually are, and it is the lane teams skip because it means reading git history and CI configuration rather than running a query.
The third command is the one that found Ironwood's two-year-old key. It is not clever. It is the lane nobody had walked.
LiveStorage: every copy of the data that is not a table3 min▶
The warehouse has grants, policies and an audit log. The nightly extract of the same table sitting in an object bucket has whatever the bucket has, which at Ironwood was a listing anybody with the URL could read. Every export, share, external stage and backup is a second copy of the crown jewels with its own, usually weaker, set of doors.
Ironwood's marketing agency needed a weekly customer extract. Somebody set up a bucket, made it readable so the agency's tool could pull it, and moved on. The bucket appears nowhere in the warehouse's grants because it is not in the warehouse. On the graph it is a two-hop path from the internet to the customers table that crosses no query log at all.
Self-studyCompute, code and network: the lanes that hold keys and decide where keys work4 min▶
- CI runners and orchestrator workers run somebody else's code with your key in their environment. A malicious package in the build is a path to the key, which is a path to the warehouse. Session 4.
- Notebooks are the credential lane's favourite hiding place and the compute lane's least governed member. Inventory them as both.
- Package manifests and lockfiles are the supply-chain inventory. If you cannot say which version of which connector ran last night, that is a finding, not a gap in the exercise.
- Network paths decide from where a credential is usable. A leaked key that only authenticates from your own address range is a much smaller door than one that works from anywhere. This lane is what the "perimeter firewall only" over-correction in session 8 gets right, and it closes exactly one of nine paths.
Three doors, nine paths
8 min liveEvery path into a data estate goes through one of three doors: a credential that should not have worked, a misconfiguration that exposed something directly, or a supply chain component that ran with your permissions. Naming the door tells you which session's control closes it.
LiveWhich door each path uses, and which session closes it4 min▶
| Path | Door | Closed by | Seen by |
|---|---|---|---|
| Internet, public repo, ETL key, warehouse | Credential | Key rotation (session 2) | Query logging (session 7) |
| Internet, phished analyst, warehouse | Credential | MFA (session 2) | Query logging |
| Internet, phished analyst, admin role, warehouse | Credential, then privilege | MFA, or least privilege | Query logging |
| Internet, phished admin, warehouse | Credential | MFA | Query logging |
| Internet, CI runner, ETL key, warehouse | Supply chain | Pinned dependencies (session 4) | Query logging |
| Internet, public export bucket, table | Misconfiguration | Private bucket (session 3) | Nothing in the warehouse sees it |
| Insider, own login, warehouse | None - legitimate | Cannot be closed without stopping the work | Query logging |
| Insider, own login, admin role, warehouse | Privilege | Least privilege (session 2 of the access course) | Query logging |
| Insider, own legitimate support session | None - legitimate | Cannot be closed | Query logging |
Two rows say "cannot be closed". That is not a gap in the design; it is the reason detection exists. A support agent has to read customer records to do the job. The only defence against that path being misused is that every read is logged and somebody reads the log.
Self-studyThe export bucket is the path the warehouse will never see3 min▶
Eight of the nine paths pass through the warehouse, so a query log on the customers table sees all eight. The ninth reads a nightly extract from a bucket. It never touches the warehouse, so no warehouse control - not logging, not least privilege, not MFA - has any effect on it.
This is the general lesson of the storage lane: every copy of the crown jewels outside the warehouse needs its own inventory row, its own control and its own log, or it is an open door in a room with no camera. Session 3 closes this one; session 5 covers how you would even notice it being used.
Draw your own estate
★ 18 min · everyone buildsPick one warehouse and one crown-jewel table. If you have nothing to hand, use Ironwood's inventory above. The output is a text file of nodes and edges, not a diagram; the diagram comes from the file.
Name the crown jewels. One to three tables whose loss is the incident. If you list ten, you have not decided. Ironwood's is customers.
Walk the five lanes and write a node per thing. Every human role, every service account, every key you can find, every bucket and stage and share, every runner and worker, every network path. One line each. Expect 15 to 40 nodes for a single warehouse.
Write an edge for every move. For each node ask: what can this reach, and how? "phished password" and "key in repo history" are edges. So is "SELECT with a broad role". Use the attacker's verb, not the architecture's.
Add the two starting points. The internet, and one insider with a real functional role. The insider is not an accusation; it is the shape of half of all real incidents and the reason two of Ironwood's paths cannot be closed.
Trace every path to the crown jewels by hand, and to the backups. Count them. Ironwood has nine to the table and one to the backups. Your number is your baseline, and it is worth writing down before anybody proposes a control.
For each edge, name the control that closes it and the log that would see it. Leave the cell blank where you do not know. Blank cells are the syllabus for sessions 2 to 7; two of Ironwood's edges have a blank in the "closed by" column forever, and that is the honest answer.
Keep the file next to the policies, in version control. The inventory is the thing session 8 scores and session 7 checks against reality. A graph in a slide deck is a picture; a file is a control.
Before session 2
30 min- Finish the inventory file for one warehouse, all five lanes, including the copies of the data that live outside it.
- Run the git history grep on every repository that has ever deployed to that warehouse. Write down the count, then stop and do nothing else with what you found until session 2 - rotating a key without knowing what depends on it is its own incident.
- Count your paths to the crown jewels and to the backups. Compare with nine and one.
- Find out whether your backups can be deleted by the same account that can read the warehouse. The answer is usually yes, and session 6 is about that.
Three questions
Ironwood's nightly customer extract sits in a publicly listable bucket. Which warehouse control reduces that path?
The bucket is a second copy of the crown jewels with its own, weaker doors. No warehouse control affects it. Every copy outside the warehouse needs its own inventory row.
Two of Ironwood's nine paths are marked "cannot be closed". Why is that not a gap in the design?
A support agent must read customer records. Prevention cannot remove that path without stopping the work, which is exactly why detection exists. The finished design in session 8 has one open path, logged.
Why are identities and credentials inventoried as separate lanes?
Ironwood's two-year-old key belonged to a perfectly ordinary identity. Enumerating users found nothing; enumerating where keys lived found the door.