Infosec Stoic

Most breaches aren't the result of exotic zero-days or genius attackers. They're controls everyone believed were operational that had quietly decayed, or were never fully in place to meet the original intent. @philvenables@infosec.exchange makes the case for Control Reliability Engineering: apply SRE discipline to security controls. SLIs/SLOs for control health, error budgets to govern acceptable failure, blameless postmortems and root-cause analysis when a control fails, production-readiness gates before a control is trusted. The reframe I like: control strength stops being a checkbox and becomes a measured, decaying property you have to engineer for. Same gap I keep seeing in assessments, controls assumed working, never verified. https://www.philvenables.com/post/control-reliability-engineering-cre-applying-sre-principles-to-cybersecurity-controls

Boards keep asking how they compare to peers on cyber risk. I used to think that was the wrong question. I've come around: it is exactly the right one, because "reasonable" is comparative by construction. Negligence, the professional standard of care, and the prudent-person rule all ask what a competent peer would have done. The trouble is the data that would answer it does not exist. To show you were reasonable you'd need to know what risk your peers actually decided to accept, the line they drew. Not their losses, not their BitSight score. The decision. And nobody publishes that. I went looking for an industry that had solved it. Aviation, nuclear, banking, patient safety, insurance: every one pools events and losses, always behind a legal shield, and never the acceptable-risk decision. Where a shared line exists, a regulator set it from the top. Cybersecurity has no such shield. And the very reason boards want peer data, to prove they were reasonable, is exactly why no one will contribute theirs: a candid record of what you chose to accept is a gift to a plaintiff's lawyer. The demand and the refusal come from the same rational instinct. The silence is rational. https://infosecstoic.substack.com/p/come-clean

What does CVSS actually measure? Jay Jacobs, who built EPSS, asked exactly that on LinkedIn and admitted he has never gotten an authoritative answer. 87 comments agreed it is "not risk." None could define "severity." That is not a CVSS problem. It is a language problem. Our field runs on load-bearing words it never defined. Held against FAIR, a real risk ontology, CVSS has no frequency term at all, so it structurally cannot be risk. As Sasha Romanosky (@SashaRomanosky@techhub.social) put it, we have "fundamentally lacked that capability as an industry." FAIR and CVSS even use "vulnerability" to mean opposite things: a probability versus the flaw itself. But CVSS is not fake. It is Ptolemaic: coherent, useful, quietly wrong about its own ontology, like epicycles that predicted the sky for 1400 years on a false model. It is dangerous only when we read severity as risk and build clocks and contracts on the reading. The fix is already here: CVSS for severity, EPSS for likelihood, KEV for live exploitation, FAIR for loss. CISA's new BOD 26-04 does exactly this. Stop asking one number to be four things. The Magic Number: https://infosecstoic.substack.com/p/the-magic-number-what-does-cvss-actually #cybersecurity #vulnerabilitymanagement #CVSS