The Complexities of Zero-Trust Network Access

Zero-Trust is a concept Information Security leans into, empowering business partners to deliver imperatives within a seamless, secure, identity-centric method. The user-to-system access capability of a zero-trust framework defines the seamless enablement of virtually any service from anywhere in an automated, scalable way, implementing dynamic security controls and policies directly proportional to the value of the data/service being accessed.

Fig. 1 — What Information Security is providing the business (from the Secure Design Framework)

In my opinion, access is too broad a term to define what is being provided by zero-trust access vendors today. I like the word connectivity. Zero-trust access providers are providing connectivity to applications and services within their architecture. Access is granted after connectivity is granted via identity authorization and entitlement services.

Fig 2 — VPN Access vs. Zero-Trust Private Access

Take VPN as an example. Within your traditional VPN service architecture, VPN users have connectivity to all and entitlement to some (figure 2 above). The ideal, automated, scalable zero-trust design would require connectivity to only those things you are entitled to, nothing more.

Now imagine the design that enforces this requirement at scale within a large enterprise (figure 3 below), with tens of thousands of destination objects, hundreds if not thousands of applications, and hundreds of thousands of users. It isn't feasible to define and manage destination objects and their associated access policies and profiles by hand. So, to scale to the enterprise, zero-trust connectivity must be a by-product of entitlement services, and it must support large sets of destination objects.

Fig. 3 — Connectivity At Scale

A core design principle Information Security should adopt is to require security controls to be byproducts of normal upstream action. In other words, identity should be an automated by-product of a new resource being hired or deployed and entitlement should be an automated (birthright) byproduct of identity creation, and zero-trust connectivity should be a by-product of entitlement.

I have yet to discover a zero-trust access solution that delivers on this zero-trust connectivity requirement (only allowed access to what you are entitled to). Although many mature vendors have large deployments, look closely. You will discover they have hard limits on the number of defined destinations they can support or lack API integrations to enable the zero-trust design requirement at scale. The moment a zero-trust access vendor says, "you can wildcard your destinations and networks to stay within the limit," realize you are no longer working with a vendor who understands zero-trust.