security is a measurement problem

In 1494, a Franciscan friar named Luca Pacioli published a textbook on mathematics. One chapter in it codified a bookkeeping practice that Venetian and Genoese merchants had been using for about two hundred years. The practice was double-entry bookkeeping, every transaction recorded twice, once as a debit and once as a credit, in separate ledgers that had to balance.

Pacioli’s contribution was codification. The practice, once written down, spread across Europe in a few decades and became the substrate of modern commerce. Every company that exists today keeps books that are, at their root, a descendant of the system Pacioli described.

Double-entry bookkeeping is worth looking at closely, because its design reveals something about what a working control system looks like, and that something is the opposite of what the security industry has spent thirty years building.

Double-entry bookkeeping works by making fraud visible. The ledger has no enforcement capability, there is no mechanism in it that stops a merchant from writing a false entry. What the ledger does is refuse to close unless every transaction balances. If someone removes money without a counter-entry, the discrepancy appears at the next reconciliation. The ledger assumes that bad things will happen. Its job is to make sure bad things cannot happen silently.

This is a measurement system. It is a system designed around the premise that control comes from visibility, not from enforcement. The merchants who adopted double-entry bookkeeping continued to get cheated. What changed was that they started noticing when. The difference, over a few centuries, was enough to build the modern economy on.

The security industry took a different path. This essay is about why that path has not worked, and what the alternative would look like if we took the accounting analogy seriously.

the prevention industry

Most of what gets sold as enterprise security is prevention technology. Endpoint detection and response, prevention of malicious code execution. Next-generation firewalls, prevention of unauthorized network traffic. Identity providers with conditional access, prevention of unauthorized authentication. Zero trust network access, prevention of lateral movement. Email gateway, prevention of phishing payload delivery. Each of these is a wall. Each is priced and marketed on the premise that it will stop the bad thing before it happens.

The market for these tools is large and growing, and most of it is spent on prevention. The category has the most vendors, the most attention, the most budget line items, and by far the most confident marketing.

The category also has a persistent, awkward feature: it does not work very well.

Every major data breach of the last decade has happened at a company that had already deployed the prevention tools that were, in theory, supposed to prevent it. Equifax had network segmentation. Target had EDR. SolarWinds had code signing. LastPass had identity providers with conditional access. Change Healthcare had, by any reasonable measure, a well-funded security program. None of them were supposed to be the company in the news. All of them were.

The response from the prevention industry to each incident is the same. Add another layer. Deploy another tool. Upgrade the SKU. Run the breach through the marketing funnel as a reason to buy more of what clearly failed the first time. The industry has been running this motion for thirty years. It generates revenue while breach counts in the aggregate keep climbing.

The question worth asking, which the industry structurally cannot ask, is whether the entire paradigm is wrong.

every postmortem reads the same way

Read any public breach postmortem from the last five years. The structure is identical.

An initial access event happens, a phishing email, a compromised credential, a third-party compromise, an unpatched service. The attacker establishes persistence. The attacker moves laterally. The attacker locates data of interest. The attacker exfiltrates. Somewhere between thirty days and twenty-four months later, someone notices. The notification often comes from outside the company, a researcher, a journalist, a regulator, a law enforcement tip, not from the internal monitoring systems.

Mandiant’s M-Trends report has been publishing median dwell time numbers for over a decade. In the early years, median dwell time was over 400 days. By 2023, it had dropped to 10 days globally, though with huge regional and sector variance, and the drop was heavily driven by ransomware actors announcing their own presence by detonating. Non-ransomware intrusions still dwell for months. The idea that the victim company is the first to notice their own breach remains, in many sectors, a minority outcome.

Every postmortem has the same final section: “in retrospect, indicators were present.” The logs had the data. The alerts were there. Somebody could have seen it. Nobody did, because there was too much telemetry, too little correlation, too many alerts with too little context, and nobody whose job explicitly was “make sure we notice when something’s wrong across the entire data surface of the company.”

