The attacker's view of a warehouse

An auditor asks whether a control exists. An attacker asks whether there is a way in that no control touches. Those are different questions, and an estate can score well on the first while failing the second completely. Ironwood's hardening list was 31 of 40 items green. Its two-year-old service key in a public repository was not on the list, because whoever wrote the list had never met that door.

The attacker's view is also the one that fits on a page. A threat landscape is infinite; the set of paths from the internet and from an insider to one table is small, finite and countable by hand. That count is the number a leader can act on, and the number a control list cannot produce.

• Crown jewels - the small number of tables whose loss is the incident. Ironwood has one. Most estates have two or three; an estate that names ten has not decided.
• Path - a chain of moves from a starting point (the internet, or an insider) to the crown jewels. The unit everything else is counted in.
• Door - the one weak point a path relies on: a credential that should not have worked, a misconfiguration that exposed something directly, or a supply-chain component that ran with your permissions.
• Undetected path - a path that crosses nothing anyone logs. The attacker finishes and nobody knows. Ironwood's baseline has nine of these.
• Recoverable - whether an attacker who reaches the admin login can also destroy the copy you would restore from. Snapshots and time travel go with the account; they are not a backup against the account being taken.
• Control - something that closes a door or logs a path. A control that maps to no path is a line on a checklist and nothing else.

• The data itself. Sold, or held over the company for payment. A complete customers table with contact details and order history is worth more than the same rows scattered across an order system, a support tool and a marketing platform, because somebody has already done the joining.
• The ability to destroy it. Ransomware against data does not need to encrypt anything. An admin login that can drop tables and purge the snapshots behind them is enough to make Monday not happen. At Ironwood the same login that reads the warehouse can delete the backups, so the question "is it backed up" has a yes answer and a no meaning.
• A foothold into the rest of the company. Warehouses hold service accounts: the key the ETL job uses, the token the BI tool uses, the credentials the orchestrator hands out. Whoever holds the warehouse holds keys to the systems that feed it, and a data breach turns into a company breach.

A control list names what has been bought. The question underneath the questionnaire is which paths remain, and a list cannot say, because a control only matters where it sits on a path. Ironwood's firewall and role hierarchy were real and switched on. They coexisted with nine open routes to the customers table because eight of the nine never met either control in a way that stopped them.

The honest version of the questionnaire answer is three numbers: how many paths to the crown jewels remain, how many of them nobody would see used, and how many tables survive an attacker with the admin login. A leader who can ask for those three numbers has changed what the security programme reports, which is most of the job.

The warehouse has grants, policies and an audit log. The nightly extract of the same table, written to an object bucket for a marketing agency, has whatever the bucket has. Every export, share, replica and backup is a second copy of the crown jewels with its own, usually weaker, set of doors, and it appears nowhere in the warehouse's own controls because it is not in the warehouse.

The professional norm is that every copy of a crown-jewel table gets its own row in the inventory, its own control and its own log. The reason is simple: a control on the original does nothing for the copy, and the copy is usually the path that no warehouse log will ever see.

The most common door, and the cheapest to close. A password with no second factor, phished from an analyst or an admin. A service key committed to a repository two years ago, still valid, usable from anywhere. A role granted to an analyst on a Friday to unblock something and never taken back, so a phished analyst is quietly an admin.

Ironwood's credential door carries five of the nine baseline paths. MFA on every human login closes three of them and takes the count from nine to six. Rotating service keys and expiring the old ones closes one more, six to five. Least privilege on the analyst role, which is really a governance decision about who approves a grant and for how long, is what removes the Friday admin path at the end.

No login at all. A bucket that anyone with the address can list, an open share, a network policy that allows every address. Ironwood's example is the nightly customers extract, written to a bucket a marketing agency's tool could read, which meant anyone could read it. The path from the internet to the customer data is two hops long and never touches the warehouse.

That last fact is the important one. No warehouse control affects this path: not logging, not least privilege, not MFA. Making the bucket private takes the count from five to four. Nothing else on the list would have, and no warehouse log would have shown it being used.

Your pipelines run other people's code: packages, connectors, transformation libraries, pulled fresh on every build. A malicious version of one of them runs on your CI runner, and the CI runner holds the ETL service key so the pipeline can load the warehouse. The package did not break in; it was invited, and it read the key out of the environment it was handed.

The control is pinning every dependency to a known version and verifying it before it runs, which takes Ironwood's count from four to three. It is unglamorous, it belongs to the platform team, and it is the door most estates have never checked because nothing about it looks like a security setting.

Of Ironwood's nine paths, two are legitimate reads. An analyst logs in with their own credentials and queries the table their job requires. A support agent opens a customer record to answer a ticket. There is no door here to close, because closing it means stopping the work. Every prevention control on the list leaves these paths exactly where they were.

The only defence against a legitimate read being misused is that every read is recorded and somebody reads the record. That is why the finished Ironwood design reports one path rather than zero: the support session remains, and it is logged. A programme that reports zero has either stopped the work or stopped counting insiders. Detection is session 5 of this track, and it sits there because prevention runs out before the paths do, not because it matters less.

Plus one path that is not to the table: the phished admin login reaches the backups and can drop and purge them, snapshots included, until the backups are made immutable. Session 4 is about that path alone.

A perimeter allowlist decides from where a credential may be used. That is a real control and it closes a real door: a leaked service key used from an address outside the company. It does nothing to the others. A phished user logs in from their own laptop, inside the allowlist. The malicious package runs on your own CI runner, inside the allowlist. The export bucket sits outside the perimeter altogether, so the wall is beside it, not in front of it. Both insiders were never outside.

Counted, the state "perimeter firewall only" is seven paths, seven unseen, zero recoverable tables. It is the most common single security purchase in mid-size companies and, on its own, the weakest position on the whole ladder after doing nothing.