Peter Neumann once famously said,”If you think cryptography will solve your problem, then you don’t understand cryptography and you don’t understand your problem.” I guess his exact construction was maybe a little different (in at least one source — see New York Times, February 20 2001), but whether he said it exactly this way or not, it’s (as we’ve learned the hard way over the years) spot on.
I happen to think this applies equally well to a new wave of hype going on in the industry right now: zero trust. Now, if you pay attention to the industry press, you’ve probably noticed quite a bit of attention centered on this. For example, here’s an article in Forbes talking about why “now is the time” for zero trust. I encourage you to read it so you’re not taking my word on what it says, but the gist essentially boils down to “there are lots of breaches… ergo zero trust.” It’s more complicated than that obviously, but the point essentially is that security has become so dire – and breaches so prevalent – that zero trust is now a requirement. I’ve seen a lot of this type of thinking recently both in personal interactions with folks, in marketing, and in the trade press. Specifically, that zero trust will directly solve security problems. It strikes me that advocating this position fundamentally misunderstands both zero trust and also the problems this guidance advocates it’ll solve.
I can hear you sharpening your knives as I say this, so let me caveat a little bit. First, zero trust – when used intelligently and as part of a broader strategy – is absolutely a powerful model. But riddle me this: if you wake up in the morning and decide you’re zero trust now, is anything different? No, right? Because, zero trust is a point of view – a way of looking at how you secure applications, processes, and assets. Specifically, it’s about where you draw the line of demarcation for securing assets and how you view the context within which that asset will operate. Under a traditional model, you might “trust” internal communication paths because the bad guys are expected to be on the other side of a perimeter while under a zero trust , you don’t. Second, zero trust can absolutely and directly forward security goals. For example, assuming communication pathways are de facto untrusted is a great way to ensure that you’re building in strategies to validate connection points, authorize actions, and keep communications private. But if you have a disorganized mess in your shop today and you decide you’re not going to trust a large subset of it, does the original mess get any better? Clearly not.
It frustrates me when people argue that a specific point of view is the answer to a host of concrete engineering problems. It’s like saying REST is the answer to insecure code. REST is a “point of view” and architectural strategy inasmuch as zero trust is. Can REST be part of an application-forward security strategy? Sure. Can you use REST to segment out components so that you can make sure to do a thorough threat model? Absolutely, it’s great for that. Can you harden authorization and authentication state transfer interactions between components while simultaneously hardening the mechanism they use to communicate (e.g. over TLS)? Hallelujah, yes you can. But will you stop application bugs “because REST”? No. Because that fundamentally misses a step or three. Like, important stuff where you actually address the root problem.
Note that I’m not painting everything that uses the words “zero trust” in sequence with the same brush here. There are examples of helpful, useful material (both in the trade media and vendor community) that actually advocate how to use zero trust effectively to solve problems. But pay attention to what they do: they focus on a specific problem and tie it back to zero trust as a philosophy. For example, here’s an article (full disclosure: I know about this one because it was written by a friend) about using zero trust for microsegmentation. It’s useful because it’s about using zero trust to bolster another architectural strategy (microsegmentation), which in turn can be used as a tool to achieve specific security outcomes. See? Helpful because it’s tied both to an objective, a way to achieve that objective, and it’s concrete in how it achieves the security-relevant outcome.