This is the measurement failure. The security controls the company bought were almost all prevention controls. The one control that actually determines outcomes, the control that would cause someone to notice that a compromise happened, was the control that was structurally under-resourced relative to prevention.

If this were an accounting problem, we would say the company had a sophisticated set of internal controls but no general ledger. No central record of what was happening, no reconciliation, no visibility into the system as a whole. The accounting profession figured out five hundred years ago that you cannot run a business this way. The security profession has not.

compliance optimizes for the audit narrative

One reason the industry has been able to survive without a ledger is that compliance frameworks have served as a proxy for the missing measurement layer, and they have been very good at serving that proxy badly.

SOC 2, ISO 27001, PCI DSS, HIPAA, these are all, substantively, audit frameworks. They describe controls a company must attest to having. They require evidence that those controls exist. The auditor reviews the evidence, writes a report, and the company goes to market with the report as proof of a security program.

The problem is that these frameworks are structured around control existence, not control efficacy. The question an auditor asks is “do you have a process for X?” The question the framework cannot easily ask is “does the process for X actually work?” Evidence of existence is easy to produce. Evidence of efficacy is much harder, and most auditors are not equipped to evaluate it even when it is produced.

This mismatch has a predictable consequence. Companies optimize their security programs for the audit narrative. The runbooks exist, the policies exist, the training records exist, the logs are retained for the required period, the access reviews are conducted on the required cadence. All of this is visible to the auditor and produces a clean report. None of it tells you whether, if a compromise occurred tomorrow, you would notice.

A company can pass SOC 2 every year while quietly running a program that has no operational visibility into its own access graph. The auditor is looking for the runbook, not for operational visibility. The runbook exists. The report is clean. The breach, when it comes, will be indistinguishable from breaches at companies with no certifications at all.

The certification industry is, itself, a prevention industry, selling the appearance of control rather than the measurement of control. It is not a substitute for a ledger. In many cases, it actively displaces the ledger, because the security team spends the operational budget on audit preparation that it could have spent on telemetry.

two ways to run security

prevention-first

buy the next control

• Every new threat gets a new tool
• Success is measured in alerts and blocks
• Breaches are found by someone outside

ledger-first

know what you have

• An inventory of identities, apps and data comes first
• Success is measured in reconciled gaps
• Controls are chosen from what the ledger shows

MTTD and MTTR are inverted

Two numbers get cited in most executive security discussions: mean time to detect, and mean time to respond. Boards ask for them. CISOs report on them. Vendors use them in sales cycles.

The numbers are the right numbers to care about, but they are usually measured in a way that conceals the actual problem.

MTTD, mean time to detect, is almost always reported relative to alerts that were detected. If you measure the time from alert generation to alert triage for the alerts that made it into the queue, you get a number that looks good. Ten minutes, four minutes, thirty seconds. These numbers are real. They describe how quickly the security operations team processes a work item.

The number almost never asked is the more important one. What is the mean time to detect for events that were never alerted on? What is the detection time for the category of compromise where the initial access didn’t match any signature, the lateral movement used only legitimate credentials, and the exfiltration went over approved channels at sub-threshold rates? The honest answer at most companies is that the MTTD for that category is undefined, because the events are still in progress and nobody has noticed.

MTTR has the same problem. The time-to-respond metric looks great when measured against known incidents. It looks undefined against unknown incidents. Both are real. Only one gets reported.

This is a measurement problem in the literal sense. The company does not measure what it cannot see. The things it cannot see, by definition, do not show up in the measurement. The measurement is therefore optimistic in a structural way that cannot be corrected with better reporting, only with better ledgers.

visibility is the precondition for every other control

Almost every security control the industry sells is downstream of visibility. Access reviews depend on knowing what access exists. Deprovisioning depends on knowing what needs to be deprovisioned. Data loss prevention depends on knowing what data exists and where. Vulnerability management depends on knowing the asset inventory. Incident response depends on having logs from the relevant systems.

