Detect what you cannot prevent

A prevention control works by removing a way in that should not have existed: a password with no second factor, a key in a public repository, a bucket anyone can list. Each of those is a mistake, and mistakes can be corrected. But some paths to the crown jewels are not mistakes. The support team reads customer records because that is the job. The analyst queries the table because the dashboard needs it. These paths were designed in, on purpose, by people who understood what they were doing.

You can shrink them, with least privilege and row-level policies that show a support agent one customer at a time rather than the whole table. You cannot remove them, because a company that removes them has stopped serving customers. The finished Ironwood design reports one path, not zero, for exactly this reason, and a programme that reports zero has either stopped the work or stopped counting insiders.

• Legitimate path - a route to the crown jewels that exists because the business decided it should. Cannot be prevented; can be logged and reviewed.
• Audit log - the warehouse's own record of who ran which query against which object, when, and from where. Sees every read that passes through the warehouse and nothing that does not.
• Egress - data leaving the estate: a copy to an external location, a share to another account, an extract written somewhere else. The second place to watch, because a read that stays inside is a smaller event than a read that leaves.
• Dark path - a path to the crown jewels that crosses no log anyone reads. Either there is no log at all, as with Ironwood's export bucket, or there is a log and nobody looks at it, which is a dark path with a receipt.
• Undetected - the second column on Ironwood's ladder: how many of the remaining paths are dark. Logging moves it from 3 to 0 while the path count stays at 3.

Most audit logging is switched on because a standard asks for it, kept because turning it off would raise a question, and read by nobody. That is logging as decoration, and it has the same effect on an attacker as a camera with no tape in it. The professional argument for detection is different and does not depend on any standard: for the paths that prevention cannot close, a log that somebody reads is the only control there is.

Put it on the ladder and the point is exact. Every prevention control on Ironwood's list has been applied and the path count is 3. Two of the three are legitimate reads. Adding query logging and egress alerting does not change the 3, and it is not supposed to. What it changes is the second column: undetected goes from 3 to 0. Before it, an attacker using any of the three paths finishes and nobody knows. After it, all three cross an edge that writes a record, and the record is the control.

The last row is the over-correction. Every prevention control on, the backups immutable, least privilege applied, and no logging: one path remains, and it is one path that nobody would see used. That is a complete prevention programme with a support agent's session as its blind spot, and it is what most well-funded estates look like.

A warehouse query log is a better instrument than most leaders expect and a narrower one than most vendors imply. It records four things reliably, and understanding the four is what makes it possible to say what it can and cannot see.

• Who. The user or service account that ran the query, and the role it was using. Not the person behind a shared account, which is one reason shared accounts are a finding in their own right.
• What. The query text and the objects it touched: which tables, often which columns, and how many rows came back. Eleven thousand rows from customers by an account that normally returns one is visible here.
• When. The timestamp, which is what makes three in the morning distinguishable from three in the afternoon, and a burst of two hundred reads distinguishable from a working day of nine.
• From where. The network address and the client application. A support tool's account querying from a laptop rather than the support tool is a sentence a log can write and a person can read.

What it cannot record is intent. The log shows a support agent reading a record; it cannot show whether the ticket existed. Detection therefore works on shape, not motive: volume, time, source and object, compared to what that account normally does. And there is a second, larger gap. The warehouse log records what happened in the warehouse. Anything that never touched the warehouse is not a gap in the log; it is outside the log entirely, and Part 2 is about the path that lives there.

Because the log cannot see why a query ran, detection on legitimate paths is a comparison between what an account did and what it normally does. Five shapes cover most of what matters, and none of them requires knowing anything about the person.

• Volume. An account that returns tens of rows a day returning tens of thousands.
• Time. Activity outside the account's own working pattern, not outside office hours in general, since analysts and pipelines keep odd hours legitimately.
• Source. A service account authenticating from a new address or a new client, especially one that looks like a laptop.
• Object. An account touching a crown-jewel table it has never touched before, or touching every column when it normally reads two.
• Egress. Any read whose result leaves the warehouse: a copy to an external location, a share, an export. Part 2.

Turning these shapes into specific alert rules against specific attacker techniques is detection engineering, which is builder session 7. What a leader needs is the list of shapes, the knowledge that a warehouse log can express all five, and a named person whose job it is to look.

Somebody at Ironwood set up a nightly job that writes the customers table to an object bucket so a marketing agency's tool could collect it weekly. The bucket was made readable so the tool would work. From that moment there were two copies of the crown jewels, and only one of them was inside anything the security programme looked at.

Walk the warehouse's controls down the list and every one of them comes back with the same answer. MFA protects logins; the bucket has no login. Least privilege shapes roles; the bucket has no roles. Query logging records queries; reading a file from a bucket is not a query and produces no row in the warehouse log. Row and column policies mask what a query returns; the extract was written before any of them applied. The path is two hops from the internet to the customer data, and it never enters the box where the controls are.

Making the bucket private is the prevention control, and on the ladder it takes Ironwood from 5 paths to 4. The detection lesson is separate and survives the fix: even a private bucket is a copy of the crown jewels outside the warehouse, and it needs its own access log, read by somebody, or its use is invisible by construction.

The export bucket is the sharp example of a rule that applies to every export, share, replica, extract and backup: a control on the original does nothing for the copy, and a log on the original records nothing that happens to the copy. Each copy of a crown-jewel table gets its own row in the inventory, its own lock, and its own log with a named reader. The reason is not tidiness; it is that the copy is exactly where an attacker goes when the original is well defended, because it is the same data with fewer doors and no camera.

A read that stays inside the warehouse is an event. A read whose result leaves is a bigger one, and it has a distinct signature: a COPY to an external location, a share created to another account, an unload to a stage nobody has used before. Egress alerting watches for that moment, because it is the moment data stops being under any of your controls and starts being somebody else's file.

The honest framing is visible, not blocked. An estate that blocks every external copy stops its own pipelines, so egress alerting is a record and an alert, not a wall. It is also the reason the ladder's rung is called query logging and egress alerting: the query log sees the read, the egress alert sees the read that left, and the two together are what take the undetected count to 0.

Everything in Part 1 assumed that when the log writes a record, somebody sees it. Nothing about a log makes that true. A log that is switched on and never read leaves the attacker's path exactly as dark as before, with the one difference that after the incident there will be a very complete account of how it happened. That is a dark path with a receipt, and it is the most common state of audit logging in mid-size companies.

Detection is therefore three things, and the log is only the first. The second is a rota: a named person, on a stated cadence, whose job includes reading the alerts and the summary of the log. The third is a review: a periodic check that the rules still match the estate, because tables get added, accounts change and last year's alert for the support tool fires on the wrong account this year. Designing rotas, on-call load and review cadence is a discipline in its own right, and the reliability course covers it at length. What matters here is that detection has a headcount line as well as a tooling line, and a programme that funds only the second has bought receipts.

Every row has a different log, owned by a different team, in a different format. That is the real cost of copies, and the reason the number of copies is a security metric before it is a storage one.