Six functions, one estate

A framework is a shared vocabulary between the people who run the estate and the people who fund it. Without one, every conversation about security starts from a vendor's product categories, and vendors sell prevention. With one, the same conversation has six fixed headings, and the two headings nobody is selling anything under still have to be filled in.

The NIST Cybersecurity Framework is the one most boards, auditors and insurers already recognise, which is the whole reason to use it: the value of a vocabulary is who else speaks it. Version 2.0 was published on 26 February 2024 and has six Core Functions. Version 1.1 had five. The sixth, Govern, was added because two decades of incidents kept showing the same pattern: the technical controls existed, and nobody owned them.

• Govern - who owns the customers table, who may approve an exception to a rule, and who decides what gets funded.
• Identify - what exists. Every account, key, bucket, export and runner that can reach the table, and every copy of the table that lives outside the warehouse.
• Protect - what has been closed. The controls that remove a path: MFA, key rotation, private buckets, pinned dependencies, least privilege.
• Detect - what would be seen. The query log and the egress alert, and the person who reads them.
• Respond - what happens in the first hour after something is seen: which credential is revoked, what is isolated, who is told.
• Recover - what survives an attacker who reaches the admin login. A copy of the data that login cannot delete, and proof that it restores.

GOVERN (GV) - the organization's cybersecurity risk management strategy, expectations and policy are established, communicated and monitored. On a data estate this is three names. Who owns the customers table, meaning who answers for it when it is read by the wrong person. Who may approve an exception to a rule, such as granting an analyst the admin role to unblock a Friday deployment, and for how long. And who decides which of the other five functions gets money this year.

Govern is the function that was added in version 2.0. In the 1.1 framework governance sat as a category inside Identify, and in practice it was treated as paperwork. The reason it was promoted is visible in almost every post-incident report: the technical control existed and was switched off, bypassed or never finished, because no named person owned the outcome. Ironwood's Friday admin grant was a Protect failure on the day and a Govern failure for the two years it stayed in place. Nobody had been given the job of taking grants back.

IDENTIFY (ID) - the organization's current cybersecurity risks are understood. On a data estate this is the inventory the builder track draws in its first session: every account, key, bucket, export and runner that can reach the crown-jewel table, written as nodes and edges, and every copy of that table living outside the warehouse. Understanding the risk means being able to count the paths, which means having listed the things the paths run through.

Identify is where a checklist and a graph part ways. Ironwood's hardening checklist was 31 of 40 items green, and the door that mattered, a service key in a public repository two years old and still valid, was on no line of it. An inventory that skips the credential lane, or the storage lane where the export bucket lives, produces a confident number that is wrong. Nine paths is the honest count for Ironwood, and it took one afternoon of walking five lanes to reach it.

PROTECT (PR) - safeguards to manage the organization's cybersecurity risks are used. On a data estate, Protect is the short list of controls that each remove at least one path from the graph. MFA on every human login takes Ironwood from nine paths to six. Rotating service keys and expiring the old ones, six to five. Making the export bucket private, five to four. Pinning and verifying every dependency the pipelines run, four to three. Least privilege on the analyst role, at the end, three to one.

Protect is the function everyone recognises, because it is the one that maps onto products and the one the questionnaire asks about. It is also the function that runs out: after all of it, one path remains, the support agent's legitimate read of a customer record, and no Protect control can remove it without stopping the work.

DETECT (DE) - possible cybersecurity attacks and compromises are found and analyzed. On a data estate this is two logs and one person. Query logging on the warehouse records every read of the customers table, whoever made it. Egress alerting watches the point where data leaves, so that a copy to an external stage raises a flag. The person is the part most estates skip: a log nobody reads detects nothing, and Ironwood's audit log had been switched on for four years and opened twice.

Detect changes a number that Protect cannot touch. With every Protect control on except least privilege, Ironwood has three paths, three of them unseen. Query logging and egress alerting leave the count at three and take unseen from three to zero. The path count did not move, which is exactly why this rung is so often skipped, and exactly why session 5 exists.

