The hype around Zero Trust (ZT) has reached epic proportions in the cybersecurity world. Everyone’s talking about it. Everyone’s promoting its use and selling services to help implement it. But debates still rage about what it really means and how it should work. Terms said to be part of ZT mean different things to different people. In short, confusion reigns.
One thing most cybersecurity professionals seem to agree on is that attackers are increasingly targeting credentials to gain access to valuable company resources—a trend confirmed by industry research. Seventy percent of data breaches involve stolen or weak credentials1. Ninety-one percent of phishing attacks target credentials2.
As this trend accelerates, it’s becoming clear that focusing security efforts on defending your network perimeter is no longer sufficient. Identity needs to become the new perimeter. This new approach is reflected in ZT’s fundamental tenets, which dictate that:
- No user should be implicitly trusted, even if they are accessing resources from within a company’s internal network, and
- All users requesting access to company resources should be authenticated and authorized.
While most companies are adopting some form of ZT in their environment, it appears that few have an explicit ZT strategy. Okta’s research3 indicates that 97% of organizations are engaged in ZT projects, while only 16% have a clear strategy for implementing it.
NIST’s New Zero Trust Paper
When the National Institute of Standards and Technology (NIST) published its Zero Trust Architecture paper (NIST Special Publication 800-207) in August 2020, expectations ran high that this would be the definitive source for defining and clarifying ZT principles, terms, and technical implementation approaches. Many companies hoped it would provide a step-by-step roadmap for implementing ZT in their environment.
So, is it the ZT Holy Grail? After careful review of the paper, our answer is… drumroll please… definitely maybe. We know. Disappointing.
There are many aspects of NIST’s paper that we really like, and it goes a long way toward solidifying ZT as an industry-leading approach to security. Its publication is a strong indicator of the maturity level of the ZT concept. We believe the paper does a great job of laying out basic ZT principles, terminology, tenets, and logical components of a ZT architecture, which forms an excellent base and reference point for the fundamental aspects of ZT.
There are aspects of the NIST paper that may not reach Holy Grail status for some readers.
If you are expecting a simple step-by-step roadmap for implementing a ZT architecture in your environment, you may be disappointed. The paper is clear in saying that implementation of a ZT architecture:
- Is a complex process that will require a detailed analysis of an organization’s security needs, business processes, and current technical architecture
- Will be different for each organization, depending on their unique business, security, and technical environments
- Will typically need to be done using a phased approach, which focuses on the highest priority/highest risk areas first and phases in other aspects over time
While this may be disappointing to some, we believe it is a realistic view of the approach organizations need to take to maintain a high level of security in today’s environments that increasingly involve cloud-based resources, remote workforces, and Bring Your Own Device (BYOD) devices.
There are also a few points in the paper that we feel might be somewhat misleading. We’ll cover these areas in subsequent blogs in this Zero Trust series.
What’s in the Paper?
Here’s a quick summary of what’s in each section of this comprehensive paper:
- Introduction—history of ZT efforts related to federal agencies; structure of document
- Zero Trust Basics—tenets of ZT; ZT view of a network
- Logical Components of ZT Architecture—logical architecture components and variations; deployment scenarios; trust algorithms; network/environment components
- Deployment Scenarios/Use Cases—architecture deployments for different enterprise environments and use cases (e.g., single headquarters with multiple satellite facilities and/or remote workers, multi-cloud and cloud-to-cloud environments, enterprises with contracted or non-employee access)
- Threats Associated with ZT Architecture—different types of attacks that may be launched against ZT architectures and how to defend against them
- ZT Architecture and Possible Interactions with Existing Federal Guidance—how ZT architectures may interact with and augment existing Federal policies and guidance (e.g., NIST Risk Management Framework, NIST Privacy Framework, Federal Identity, Credential and Access Management Architecture, Trusted Internet Connection 3.0)
- Migrating to a ZT Architecture—different approaches for migrating to a ZT architecture (e.g., pure ZT architecture, hybrid ZT and perimeter-based architecture); suggested high-level steps for migrating to a ZT architecture
The document also provides valuable references and appendices with acronyms and identified gaps in the current state-of-the-art in ZT architecture.
The NIST paper is a comprehensive document that goes into a fair amount of depth on many aspects of ZT that are beyond the scope of this introductory blog. Here are some of the highlights from our perspective.
Identity is the New Perimeter
Enterprise infrastructures are increasingly involving multiple internal networks, remote offices, remote or mobile workers, BYOD devices, and cloud services. In these complex environments, the traditional approach of defending the internal network perimeter is becoming obsolete, and identity is becoming the new perimeter that must be defended. Adoption of ZT is especially important in these complex environments.
Migration to a ZT Architecture is Often a Complex, Multi-Phase Journey
Migrating to a ZT architecture is not a simple process. It involves a detailed review of your current business, technical, and security environment and will likely require a multi-phased implementation approach, beginning with the highest priority/highest risk aspects. Many organizations will need to operate in a hybrid ZT/perimeter-based environment initially until modernization initiatives can be implemented to upgrade technical environments and business processes to fully embrace ZT principles. Even when you have fully implemented a ZT architecture, you will need to continually evolve your environment as ZT concepts and technologies mature.
Least Privilege Concept
Organizations should grant users the minimum privileges (e.g., access to specific systems or applications, read/write/delete access) needed to perform their work functions. Implicit trust zones should be made as granular as possible to enforce the least privileges needed to perform the action in a user request.
Policy Decision Point (PDP) and Policy Enforcement Point (PEP)4
Access to enterprise resources should be granted through Policy Decision Points (PDPs) and corresponding Policy Enforcement Points (PEPs).
The PDP/PEP must ensure that the requestor is authentic, and the request is valid. This may involve checking the requestor’s privileges, device characteristics, device ownership, user behaviors, security posture, time, location of access, and many other factors.
We will drill down into other aspects of the comprehensive NIST paper in subsequent blogs in this Zero Trust series.
Implementing a Zero Trust Architecture
Achieving a ZT Architecture is a journey, and success means focusing on milestones that can be achieved over a series of phases. The first phase is ensuring all resources require authentication, except those resources considered public. This doesn’t mean that single sign-on solutions should be avoided—in fact, these will often be key elements of a ZT architecture. It simply means that each resource needs to be carefully evaluated to determine whether it can be considered trusted.
The second phase is a careful review of network architecture. In many cases, this can best be achieved through microsegmentation. Microsegmentation solutions have matured to the point where they are often simpler and cheaper to implement than many traditional network architecture efforts. These solutions are focused not just on providing segmentation but also on monitoring network flows and helping to define associated business requirements.
The third phase is implementing risk-based authentication. The first two phases are largely focused on ensuring access is unavailable to users that shouldn’t have access. This phase is more focused on ensuring that access is seamless for those that need it and that security incidents are quickly identified and resolved. Establishing a risk-based authentication approach can be the most time-consuming phase, as technologies evolve and testing is necessary to understand how to best make this approach work.
The Zero Trust End Game
In this blog, we’ve identified a few things in the NIST paper that some readers may view as falling short of the ZT Holy Grail. However, we still feel that the document is an extremely valuable and important step in the evolution of ZT.
At Tevora, we are big fans of ZT and feel it’s something that most, if not all, companies need to embrace to ensure the security of their systems as they become increasingly complex and cloud-centric. Here are the key benefits we believe ZT offers when fully implemented:
- Increased resiliency to breaches—reduces vulnerability at several points that are commonly exploited in compromises, including the privilege escalation, discovery, and lateral movement phases of the MITRE ATT&CK framework
- Improved user access experience—with consistent and risk-based authentication login processes, users find login experiences to be more fluid and often less frequent
- Reduced insider threat—with better controls over access mechanisms, users are less able to access data that is outside their job function requirements
- More rapid identification of security incidents—with standardized authentication functions and tighter access points, deviations are easier to identify and function as strong indicators for investigation
We Can Help
If you have questions about the NIST paper or would like help implementing ZT in your environment, Tevora’s team of ZT specialists can help. Just give us a call at (833) 292-1609 or email us at email@example.com.
About the Authors
Clayton Riness is a Principal at Tevora.
Ben Dimick is a Director of Security Consulting Services.
 2019 Verizon Data Breach Investigation Report
 2016 Verizon Data Breach Investigation Report
 Okta Zero Trust Survey 2019
 NIST Special Publication 800-207, Zero Trust Architecture, August 2020, page 5