In 2008, when the financial system collapsed, the most common institutional response was some version of: "The models didn't predict this." What followed was a long argument about model failure, regulatory failure, incentive misalignment, and the specific instruments — CDOs, credit default swaps — that had transmitted and amplified risk through the system faster than anyone had modeled.
What got less attention, in that argument, was the possibility that the models had worked. That the system had done exactly what it was designed to do. That the failure was not a deviation from the design but an expression of it.
What I Saw from the Inside
I spent years in financial services before I started writing, working at the intersection of planning systems and trading infrastructure. I had a ground-level view of the way these systems were built and operated — not at the level of exotic instruments, but at the level of the underlying assumptions baked into the software. The assumptions about liquidity. The assumptions about correlation. The assumptions about what conditions could coexist.
What I saw — and what I've been writing about, in various forms, across eight books — is that the most effective attacks on systems aren't attacks on their failures. They're attacks through their correct operation. Find what the system does reliably, and find the edge case where that reliability becomes a liability.
This is not a new observation. It's in the security literature, it's in the financial risk literature, it's in the accident investigation literature. Perrow called it normal accidents — failures that emerge from the correct operation of tightly coupled systems. But it keeps not being absorbed, possibly because it's uncomfortable: it means that making a system more reliable can, in certain configurations, make it more exploitable.
The Infrastructure Problem
The infrastructure Knox tracks in the Knox series is not infrastructure that has been compromised in the way the word usually implies. It hasn't been broken into. The permissions haven't been stolen. The logs are clean. The anomaly detection hasn't flagged anything. The system is working as designed.
That's the opening. What follows is Knox figuring out how to find a flaw in something that isn't, technically, flawed — how to mount a defense against an attack that the system's own architects would describe as normal operation.
I find this more interesting to write than traditional cyberattacks because it's harder to defend against. You can patch a vulnerability. You can't easily patch correct operation. The fix, if there is one, requires reconsidering what the system was built to do and whether you still want it to do that.
That's a conversation most organizations don't know how to have. Knox is good at having it. It's one of the things the notebooks are for.