The growing push and excitement around zero trust buries the real challenge security leaders need to solve.
Sure, it seems reasonable to think about “zero trust” in terms of networks, data, and identity. After all, we’re experiencing dramatic shifts in the amount of information we need to store, protect, and access. The rise of remote and hybrid work increases our challenge.
I accept that, for many, the theory of zero trust makes sense. But the framing and experience is … unfortunate.
The problem is the how the push for zero trust affects our efforts to connect security to business results. If we don’t solve the underlying challenge, we might stunt efforts to earn respect and recognition for the valuable work we’re doing.
Learning from 'least privilege'
Back when identity was hot the first time (late 1990s, early 2000s), we used the concept of "least privilege" extensively. And in nearly every time we told the business we planned to enforce least privilege, someone would get violently upset with us because we were certainly going to prevent them from doing their work.
See, they heard the negative word “least” in front of something they desired: “privilege.”
It didn’t matter how many times we’d explain “you’ll have exactly what you need to do your job, no more and no less,” we always created unnecessary friction.
Carry the lesson forward to trust. We want our colleagues to trust us more and they want us to trust them more. Seems odd that the solution we’re offering them is zero trust. Again, we negated the thing they desire.
Why don’t we trust developers?
At a recent office hours, we had a lively conversation on ways to improve the security of development — without relying on the security team.
That raised the natural question: “Why don’t we just let the developers have the security tools and use them?”
Jim (not his real name) laughed as he explained every time he suggests it, he’s told, “We can trust developers to do security the right way. They need us to make sure they’re doing it the right way.”
We talked about the friction this creates, and how friction destroys trust as it burns people out.
That’s when Nicole (not her real name) jumped in and said, “Well, there’s your real zero-trust challenge.”
The real zero-trust challenge
Interesting that the phrasing "zero trust" not only negates what people want, but in some ways captures the trust security has for other teams. I realize this blankest statement doesn’t apply to everyone, but it comes up in enough conversations to merit deeper consideration.
A lot of security leaders continue to shake off the reputation as the obstacle to overcome and the barrier to progress. This makes people less willing and likely to work with us to get what we all need.
The challenge we face is how to build trust within our organization — and how to learn to trust others to take the responsibility and action to better protect the information and resources they depend on.
That feels more like "massive trust," not "zero trust."
Flip the script on 'zero trust'
If we want to solve our priority problems and deliver value faster, we need to think about how we frame our approach with other people. It means paying attention to the words and delivery to avoid suggesting we don’t trust our colleagues.
This is how we flip them from “no way” to “what took you so long?”
Focus on the problem your zero trust effort solves. Invite people to contribute their ideas and experience to the solution. And work together to build the trust you need internally to get stuff done.
If you want to connect to business results, you have to be trusted, and you have to trust your colleagues and partners, and the other parts of technology and the business.
