Zero Trust Defined: A Practical Reference for IT Security Architects

Among enterprise security discussions today, zero trust has become one of the most referenced and cited concepts in vendor material, government mandates, analyst frameworks, or architectural discussions, which would be looked at with a repetition worthy of general adoption. The term is used fairly loosely in practice; sometimes for a specific architectural model, and at other times a philosophy or collection of product features. For IT security architects tasked with designing and implementing security programs, a precise, workable definition that cuts through this variation is the essential first step.

The Core Definition

Zero trust is a security approach based on the principle of not trusting anything implicitly. In network security architectures typical to the past, trust was allocated based on network location: systems located inside the perimeter of the organization were assumed trusted by default and anything outside was not. By eliminating the geographic trust assumption altogether, zero trust solves this concern. Access to resources is not based on where a user, device or system sits in the network.

Rather, each access request is assessed in isolation, taking into account verified identity, the security posture of the device requesting access, the sensitivity of the resource requested and contextual signals, including when a request is made, user behavioral history and any risk flags triggered during a session. A separate authentication and authorization phase takes place before establishing a session to a protected resource, rather than just granting once at login and assuming that persists.

The zero trust definition for security architects is a focus on ongoing rather than binary validation. Zero trust does not merely relocate the perimeter; it replaces a decades-old model of a trust boundary based on the idea that a user is always to be trusted until they prove otherwise with an alternative model in which trust is never presumed, and must always be assessed anew for every transaction.

Origins and Development

The zero-trust model arose from an enterprise world where perimeter-based security failed. With the inclusion of remote users, mobile devices, cloud-hosted applications and third-party service providers into enterprise networks, defining and defending a perimeter became increasingly difficult. However, the assumption that everything inside the network could be trusted, a simplification it had always been, became glaringly untenable.

Zero Trust Specification: The U.S. federal standards authorities define zero trust in their codified zero trust architecture specification as an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources (U.S. Department of Homeland Security Cybersecurity and Infrastructure Security Agency Zero Trust Reference Architecture). For architects, this is such an important framing because zero trust isn’t a category of product but a collection of design principles applicable to any technology environment, using various specific implementations.

There is even one saying that the practical implication is: zero trust is an architecture, not a technology. No single product achieves zero trust. Doing so comes with intentional design choices regarding how identity gets proved, how devices get rated and whose access policy governs that device type, as well as how to keep an eye on the enterprise environment continuum.

The Three Foundational Principles

Zero trust consists of a number of specific capabilities and design patterns, but three core principles form its foundation and distinguish it from classic security architecture.

Verify Explicitly

Time to access should use all data available (identity, location i.e. both top-down and bottom-up security level, device health state, service or workload-level usage patterns, data classification, etc.) rather than relying solely on network location or an authenticated state that is no longer valid. That requires that security architectures include the data collection and policy evaluation infrastructure necessary to make these decisions reliably on access requests at user time scale.

Use Least Privilege Access

Any specific user, device, or system is given the lowest level of access possible to accomplish its current task, and for the smallest amount of time necessary. This restricts the damage that may be done with any credential compromise or insider threat to an attacker who gains access through any one identity giving them a very narrow target rather than near-broad access to enterprise resources.

Assume Breach

Security architects design their systems with the belief that a breach will occur at some point and so they work to reduce impact instead of focusing entirely on prevention. This principle underlies the focus of zero trust implementations on things like segmentation, putting data in transit and at rest and logging/monitoring capabilities in place along with quick detection and response capabilities as part of a mature implementation of zero trust.

An Example of How Zero Trust Architecture Works

For IT security architects, zero trust comes to life through the design of several integrated functional components that enforce the three principles above.

