Unpacking Zero Trust As A Concept

Since the term “zero trust” was coined in 1994 by Stephen Paul Marsh in his doctoral thesis, it’s gone through a lot of changes. So many, in fact, that security practitioners often find themselves with a mandate to implement it without a good understanding of how to do so. Thankfully, with the publication of NIST SP 800-207 in August 2020, we have a document that may help CISOs, operations teams, and architects bridge the gap between the theory of zero trust and the practicalities of implementation. This article is an attempt to briefly explain zero trust principles, discuss the architectural patterns that arise from those principles, and use some concrete examples to help practitioners make sense of this paradigm. Since the term “zero trust” can apply to principles, architectural designs, initiatives to implement those designs, and products, we are going to lean heavily on the NIST 800-207 document, since it is uniquely clear in distinguishing between these and providing useful guidance.

How Much Trust Did We Have Before?

Zero trust architecture (ZTA) is an attempt to address some of the shortcomings of what we could call a more traditional security architecture, so it makes sense to start by describing that older form.

In a traditional security architecture, broadly speaking, there is a hard perimeter, usually defined by one or more firewalls, along with a VPN for remote access, and some centralized authentication management that identifies the user and grants access. Generally speaking, once an authenticated user is inside the security perimeter, they have very few controls placed on them—they are in a “trusted” zone, and so may access file servers, connect to other nodes within the network, use services, and so forth.

Of course, some enterprises have been aware of the shortcomings of this general approach for quite a long time, and so there may be perimeters within perimeters, or points of control and re-authentication in some architectures, but overall, the general tongue-in-cheek description of the traditional model is “hard on the outside, soft on the inside.” One occasionally hears this described as a “walled garden.” The walls are supposed to keep the bad actors out and allow friction-free productivity inside.

Whatever way we picture this, and however we might have implemented it, there are several downsides to such a design. The main downsides are the following:

• If an attacker can penetrate the perimeter, they often have unimpeded access to explore, use lateral movement, attack machines inside the perimeter, and elevate their privileges, often without much chance of being detected.
• There is little attention paid to the behavior of an individual authenticated entity. An authenticated user may do things that are very out of character, and not be detected.
• The overall lack of granular access control allows users (malicious or not) to access data and services that they do not strictly have a need for.
• The distinct focus on external threats does not address malicious insiders, nor external attackers who may have already gained a foothold.
• This security architecture is difficult to integrate, implement, and maintain as enterprises make the transition from on-prem to cloud, multi-cloud, or hybrid environments.
• The assumption that all devices within the perimeter can be trusted is often difficult to assert, given the popularity of bring your own device (BYOD) and the need to grant access to external vendors, contractors, and remote workers.

What Is Zero Trust Architecture?

ZTA addresses these challenges by redefining the overall architecture, removing the concept of a trusted zone inside a single large perimeter. Instead, ZTA collapses the trust boundary around any given resource to as small a size as possible. It does this by requiring re-authentication and authorization each time a user wants to use each resource. This places identity and access control of individual entities at the center of the architectural concept.

Advantages of Zero Trust Architecture

This new architectural paradigm addresses many of the gaps in the older model. To begin with, it can prevent lateral movement by attackers. If an attacker (insider or external) can manage to get “inside,” they will be continually confronted with barriers to gaining further access, having to re-authenticate and prove their identity constantly for each resource.

ZTA also uses behavioral analytics on entities, whereas traditional access control often uses only a set of credentials for its criteria. User parameters such as time of day, pattern of access, location, data transfer sizes, and many other observable phenomena are evaluated to determine if the entity that is attempting to access the resource is doing so in acceptable manner. If an entity starts attempting to access resources they usually don’t, or at times of the day they are usually not working, these behaviors trigger an alert, and possibly an automated change in authorization.

Shrinking the perimeter to the individual resource level makes it possible to achieve very fine-grained access control. A specific set of APIs may be allowed for some users, and a different subset allowed for others, for example. Or a contractor may be allowed access only to the system they support and nothing else. While this is possible and often attempted in traditional architectures, the extremely fine-grained access control offered by ZTA style architecture can make this easier to manage and monitor.

In addition, BYOD becomes easier to manage. Non-corporate devices can be limited to access only a subset of resources, or prevented from any access at all unless they meet certain specific requirements in terms of patch level or other qualities.

Provided the ZTA implementation is sufficiently extensive and complete that the external perimeter can be removed entirely, remote workers and contractors no longer need to be granted VPN access. They can simply be granted access to only those resources they require, and no others, which can simplify and even remove the need for VPNs entirely, although the latter is rarely achieved in practice outside of cloud environments. Similarly, guest networks for visiting customers are reasonably easy to implement using this architecture; they are allowed access only to outbound connectivity.

Disadvantages of ZTA

This radical departure from a traditional architecture comes at some cost, however. Given that this is, at least in some regards, an entirely new paradigm, it will take time for current security administrators to adapt to it. The actual implementation of this architecture usually requires significant investment in additional controls, with attendant learning, training, and support costs. Integrating ZTA is complex, and maintaining it promises to be complex as well, with an entirely different model of access granting, and many more places where robust monitoring must take place. The very advantages of fine-grained access control may be offset by the difficulties of managing such complexity. And behavioral access control has not been widely implemented so far, and rarely has it been implemented easily.

Finally, any large architectural change requires a balance between keeping the business running and transitioning to the new architecture. The move to ZTA requires careful planning, change control, and a great deal of time and effort.

How New Is Zero Trust, Really?

If you have read this far and are rolling your eyes because it all sounds very familiar, you are not alone. At the level of principles, ZTA sounds less like a completely new architecture and more like an incremental advancement of previous principles, such as role-based access control (RBAC), defense in depth, least privilege, and “assume breach.” However, once we start to sketch out the options to implement re-authentication for every request, it becomes clearer what a substantive change this really is. For this reason, one of the strongest aspects of the NIST document published in 2020 is its emphasis on a few core components that are necessary to accomplish a true ZTA: Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs). The presence of PDPs and PEPs in front of every enterprise asset, through which every request must pass, is the most significant and indicative differentiator between ZTAs and previous attempts to implement similar, though narrower principles.

PDPs and PEPs are abstract capabilities that can take different forms depending on the needs of the enterprise (more on that below). But in all cases, Policy Decision Points are components that evaluate the holistic posture of the requesting subject and the requested object and produce an access control decision. Policy Enforcement Points are the components responsible for opening and closing connections to specific resources based on the output of the Policy Decision Point. PDPs and PEPs can be consolidated or distributed, and in some cases the PEP will be split between an agent on the subject system (such as an employee laptop) and a gateway of some form on the resource. But in all cases, PDPs and PEPs represent the capabilities through which the basic goal of re-authenticating and re-authorizing every request is accomplished.

Approaches, Variations, and Scenarios

By now it should be clear that zero trust (as a set of abstract principles) can manifest in many different ZTAs (as an actual design). This is a strength of zero trust, since it places the initiative in the hands of individual architects and practitioners to evaluate and prioritize the various core tenets (Figure 1) in ways that suit each organization.