Right Finding, Wrong Fix

A client of ours turned off a server one afternoon and stopped their partner payments cold. Not a nation-state, not ransomware. A scanner had flagged the box for a weak TLS configuration, the finding was accurate, someone acted on it quickly and responsibly, and a legacy system quietly holding up a chunk of their partner-transaction processing went dark along with it. Nobody in the room had known what ran through it. The security work was correct. The result was an outage.

I was CTO of Venari Security then, a startup that built tools to discover what cryptography an organisation was actually running, so we saw a lot of these. Not carelessness. Careful people, doing the right remediation, breaking things they could not see.

It is tempting to file this under a familiar heading: do not tear down a fence until you know why it was put there. There is a good essay on exactly that, applied to security controls, and I am not going to write an inferior one, because this was not that. The team did not misunderstand why the old system existed. They were not disabling a control whose purpose had been forgotten. They understood the finding perfectly, and the TLS configuration genuinely was bad. Every step of their reasoning about security was right. What they were missing was not the reason the fence was there. It was the knowledge of what the fence was holding up.

Those are different questions. “Is this insecure?” and “What breaks if I fix it?” are answered by completely different instruments. Security has spent thirty years building the first instrument and almost none building the second. We have scanners, feeds, severity scores, whole industries devoted to telling you that something is wrong. We have almost nothing that tells you, before you act, what depends on the thing you are about to change. So remediation happens in the gap between the two. A finding arrives with a confident number bolted to it, a CVSS score, a red badge, and the confidence of the finding gets mistaken for confidence about the fix. They are not the same confidence. One of them nobody in that room actually had.

The move that would have saved those payments was not more security expertise. It was someone saying “I don’t know what this connects to.” It took me a long time to learn a rule I now keep without thinking: if you don’t know, say you don’t know, then say where you’d start looking. It reads as humility. It is really about trust. A source that never marks the edge of what it knows cannot be trusted anywhere, because you cannot separate its certainty from its guessing, and the “I don’t know” is what makes the “I do know” worth acting on. That is what went missing in that room, and in the tool that served it. A precise answer to one question was allowed to stand in for the answer to a different question nobody had asked out loud. The finding was precise. The blast radius was unknown. Precision on the first got spent as though it were precision on the second.

The same gap shows up one level higher, in what teams choose to fix at all. A customer once came to us with a little over four thousand TLS “issues” from their previous tool. Four thousand. No security team on earth works four thousand of anything, so they worked none of them, which is what everyone does with a list that long, and the list became furniture. When we went through it with them against what those systems actually did and what sat downstream of them, twelve mattered enough to touch that quarter. Not four thousand. Twelve. The other few thousand were real, in the sense that the scanner was not lying, and noise, in the sense that acting on them blind was about as likely to break something as to fix it.

The direction cuts both ways. We watched a system flag a development server running an outdated elliptic-curve implementation, the sort of finding that sits near the bottom of any severity list. On technical severity alone you would never reach it. But that dev box pushed code straight into a production payment path, and once you knew that, it was not low priority at all. What moved it up the list was not its cryptography. It was its blast radius pointed the other way, at what it could reach rather than what depended on it. Same missing instrument. The severity score could not see the dependency, in either direction.

Cryptography makes all of this worse, which is the part I spent those years staring at. You are at least a little blind to what depends on any given system. You are almost totally blind to what depends on a particular piece of cryptography, because hardly anyone has an inventory of the cryptography they run in the first place: which algorithms, on which systems, terminating where, trusted by what. Ask most organisations that question and you get a shrug and a spreadsheet from three years ago. So when a finding says “this key exchange is weak, replace it,” the honest answer to “what breaks if we do?” is that nobody knows, because nobody has the map. That same missing map is why the post-quantum transition, when it arrives in earnest, is going to be a mess. The hard part won’t be the mathematics. It will be the inventory. But that is a piece for another day.

The fix is not more findings. We are not short of findings. It is the second instrument, the one that answers “what depends on this,” built with the seriousness we built the first: discovery aimed at blast radius, not just at vulnerability. A map of what talks to what, what sits downstream of what, which sleepy legacy box is quietly carrying a payment rail. It is unglamorous work. It does not produce a dashboard with a satisfying number ticking down. It is also the whole difference between remediation that fixes things and remediation that trades a theoretical risk for a real outage.

A finding tells you something is wrong. It has never once told you what will break when you make it right. Until the instrument that answers the second question exists, and is trusted the way the first one is, every fix is a small bet with a stake you cannot see. Most of the time you win, which is exactly what makes it dangerous, because winning teaches you it was safe. The client who went dark that afternoon had won that bet a hundred times before. The hundred-and-first was a legacy server nobody remembered, holding up the payments, invisible until the moment it wasn’t.