Stay up to date with Pomerium news and announcements.
What is Zero Trust?
The term "Zero Trust" has been co-opted by many marketing branches of products, but it has a defined meaning with real industry impact.
Zero Trust is a security framework centered around the idea that any activity within your network can’t be trusted until verified. On a human level, this means your users should be continuously authenticated and authorized before they can access a resource within your network. A zero trust approach is only possible if you continuously verify each and every request to a protected endpoint – something you can’t do with a traditional perimeter security model.
If you want the more technical explanation, the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-207 defines Zero Trust as:
Zero Trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero Trust Architecture (ZTA) is an enterprise’s cybersecurity plan that uses zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a ZTA plan.
When implemented correctly, Zero Trust bridges productivity and security to provide multiple benefits for organizations. From a security point of view, the goal of Zero Trust is to “prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible.”
What does this mean in practice?
Physical or network locations aren’t good indicators of trustworthiness
Cloud and remote work blurs the line of where the enterprise network perimeter begins and ends
Bring your own device (BYOD) makes it more complicated to keep a complete inventory of connected devices
No more privilege access — every action should be verified regardless of account
In other words: the traditional network security model no longer works because implied trust doesn’t function in the modern workplace. ZT wants to fix that by providing a framework for continuously verified access.
“It is no longer feasible to simply enforce access controls at the perimeter of the enterprise environment and assume that all subjects (e.g., end users, applications, and other non-human entities that request information from resources) within it can be trusted.”
Traditional perimeter-defense has assumed that there are no issues so long as the entrance into the organization’s network is gated. After all, only verified and privileged users are granted access into the enterprise network through existing tools such as the virtual private network (VPN).
ZTA is becoming increasingly necessary because of de-perimeterization — an understanding that there is no enforceable boundary or perimeter in a digitally connected world. This results in a faulty “trust but verify” system because access location is no longer a compelling piece of authentication data.
This is an unintended side-effect of pursuing efficiency, because companies want:
a globalized talent pool
flexibility in remote work
a shift to the cloud for resource efficiency
users to bring their own devices
All moves that resulted in dismantling boundaries and network perimeters. While this did wonders for workflow efficiency, it indirectly exposed all of the enterprise’s resources, sensitive data, and assets. For internal resources to be accessed on the internet, it must first be exposed to the internet.
But even if this weren’t the case, modern threats have revealed faulty gaps in the perimeter-defense:
Stolen credentials — when a user with access privileges is phished or has their account stolen, what now?
Malicious or negligent insiders — when a user with privileges turns malicious, what now?
Lateral movement and pivoting — Once a hacker gets past the perimeter via any entry point, they can exploit that foothold to access other assets. What now?
For each access request, ZTA explicitly verifies the context available at access time—this includes both static user profile information or non-person entity information such as the requester’s identity and role; and dynamic information such as geolocation, the requesting device’s health and credentials, the sensitivity of the resource, access pattern anomalies, and whether the request is warranted and in accordance with the organization’s business process logic. — Line 11, Page 2 of Implementing a Zero Trust Architecture, Volume A: Executive Summary
“ZTA explicitly verifies context” and “dynamic information such as geolocation” → Translates into “context-aware access,” which is not just another buzzword. This means being capable of integrating external sources of data for context when making access policy decisions, a big differentiator from static information such as identity.
“includes both static user profile information or non-person entity information such as the requester’s identity and role” → This is the more well-known identity-aware access process. Note that unlike context, identity does not change.
“the requesting device’s health and credentials” → Devices are common carriers of malware. You need to be able to register a device and check its posture.
“access pattern anomalies” → This falls under observability, audit logs, and once again, context.
“business process logic” → Is another term for authorization policy, or whether an access request is approved or denied. Being capable of writing granular security policy rules is critical for security.
Foundational Principles of Zero Trust
At its core, the zero trust model operates on the principle of "never trust, always verify." This means that no user or device is granted implicit trust; instead, they must undergo a rigorous verification process before being allowed access to an organization's network or resources. This verification process is multi-faceted and includes:
Continuous explicit verification — access is verified at all times for all resources (not just on session start, but per-request), based on all relevant contextual data points
Assume breach — act as though hackers (or vulnerabilities) are already within the network by limiting blast radius
Enforcing access control on a per-resource basis — gaining access to one resource should not result in another resource also being breached
Authorization decisions should take into account all of:
Identity and role (verifying identity is where most existing security postures stop)
Request context (does it make sense to grant this user access to the Finance department’s credit card database?)
Device health and credentials (an increasingly important piece of context)
Resource sensitivity (how bad is it if this data gets stolen?)
Access patterns (another piece of context)
What about network segmentation?
Network segmentation is the practice of further separating the internal network into isolated segments. This is usually done through software-defined perimeters.
We understand that network segmentation is a common practice, but network segmentation has two competing priorities:
You want to segment the network as much as possible to limit blast radius and lateral movement
You want to keep as many assets and resources that rely on each other within the same segment for data flow efficiency
If the underlying goal of network segmentation is to limit lateral movement, then network segmentation fails to limit movement within its own segment. After all, once the segmented network’s perimeter is breached, one can reasonably assume that all resources and assets within that particular segment can be accessed.
NIST gives guidelines on the solution to addressing this problem:
“Access controls can be enforced on an individual resource basis, so an attacker who has access to one resource won’t be able to use it as a springboard for reaching other resources.”
Think of it as segmenting your assets themselves, not just the environment in which they reside. By removing all perimeters within the network, data flow can remain unimpeded and access to each resource is gated by access control. This also reduces the administrative burden of reconfiguring the network each time assets need to be reshuffled around or the data flow has changed.
If there’s concern for legacy applications or tools that don’t have access controls in mind, there are tools that enable this.
What are the stages of zero trust implementation?
CISA has a useful zero trust maturity model for understanding where your organization currently is (probably traditional or initial) with practical guides for shifting up the bracket towards an optimal ZT model. Here’s a relevant rubric from the guide:
To effectively implement ZTA, organizations must follow a series of steps designed to ensure the comprehensive protection of their digital assets.
Step 1: Visibility and Critical Asset Identification
The first step in implementing a ZTA is identifying the most critical and valuable data, assets, applications, and services within the organization. This process allows organizations to prioritize their security efforts and create zero trust policies that specifically address their most sensitive information.
Step 2: User and Device Authentication
Once critical assets have been identified, organizations must ensure the secure access of users and devices. This involves understanding who is accessing the network, from what devices, and for what purposes. With this information, organizations can determine and enforce policies that guarantee secure access to their critical assets.
Step 3: Application and Infrastructure Security
As mentioned previously, a ZTA must also address the security of applications and infrastructure components. This may involve implementing network segmentation (though we recommend avoiding network segmentation), monitoring application behavior, and ensuring the secure operation of all infrastructure elements.
Step 4: Policy Enforcement and Optimization
In ZTA, policy enforcement is a critical component of the overall security strategy. Policies must be enforced at the time of access and continuously evaluated throughout the duration of a user's session, leveraging all existing data points. Additionally, organizations should regularly assess and optimize their policies to ensure the most effective protection of their digital assets.
Step 5: Threat Detection and Response
Your infrastructure must also include robust threat detection and response capabilities. This involves collecting and analyzing telemetry data from all aspects of the organization's network, as well as leveraging threat intelligence to generate accurate risk assessments. In the event of a potential security breach, organizations must be able to respond quickly and effectively to mitigate the threat.
I’m a traditional network person. Is there a way to avoid zero trust?
It’s possible. Here’s a way to determine if the organization can ignore zero trust altogether:
There is no shift to the cloud, now or in the future
The supply chain is wholly owned by the organization or provided by vendors that allow for full auditing and verification
All assets are self-hosted and managed by the organization
All user devices are provided and strictly managed by the organization
All users can be expected to connect from within a pre-determined physical location, not through a VPN
All users are completely trustworthy at all times with no financial incentive to become compromised
All users are well-trained in cybersecurity concepts and would never be negligent insiders
All acquisitions and mergers are extremely audited for the above requirements, or assets are not co-mingled until the above requirements are met
Accomplishing the above list of requirements allows for an organization to continue with perimeter-based defense.
Zero Trust Resources
Here is a list of relevant neutral source material or resources to be aware of:
Whether you’re spinning up a new application or trying to add access control to a legacy service, Pomerium builds secure, clientless connections to internal web apps and services without a corporate VPN. The result is:
Easier because you don’t have to maintain a client or software.
Faster because it’s deployed directly where your apps and services are. No more expensive data backhauling.
Safer because every single action is verified for trusted identity, device, and context.