RESPOND (RS) - actions regarding a detected cybersecurity incident are taken. On a data estate the first hour is a short list of decisions that are far easier to make before the hour than during it. Which credential is revoked first, and what breaks when it is. Whether the warehouse is taken offline, and who may say so. Which log is preserved before anyone touches anything. Who inside the company is told, and who outside.

The last decision, who outside must be notified and by when, is a matter of law and regulation and belongs to the data-governance course, where breach notification duties are taught properly. Session 6 covers the technical containment decisions and the report that follows. What Respond asks of a leader tonight is one thing: that the list exists, on paper, with names, before it is needed.

RECOVER (RC) - assets and operations affected by a cybersecurity incident are restored. On a data estate this is one question with an uncomfortable usual answer: can the login that reads the warehouse also delete the backups? Warehouse time travel and snapshots are kept by the account that owns them, so an attacker holding the admin login purges them along with the tables. They are a convenience against mistakes, not a backup against the account being taken.

The professional norm is a copy the admin login cannot delete, stored where the warehouse's own credentials do not reach, immutable for a fixed retention, and restored from on a schedule to prove it works. At Ironwood that control takes recoverable tables from 0 of 12 to 12 of 12. It moves nothing on the path count. Session 4 is about this function alone.

Three things pull spend toward Protect. It is the function vendors sell, so every proposal that arrives is a Protect proposal. It is the function the questionnaire asks about, so it is the one that produces a defensible sentence. And it is the function whose progress a control count can show: MFA on, keys rotated, bucket private, four items green. Ironwood spent on Protect for three years and the spend was not wasted; it took nine paths to three.

The problem is not that Protect is funded. It is that the count of controls switched on is taken as the measure of the whole programme, and two of the six functions move nothing on that count no matter how well they are done.

Read Ironwood's bench from the top. Nothing on: nine paths, nine unseen. MFA: six and six. Key rotation: five and five. Private bucket: four and four. Pinned dependencies: three and three. Then query logging and egress alerting: three paths, and zero unseen. The path count did not change by one. On a slide that reports controls or paths, that rung is invisible, which is why in most estates it never gets built.

What it changed is the only thing that matters about the three paths that remain. Before it, an attacker completing any of them finishes and nobody knows. After it, every one of them crosses a logged edge. Detect is the function that turns a residual path from a silent loss into an incident someone can respond to, and it is the only function that can do anything at all about the two legitimate-read paths that Protect can never close.

The next rung on the bench is immutable, restore-tested backups. Paths stay at three, unseen stays at zero, and recoverable tables go from 0 of 12 to 12 of 12. Again nothing visible on a control-count slide, and again the only number that would matter on a particular Monday morning.

Recover starves for a different reason than Detect. Detect is skipped because it looks like nothing happened. Recover is skipped because it looks like it is already done: nightly snapshots run, the backup line on the questionnaire says yes, and nobody asks whether the same login that reads the warehouse can delete the copy. At Ironwood it could. The recoverable count was zero for the whole time the backup box was ticked.

The bench has a row for an estate that funds Protect and Recover completely and Detect not at all. Every prevention control on, immutable backups on, no logging: one path to the customers table, one unseen, 12 of 12 recoverable. The one path is the support agent's legitimate read, the path no prevention control can remove. Without Detect it is also the path nobody would ever see used.

That row is the argument in a single line. Prevention runs out before the paths do, and the path it leaves behind is exactly the one that only a log can defend. An estate that spends everything on Protect has, at its very best, one door it cannot close and has chosen not to watch.

None of the above is a technical finding. Ironwood's platform team knew the audit log was unread and knew the snapshots went with the account. What was missing was a named person with the authority to say that the next pound goes to Detect and Recover rather than to the fifth Protect product, and a measure that would show the board why. That is Govern.

The practical form of Govern on a data estate is short: an owner per crown-jewel table, an approver for every exception with an expiry date on the exception, and a reporting line that carries three numbers rather than a control count. Paths remaining, paths unseen, tables recoverable. Once those three numbers are what the board sees, Detect and Recover fund themselves, because they are the only functions that move two of them.