Field Notes

On unread policies and the value of focus

Why do so many companies rely on scarcely read thick policy docs rather than thinking about the problem to solve? It’s like giving your 44 year old cousin a stack of finance books expecting the knowledge within to be wha...

On unread policies and the value of focus

Why do so many companies rely on scarcely read thick policy docs rather than thinking about the problem to solve? It’s like giving your 44 year old cousin a stack of finance books expecting the knowledge within to be what finally gets him to move out from Aunt Patty's.

People actively seek documentation about cloud services, data flows, and how to get their expenses reimbursed. These are things they get direct, immediate value from. News flash for security teams - People aren’t motivated about our policy documents in the same way.

I’ve read many docs intended to drive secure development. In all likelihood, they did not succeed.

One policy I read told people to be secure. By doing secure things. No specific risks to focus on, no practical examples. It did mention we shouldn’t write vulnerabilities into our code though which was probably helpful.

Another memorable policy was a full treatise on vulnerability management - its history, its evolution over the years and for reasons that remain unclear to me, it contained hand drawn security proofs.

I never finished reading it. I doubt anyone did. I stopped 20% of the way in, still unclear on what it wanted the reader to do.

You have rules people need to follow though so what’s a security leader to do?

Start by asking “Is this is a problem we can automate or build technical controls and tools to enforce?” What’s better than an imposingly large policy doc? Not needing it in the first place!

You could write about all the ways SQL Injection causes data leaks, about leaky trust boundaries, the dangers to your database of arbitrary user inputs and the finer points of parameterization.

Or…. You could make sure they use whatever standard modern framework your org settled on that will safely handle DB connections for them. Build integrations to give them immediate feedback on vulnerabilities directly in their IDE and add checks in the pipeline to catch when Randy YOLOs his own interface to Postgres again.

You could spend a bunch of time writing about password hygiene, helping with password resets and explaining why swapping out 0 for o in their dog's name doesn't make it a good password.

Or... Move towards passwordless authentication. You’ll knock out a huge amount of risk and kill a massive awareness training time sink, freeing up your team to focus on tools that make problems go away.

Save yourself. Prioritize automating the paved path to security nirvana.