Zero Trust Shouldn’t Be The New Normal

People like to tout NIST’s SP 800-207 [Zero Trust Architecture] as the hot new thing, but the fact is, zero trust network models have been around for over a decade. Google took zero trust way past the proof of concept stage with its BeyondCorp model, and by the time 2010 rolled around, the company had the most functional zero trust network on the planet.

Fast forward a dozen years, and zero trust is once again the craze-de-jour of the cybersecurity industry. The question is: Should it be?

Zero trust isn’t the silver bullet that many it is, and zero trust shouldn’t be the new normal.

What's the Problem with Zero Trust?

Briefly: Zero trust presumes that no network connection, internal or external, can be trusted. Every user authenticates with multi-factor, every system’s authentication is reverified multiple times on the network, and the default access policy for everything is ‘deny’.

The primary methods of establishing and maintaining zero trust are microsegmentation, overlay networks, enhanced identity governance, and policy-based access controls.

Setting aside the issues and the expense associated with incorporating zero trust into an existing network, the zero trust model starts to erode when the resources of two corporations need to play together nicely. Federated activity, ranging from authentication to resource pooled cloud federation, doesn’t coexist well with zero trust.

This is where we see a lot of hand waving on how to make things work. The compromises, the shortcuts, and the sacrifices that organizations wind up making to allow federation under a zero trust model should give pause to even the most hardcore CIO.

But more to the point, the problem with zero trust is that humans don’t work in a zero trust manner, and for a good reason. It’s a waste of time and resources to re-validate someone’s identity over and over again when they haven’t even left the room. Our human trust cycle relies on logic, probability, and casual observation to establish and track the identities within an observable range. Interactions with low or no trust tend to be seen as low value, or even hostile.

So what kind of trust model can fully incorporate federation, and emulate more human and relatable trust cycles?

What About Identity-First Networking?

To usefully emulate the kind of ‘informed trust’ model that humans use every day, we need to flip the entire concept of zero trust on its head. In order to do that, network interactions need to be evaluated in terms of risk.

That’s where identity-first networking comes in. In order for a network request to be accepted, it needs both an identity and explicit authorization; System for Cross-domain Identity Management (SCIM) based synchronization is used to achieve this. This securely automates the exchange of a user identity between cloud applications, diverse networks, and service providers.

Think of it as federation taken to an entirely new level. Or perhaps, a new layer. Identity is established at the network transport layer. This means that some of the most traditionally difficult resources to secure (databases, container clusters, etc.) can have their access levels centrally managed by integrating them with a trusted identity provider.

Identity is inextricably intertwined with the concept of trust. All network activity is automatically identity indexed, which means usage patterns are easy to track, and any attempts at unauthorized access are immediately flagged up. If a user or process tries to access something unusual, they’ll stick out like a sore thumb. DNS filters do most of the heavy lifting.

The risk of identity forging is greatly reduced, because the ID provider acts as the one true source of knowledge. The attacker would need the ID provider’s root certificate in order to be effective, a highly unlikely circumstance.

Computationally, this process is far less expensive than zero trust. In the case of zero trust, the work of checking and rechecking authentication several times during any given transaction adds up. In the case of identity-first, the packet doesn’t make it through the front door (or any doors in between as far as internally forged packets are concerned) without the right identity and attached permissions.

Multi-factor authentication is required for identity-first networking, but that’s hardly a bad thing in this day and age. The incorporation of identity-first makes VPNs redundant, which is only a sad story for the VPN providers.

Zero Trust Should Not Be All-Encompassing

There are places where zero trust is entirely appropriate. There are certainly government, national defense, and financial sector applications where zero trust shines.

But unless you’re creating your network from scratch, zero trust requires some expensive retooling to fully implement. This makes it inappropriate for many SMEs, as well as any organization that would rather adopt a model based on heavy federation.

In theory, the expense of zero trust is balanced out by the lower cost per security breach. But if a method such as identity-first networking can get the job done, there’s a new cost to benefit analysis that needs to be made on a per-organization basis.