Identity Provider: Also called an identity management system, is the foundation of access decision. This also includes every user and every non-human identity (service accounts, API credentials, workload identities), managed by a system that can issue credentials, react to asserting multi-factor authentication and revoke access when conditions change. How Strong The Identity Layer Is, Directly Impacts How Strong Your Zero Trust Implementation Is.
Policy Engine: Evaluates whether to allow or deny access requests using policies defined in conjunction with signals from the identity layer, the device compliance layer, and any other context data sources. The decision point in how you translate the principles of zero trust into allow or deny actions for every request to access resources.
Policy Enforcement Point: The mechanism which executes on the recommendation of the policy engine by allowing, blocking or restricting sessions based on the action comes out as per your policy. These can be enforced in practice as conditional access controls via identity platforms, network access control systems or application-layer proxies, depending upon the resource being protected.
Device Compliance: Query the endpoint or workload making a request has its security stance evaluated. The organization should classify a device that has not been updated with the latest security updates, lacks endpoint protection, or demonstrates a compromise differently than how it would classify a device that adheres to the defined compliance baseline of the organization.
Continuous Monitoring and Analytics: From being able to detect anomalies, enforce session-level policy decisions and provide that all-important audit trail which feeds into security operations as well as compliance, continuous monitoring and analytics supply the visibility required.

Leveraging the Risk Management Framework for Zero Trust Planning

For architects in regulated environments or using federal security guidance, the standards authorities zero trust planning framework is a systematic effort to combine zero trust architecture planning with the traditional Risk Management Framework, providing organization-specific mappings of zero trust principles to the various risk decisions made regarding endpoints, services and data flows. This integration is especially useful in environments where decision traceability with respect to risk acceptance decisions is required and coordination among different stakeholders who have different views on risk and operations is needed.

The planning framework recognizes that achieving zero trust depends upon contributions made by all parts of the organization, not just security teams but application owners, network engineers, compliance teams and even business process owners whose activity determines what access policies need to support. Security architects alone are not in a position to design workable zero trust architectures independent of the context in which those architectures will have to function.

Common Misapplications to Avoid

There are some common misapplication patterns that tend to reoccur in zero trust implementations and therefore might be worth calling out explicitly for architects earlier on in their design journeys.

Treating Zero Trust as a Product: When zero trust is treated as a product sale instead of an architectural program, organizations implement standalone solutions marketed as zero trust-capable tools even though they lack the policy infrastructure necessary for those tools to operate in concert as a coordinated access control environment. The tools are necessary but not sufficient.
Network-Layer Only Focus: There is an argument to be made that if you only enforce zero trust in the network layer and allow application-layer access unmanaged, you will reproduce the same implicit trust problem at a different location. Zero trust needs to be applied across the entire path from input to output, including within applications themselves, not just at the network boundary.
Neglect of Non-Human Identities: This is an old one. In many enterprise environments, service accounts, automated pipelines and API credentials account for the majority of the access activity, yet they are typically over-provisioned and under-monitored. This leaves a tremendous blind spot that adversaries will someday penetrate, and a zero trust architecture that permits humans to use resources but has no control over machine identities is one such example.

Frequently Asked Questions

Is zero trust a product or technology?

Zero trust is not a product it is a set of design principles, aka an architectural model. While it can be delivered through a variety of different technologies and vendor offerings, no single product delivers zero trust standalone. The zero trust architecture requires that some design decisions are intentional about identity, policy enforcement and monitoring of device compliance that is composed across various system layers.

What is the difference between least privilege and standard RBAC (Role-based access control)?

Standard role-based access control organizes users into roles associated with the resources for which those roles have entry, but the granularity and dynamism of role assignments vary greatly. In the context of zero trust, least privilege states that access should be as narrowly scoped as possible for the task at hand and only given for the minimum duration required with a quick revocation time when that task is done. This includes non-human identities which are typically over-provisioned, additionally in traditional access control systems.

What does this mean for the design of the security architecture when one assumes a breach?

The assumption of the breach model reorients architecture goals from simply preventing unauthorized access to also minimizing the impact of the rare instance when prevention fails. This means implementing segmentation so that a breach in one area cannot move around too freely, encrypting sensitive data so that even if exposed it does not become compromised, and investing heavily in detection and response capabilities to ensure breaches do not go undetected for long.