Security is a Side Effect

The cybersecurity industry’s product-centric model creates a market equilibrium that actively disincentivizes platform-level fixes, which would deliver far greater security improvement per dollar.

Security is a side-effect. A side-effect of well-designed software. A side-effect of well-designed networks. A side-effect of seeing the difficult work and running head first towards it, rather than looking for shortcuts.

I’ve been working in the cybersecurity industry for about 10 years now, and I was interested in it for about 10 years before that. Having that interest for so long, I studied a lot about how security has evolved; both the controls and where the market is spending its money.

Watching the evolution of the antivirus into the EDR.

Watching EDR become XDR.

Watching VPNs become Zero Trust.

Watching DLP… still be basically useless. Okay maybe not much change on this one.

Watching the “Cyber Killchain” get replaced with ATT&CK.¹

Watching “You need a SIEM” become “You need a SOAR.”

Watching dependency files translate into SBOMs.

Watching SAML become OIDC (thank god).

Watching security questionnaires become trust portals (which are security questionnaires now with a username and password).

Watching TLS certificates become short-lived and free.

Watching password managers become a de facto standard for many organizations.

Watching FIDO2 evolve into being so ubiquitously available that it’s now actually kind of annoying to deal with all the competing players wanting to save my credentials.

But despite hundreds of billions of dollars spent on cybersecurity products and services every year², the state of things continues to be… suboptimal. We’re building a house of cards atop a foundation of sand. In an unbelievable turn of events, securing computers whose very nature is designed to be flexible and general-purpose is kind of difficult.

I’m not saying we haven’t had improvements in security over the last few decades. We absolutely have. But as Gibson said, “The future is already here – it’s just not very evenly distributed.”³ We’ve made tons of gains, but much of the latest and greatest security is only really available to the biggest enterprises.

With the push of a single commit (figuratively speaking), Microsoft could wipe out entire classes of vulnerabilities in their products that stem from legacy support requirements. We’ve seen it happen with the deprecation of SMBv1. Whole security companies, with hundreds of millions in VC funding, will have significantly less impact on security in their entire existence than a few project managers at Microsoft, Apple, or Google could over the course of a couple years of their career.

A few well-placed engineers can have such an outsized impact on the security of the world’s digital systems that it becomes effectively impossible to measure almost any security company against that impact.

For as long as I remember, people have talked about “secure by design” - how security should be built into the design of a system. Usually this manifests as “security professionals with no software experience tell software professionals with no security experience to ‘do security.’” The SDLC. Security architecture diagrams. Security reviews. Yada yada yada.

It hasn’t worked.

Not only is software not secure by design, but we aren’t designing security into software.

Designing security into software involves things like baking audit logs into your platform, offering single sign on (without the SSO tax), offering service principals / service API keys as a first class concept, understanding how data will be deleted when users exercise their rights, understanding that users have lifecycles when they join your application, etc.

You could build a tool that tells people about the vulnerable settings in their AWS environment. You could get millions of dollars in VC funding for it. You build a go-to-market pipeline and your engineers could write way more yaml files than they ever thought they would.

AWS could just make those vulnerable states unrepresentable tomorrow. Of course, they take years to make those changes because hasty deprecations would ruin businesses. But they could, and it would kill dozens of security startups over night. Security would improve drastically, and nothing of value would be lost. I mean, just think about how many fewer sensitive data breaches would have occurred if s3 buckets couldn’t be public without a Cloudfront distribution in front of them. Think of how much less impact there would have been if public s3 buckets didn’t default to listing the contents of the bucket.

All of this is to say that security is fundamentally not a product. It never should have been treated as one. Security is not the thing you get from attending 52 security conferences per year. Security is not what you get when you buy all the popular vendors and smash them together in a veritable jambalaya of barely interoperable software.

Security is the side-effect of good engineering. Security is the side-effect of putting in the work to do the hard things that you know you should do even though your quarterly planning cycle can’t account for work that will take years to see the outcomes of. Security is the side-effect of being meticulous with the tools you choose. Security is the side-effect of being ruthlessly consistent with learning the ins and outs of the systems you have.

Security is quality, reliability, and observability. These are all core features of modern systems engineering. There are clear business incentives to produce these qualities. They can be tied directly to financial outcomes. Security has uniquely positioned itself as an industry to think it is somehow special, and also that you can’t reliably show financial outcomes for your security spend. But trust us, you need to spend more.