Where tonight sits in the leader track
Six sessions, 45 minutes each, no code and no SQL. Session 1 counted nine paths to Ironwood's customers table. Session 2 put the six functions of NIST CSF 2.0 onto the estate and showed that Detect is the function that moves unseen paths from three to zero without changing the path count. Tonight explains why detection works where it works: by walking the attacker's sequence of moves through the warehouse and finding the two points where the sequence has to cross something that can be logged. Session 4 is backups as attack surface, session 5 is detection in depth, session 6 is the first hour. Ironwood, the fictional mid-size retailer with one warehouse, one customers table and one set of backups, is the estate throughout.
★ What you walk out with tonight. The fifteen tactics of MITRE ATT&CK version 19.2 grouped into four stages you can hold in your head, each stage mapped to a concrete move on Ironwood's graph. The table of which stages a warehouse log sees and which it never will. And one sentence about your own estate that most leaders cannot currently say: the first stage at which you would notice an attacker, and how many stages they would have completed by then.
LiveWhy a kill chain and not a threat list3 min▶
A threat list names things that could happen. A kill chain names the order in which an attacker has to do them, and order is what makes defence possible. An attacker cannot copy the customers table out before finding it, cannot find it before having a login that can query it, and cannot have that login before getting in somewhere. Each step depends on the one before, so seeing any single step early enough stops everything after it.
The chain also answers a question a threat list cannot: where to put the camera. Fifteen tactics sounds like fifteen things to watch. On a warehouse, most of them happen in places that produce no useful record, and two of them happen in places that produce a very good one. Knowing which two is the difference between a log that costs money and a log that catches something.
Ironwood's incident retainer came with a threat briefing: 40 pages, several dozen named attacker groups, a heat map. Nobody could say what to do differently on Monday. The same estate walked through four stages produced one sentence: an attacker would complete every stage up to and including the full read of customers before anything at Ironwood recorded a thing, and the one log that would have caught the read was switched on and unread.
Self-studyWhat ATT&CK is, and what a leader needs from it3 min▶
- ATT&CK is a knowledge base of adversary behaviour maintained by MITRE, built from documented real intrusions. It is versioned, and a new version lands roughly twice a year, which is why the number of tactics on an old slide can be wrong.
- A tactic is the attacker's goal at one stage: get in, hold on, find the data, take it. There are fifteen in version 19.2 and they are the level a leader works at.
- A technique is one specific way of achieving a tactic. There are hundreds. They are the level the builder track works at in its detection-engineering session, where a technique becomes a query against a log.
- Enterprise is the matrix that covers servers, cloud services and the identities that reach them. It is the one that applies to a warehouse. Mobile and industrial-control matrices exist and do not.
- The order matters more than the count. Fifteen tactics in sequence become four stages on a data estate, and the four stages are what the rest of tonight uses.
MITRE ATT&CK, version 19.2, fifteen tactics
12 min liveThe Enterprise matrix of MITRE ATT&CK version 19.2 lists fifteen tactics in this order: TA0043 Reconnaissance, TA0042 Resource Development, TA0001 Initial Access, TA0002 Execution, TA0003 Persistence, TA0004 Privilege Escalation, TA0005 Stealth, TA0112 Defense Impairment, TA0006 Credential Access, TA0007 Discovery, TA0008 Lateral Movement, TA0009 Collection, TA0011 Command and Control, TA0010 Exfiltration, TA0040 Impact. Fifteen is too many to hold while reading a log. Four stages is not.
LiveStage 1, getting in: Reconnaissance, Resource Development, Initial Access3 min▶
TA0043 Reconnaissance is the attacker learning what exists: which staff have warehouse access, which repositories are public, which buckets have names that follow the company's pattern. TA0042 Resource Development is preparing what the attack needs: a convincing login page, a package with a familiar name. TA0001 Initial Access is the first foothold.
On Ironwood's graph, Initial Access is the three doors from session 1. A credential that should not have worked: the analyst or admin who typed a password into a page that was not the warehouse, or the ETL service key sitting in a public repository. A misconfiguration: the export bucket anyone could list. A supply-chain component: the malicious package pulled onto the CI runner. Five of the nine baseline paths open at this stage through the credential door, one through misconfiguration, one through supply chain, and the two insider paths need no Initial Access at all because the insider is already in.
LiveStage 2, settling in: Execution, Persistence, Privilege Escalation, Stealth, Defense Impairment, Credential Access4 min▶
Six tactics, and the longest stretch of the chain. TA0002 Execution is running something: on a warehouse, issuing a query. TA0003 Persistence is making sure the access survives a password change or a reboot: a second key issued to the same service account, a scheduled task. TA0004 Privilege Escalation is turning a small login into a large one. TA0005 Stealth is avoiding notice while doing it. TA0112 Defense Impairment is switching off or degrading the controls that would notice. TA0006 Credential Access is collecting more keys and passwords along the way.
On Ironwood's graph, two of these have exact addresses. Credential Access is the ETL service key in the repository: a credential obtained not by breaking anything but by reading where it had been left. Privilege Escalation is the Friday admin grant: an analyst role that was given admin to unblock a deployment and never had it taken back, so that whoever holds the analyst login holds admin without doing anything further. Both are moves that a valid login makes, using permissions it genuinely has, which is why this stage is where the chain goes quiet.
Ironwood's admin role had been granted to four people over two years for reasons that were each sensible on the day. Two had left. One was the analyst. None of the grants had an expiry, and the access review that would have caught them covered the warehouse's own users but not the roles those users had accumulated. Privilege Escalation at Ironwood did not require an attacker to escalate anything; the estate had done it for them in advance.
LiveStage 3, finding the data: Discovery, Lateral Movement, Collection2 min▶
TA0007 Discovery is the attacker working out what the login they hold can reach: listing schemas, reading table names, finding the one called customers. TA0008 Lateral Movement is moving from the system they are in to the one that holds the prize: from a CI runner to the warehouse, from an analyst's laptop to the admin console. TA0009 Collection is gathering the data in one place ready to take.
On Ironwood's graph, Collection is a SELECT on the customers table: the whole table read in one query by a login with a role that is allowed to read it. That single move is the first point in the chain where the attacker has to touch the warehouse itself in a way the warehouse records. Every one of the eight paths that pass through the warehouse arrives here. Query logging exists for exactly this moment.
LiveStage 4, getting it out or destroying it: Command and Control, Exfiltration, Impact3 min▶
TA0011 Command and Control is the attacker's channel back to themselves, the connection along which instructions arrive and results leave. TA0010 Exfiltration is the data leaving the estate. TA0040 Impact is the attacker doing damage rather than taking: deleting, encrypting, corrupting.
On Ironwood's graph, Exfiltration is a COPY to an external stage: the collected rows written from the warehouse to storage outside the company, in one bulk move, using a feature the warehouse offers for legitimate exports. Impact is the phished admin login dropping the warehouse's twelve tables and purging the snapshots and time travel behind them, so that the nightly backup goes with the data. Exfiltration crosses the egress point, the second and last place on the chain a warehouse estate can log. Impact cannot be seen in time to stop it; it can only be survived, and survival is a copy the admin login cannot delete.
Self-studyThe v19 rename, and why the count on your slide may be wrong2 min▶
Older material says fourteen tactics, with Defense Evasion as TA0005. Version 19 split that tactic into two: TA0005 Stealth, avoiding notice, and TA0112 Defense Impairment, degrading or disabling the controls that would notice. The current list, version 19.2, therefore has fifteen tactics, and any page, slide or vendor deck that says fourteen is describing a version that has been superseded.
The split is useful on a data estate, not just a renumbering. Stealth on a warehouse is an attacker with a valid key keeping their queries inside the pattern the ETL job already produces. Defense Impairment is that same attacker, holding admin, turning off query history retention or deleting the log. The first is why detection is hard. The second is why the log needs to live somewhere the warehouse's own admin cannot reach, which is the same principle as the backup and the reason session 5 stores logs off the estate.
Which stages you would see, and which you would not
9 min liveFifteen tactics on a warehouse produce a very small number of loggable moments. Everything before the first read of the table is a valid login behaving like a valid login. The read itself crosses the warehouse. The copy out crosses the egress point. The drop can only be survived. Four stages, two cameras, and one path that walks past both.
LiveFour stages against the rungs of the bench3 min▶
| Stage | No logs | Query logging | Plus egress alerting | Plus immutable backups |
|---|---|---|---|---|
| 1 · Getting in | Not seen | Not seen | Not seen | Not seen |
| 2 · Settling in | Not seen | Not seen | Not seen | Not seen |
| 3 · Finding the data | Not seen | Collection seen | Collection seen | Collection seen |
| 4 · Getting it out or destroying it | Not seen | Not seen | Exfiltration seen | Exfiltration seen; Impact survivable |
| Bench, with every Protect control on except least privilege | 3 paths, 3 unseen, 0 of 12 recoverable | Query logging and egress alerting are one rung: 3 paths, 0 unseen, 0 of 12 | 3 paths, 0 unseen, 12 of 12 recoverable | |
Read across any row and the pattern is the same: two stages never light up whatever is switched on, one lights up at the first logging rung, one at the second. Read down the last column and the attacker completes every move up to the full read of the table before anything is recorded. That is the honest shape of detection on a warehouse. It does not see the intrusion; it sees the intrusion reach the data.
LiveWhy the middle stages are quiet: a valid key looks like the ETL job2 min▶
Every move in stages 1 and 2 is made with something the estate issued. The phished analyst logs in with the analyst's real password from a real laptop. The service key from the repository authenticates exactly as it does every night when the ETL job uses it. The Friday admin grant is a permission the warehouse recorded granting, so exercising it is not an anomaly, it is a grant working as designed. There is no failed login to alert on, no exploit to signature, no unusual permission to flag.
The professional consequence is that detection built around "suspicious activity" finds nothing here, because nothing here is suspicious to the system that recorded it. What separates the attacker from the ETL job is the hour, the source address and, later, what gets read. Two of those three are only visible once the login does something, which is stage 3.
LiveWhy the last two stages are where detection pays2 min▶
Collection and Exfiltration are the two tactics that cannot be performed anywhere except at the data. A read of the customers table happens in the warehouse and nowhere else; a copy out happens at the egress point and nowhere else. Those are the two places a warehouse estate can put a log that every path through the warehouse must cross. Everything upstream of them happens on laptops, in repositories and on runners, where a log either does not exist or records something indistinguishable from normal work.
This is why Ironwood's bench moves unseen from three to zero at the query logging and egress alerting rung and at no other. The three remaining paths differ completely in stages 1 and 2 and converge at stage 3: all three read the table, and a read of the table is one event with one log. A single camera at the point of convergence sees more than a dozen scattered along the approach.
Ironwood's query history had been retained for a year. Nobody had ever asked it a question. The first question anyone asked, once the leader track had produced the four-stage table, was "which logins read all of customers in a single query in the last twelve months, and at what hour". The answer was the ETL job, nightly at 02:00, and one analyst login at 23:40 on a Saturday, once. That single row was the Collection stage of a path that had already completed. Nothing before it had left a mark.
LiveThe path that skips every stage you can see2 min▶
The export bucket path from session 1 goes from the internet to a nightly extract of the customers table and never enters the warehouse. Walk it through the four stages: Initial Access is the bucket listing anyone can read; Collection is downloading the extract; Exfiltration has already happened, because the data was written outside the estate by Ironwood's own pipeline. Not one of those moves crosses the warehouse or the warehouse's egress point.
Query logging sees nothing, because there was no query. Egress alerting sees nothing, because the data left the warehouse on schedule, as an authorised export, the night before. Every stage the warehouse can watch is skipped. The only record that could exist is the bucket's own access log, and the only defence is the one from session 1: every copy of the crown jewels outside the warehouse needs its own control and its own log, or it is a path through a room with no camera at all.
Self-studyImpact: survivable is not the same as seen2 min▶
A dropped table appears in the query log like any other statement, so Impact is technically visible. It is not visible in time. By the time the log shows the drop, the tables are gone and, without a copy the admin login cannot reach, so are the snapshots. Detection at stage 4 tells you what happened; it does not give the data back.
That is why the bench treats Impact differently from Collection and Exfiltration. Those two are detection problems and the control is a log. Impact is a recovery problem and the control is an immutable, restore-tested backup, which takes recoverable tables from 0 of 12 to 12 of 12 while leaving paths and unseen exactly where they were. Session 4 is about that control alone. What matters tonight is the distinction: a stage can be seen, survived, or neither, and the four-stage table should say which for each.
Which stages would you see
★ 16 min · everyone buildsOne sheet, four rows, no tools. Walk your own estate through the four stages as the attacker would, then ask of each row whether any log you currently keep would record it. If you have no estate to hand, use Ironwood with its audit log switched on and unread, and check your answer against the table above. The output is two sentences: the first stage you would see, and the stage you never would.
Write one sentence per stage on what the attacker would do to your estate. Getting in: which of the three doors is most open. Settling in: which existing grant or key would they use as their own. Finding the data: which table, read how. Getting it out or destroying it: which export feature, or which drop. Use the attacker's verb and your estate's nouns.
Against each sentence, name the log that would record it, or write "none". Be strict. A log exists only if it is switched on, retained, and somebody could name the last time it was opened. "There is an audit log" does not qualify; "query history, retained 90 days, reviewed by the platform lead weekly" does.
Find the first stage you would see. Count how many stages the attacker completed before it. At Ironwood the answer is stage 3, after two full stages and the whole approach. For many estates the honest answer is stage 4, or never. Write the number down; it is the questionnaire answer to "would you know".
Write down the stage you would never see. For most warehouses it is stages 1 and 2, and that is normal: a valid key is a valid key. The useful finding is any stage 3 or 4 row that reads "none", because those are the two places a log is possible and cheap.
Walk one copy of the data that lives outside the warehouse through the same four rows. An export bucket, a partner share, a replica. If every row says "none", that copy is Ironwood's bucket, and its own access log is the first thing to fund.
Two cameras, not fifteen. The most useful thing a leader can take from the fifteen tactics is that a warehouse estate needs a log at the table and a log at the egress point, read by a person, and that no amount of watching the approach replaces either.
Before session 4
30 min- Take your four-stage sheet to whoever runs the warehouse and ask them to correct the log column. Keep the version where the two of you disagree; the disagreement is the finding.
- Ask, in writing, which logins have read the whole crown-jewel table in a single query in the last year, and at what hour. If nobody can answer, the Collection stage is dark regardless of what the questionnaire says about logging.
- Ask whether the query history is stored somewhere the warehouse's admin login cannot delete it. If not, write Defense Impairment next to it: an attacker holding admin can remove the one record of stage 3.
- Check the tactic count on any security slide or vendor deck in circulation. If it says fourteen, or names Defense Evasion as TA0005, it predates version 19 and should be corrected before it is presented again.
Three questions
A vendor deck lists fourteen ATT&CK tactics, with Defense Evasion as TA0005. What does the current version, 19.2, say?
Version 19 split the old tactic into two. Stealth is avoiding notice; Defense Impairment is degrading or disabling the controls that would notice. On a warehouse the second is an admin deleting the query history, which is why the log must live where admin cannot reach it.
Why do stages 1 and 2, getting in and settling in, stay dark at Ironwood no matter which log is switched on?
The phished password is the real password; the repository key is the ETL job's key; the Friday grant is a permission the warehouse recorded granting. Nothing fails and nothing is unusual to the system that logs it. The attacker becomes distinguishable only when the login reads the table, at stage 3.
Ironwood switches on query logging and egress alerting. Which stage of the export bucket path becomes visible?
There is no query, so query logging sees nothing. The data left the warehouse the night before as an authorised export, so egress alerting saw a scheduled job. Every copy of the crown jewels outside the warehouse needs its own control and its own log.