When any of these controls doesn’t work, the failure almost always traces back to a visibility gap. The access review missed the fifteen applications outside the SSO. The deprovisioning missed the three systems that were never in the IT inventory. The DLP missed the S3 bucket nobody cataloged. The vulnerability scan missed the subsidiary’s cloud account. The incident response had no logs from the application where the attacker pivoted.

If you inverted the spend, if instead of buying seven prevention tools and two visibility tools, a company bought two prevention tools and seven visibility tools, the controls that remain would be less impressive on paper and more effective in practice. Visibility makes every other control work. No visibility means every other control is operating on a partial map.

This is the accounting analogy at work. The bookkeeping system is what makes every other business control, audits, reconciliations, fraud investigations, tax compliance, possible in the first place. Without the ledger, there is nothing to reconcile against.

Security has spent thirty years buying reconciliation tools while underinvesting in the ledger they’re supposed to reconcile against. The tools keep failing to catch things. The industry keeps responding by selling better tools. The tools get more sophisticated while outcomes flatline. At some point, the question worth asking is whether the thing we are buying more of is the thing that was ever going to work.

what a ledger-first security organization looks like

A security organization that took the accounting analogy seriously would look different from most security organizations today.

It would start with a canonical inventory. Not a procurement list. Not an SSO list. A reconciled, cross-sourced, quarterly-updated record of every application, every data store, every identity, every access grant, every service account, every third-party integration. This is the general ledger. Everything else references it.

It would publish a monthly reconciliation report. Exceptions between systems of record. Access grants without a named owner. Applications without a designated business owner. Service accounts without an attested purpose. Permissions that exceed the documented role. The report would have line items that don’t balance and would be expected, over time, to shrink as the organization closed the exceptions.

It would measure detection against a published set of scenarios, including the ones where there is no alert, by sampling the data and asking: given these specific behaviors in the environment, would we have noticed? The answer for most scenarios would be no, honestly named, with a roadmap that closes the invisibility gaps before buying the next prevention tool.

It would spend most of its budget on telemetry, normalization, and access graph maintenance, the boring infrastructural work that makes the ledger real, and a smaller portion on the glamorous prevention tools that most security budgets are organized around today.

This organization exists in some form at a small number of mature companies. Most security programs look nothing like it. Most vendors sell something else entirely. What it most closely resembles is what accountants have been doing since the fifteenth century.

the ledger as a practice

1. inventoryidentities, apps, data, grants
2. reconcilecompare sources, find the gaps
3. reviewowners confirm what stays
4. actremove, scope down, document

nobody sells the ledger

The last question is why the market has not moved in this direction, given that the failure pattern is so visible.

The answer is that the ledger does not scale as an enterprise sales motion. A prevention tool has a demo. The demo shows a simulated attack being stopped. The buyer sees the value in ninety seconds and can justify the purchase in a slide. A visibility tool has no equivalent moment. It produces reports. The reports are only valuable if you read them carefully and act on what they show. There is no moment of drama.

Enterprise sales motion requires drama. Vendors who sell ledger-type products either pivot into prevention over time or stay small. The category that should exist, the security equivalent of accounting software, oriented around reconciliation and visibility, has never become a market-sized category, because the market’s selection pressure favors tools that demo well.

This is a structural problem with how security gets bought. The gap between those two is where the last thirty years of breaches have lived.

The Venetian merchants who adopted double-entry bookkeeping did so because the merchants around them who skipped it went bankrupt. The selection pressure was real and brutal and external.

Security’s selection pressure has not yet caught up. When it does, when breaches become existential at a rate that can’t be absorbed by insurance and press cycles, the industry will discover what accountants discovered five hundred years ago. A ledger is a more valuable thing to own than another wall.

Start keeping the books.