The CAP theorem of security: business, growth, security

There is a famous theorem in distributed systems, the CAP theorem, which says a distributed data store can guarantee at most two of three core properties at the same time: Consistency, Availability and Partition tolerance.

After talking to a few peers, I believe I've stumbled on something similar in security. It's more of a current state than a rule: a company can simultaneously guarantee at most two of three core properties: Business, Growth and Security.

Because it's a state and not a rule, it's also an opportunity. Getting all three is an achievable target.

A pattern that is more common than it should be

I was recently talking with a technical founder whose product already had paying customers and had passed a compliance audit. What we discussed is a pattern I've seen more than once, so I'll describe it in general terms.

The product let customers hold their own encryption key, so the key owner could decrypt their data when they needed visibility. The flow used symmetric key cryptography, and it was audit compliant in the sense that a key could only be generated once.

Ironically, the symmetric key used to encrypt the data was stored in the database in plain text, right next to the encrypted data. The audit didn't go that far.

On top of that, non-expiring API keys for several services were stored in the environment itself. Rotating them wasn't part of any plan, and some of them were tied to the personal accounts of people who had already left.

The encryption key sat in plain text, right next to the data it was protecting.

“Look at the big players”

I asked whether these gaps were a worry, given that a breach would hit hardest for a company selling into security-conscious customers. The answer was candid: plenty of large security companies have had serious lapses, and their stock is still climbing.

It made me stop and ask whether I was overemphasizing security.

Where I landed

In the end I concluded that I can't close my eyes and pretend everything is fine 😀. I can't claim to have a secure system when I know about its gaps and vulnerabilities.

The good news is that this kind of list is fixable: keep encryption keys in a key management service instead of next to the data, rotate integration credentials on a schedule, and tie them to service identities rather than to people.

Right now I'm testing our own system against session hijacking, and it feels good to see that, so far, it's holding up as designed.