NIST offers a handy vendor-neutral overview of zero trust architecture
Curious about zero trust but don’t understand it yet or how to achieve it, then NIST is here to help you.
We have talked about zero trust a million times on this site, especially over the last year as more and more vendors roll out their related products. The only issue with their explanations is that it’s centered around their offerings rather than zero trust just on its own and what you need.
Well, NIST is here to provide a vendor-neutral look at zero trust architecture, offering clearer (for the most part) explanations of what it is, what you need, and a light explanation of implementation.
September, the non-regulatory agency released a draft on zero trust architecture, so let’s take a look. (We’re on a bit of NIST kick right now, as last week we wrote about their COPE guidelines.)
NIST zero trust guidelines
The NIST draft [PDF] offers enterprise network architects, network admins, and cybersecurity admins (with a focus around unclassified civilian networks) a few different things: a simple explanation of what zero trust is, the architectural components needed, use cases, threats to consider, and how to plan a deployment.
Zero trust overview
Part of the goal of the guidelines is to help establish industry terms, which is useful given how everyone wants to use their own (e.g., BeyondCorp, Post-Perimeter Security, etc.). Secondly, they provide a look at what zero trust is, which we’ve covered plenty of times before.
Understanding zero trust architecture
Next, NIST provides a look at what they consider to be the general components of zero trust architecture, including secure communication, policy governs access to resources, dynamic and not static authentication, and accessing each resource separately. Additionally, you need to design the architecture around a few ideas, such as how the network and devices can’t be trusted, and not all devices and resources will be under the organization’s control or on its infrastructure.
What makes up zero trust architecture?
So, we know the general components and concepts to knock into our heads, but what about actual software to implement? NIST says there are three main pieces: the policy engine, policy administrator, and policy enforcement point. A little abstract sounding, so let me actually explain a little more. The policy engine serves as the actual software that lets a user access each resource, with the decision based off enterprise policies. The policy administrator software connects to the policy engine and, once the policy engine determines whether the user is allowed to access a resource, executes upon it, creating the authentication credential needed. The final main piece is the policy enforcement point, which handles the connections between users and resources. Its job is to monitor and determine continued access between the two. The policy enforcement point can either be one single application or an on-device agent and gateway.
With those three pieces in place, NIST recommends a few complementary components to really make your zero trust architecture pop.
- Continuous diagnostics and mitigation system
- Industry compliance system
- Threat intelligence feed
- Data access policies
- Enterprise public key infrastructure
- ID management system
- SIEM
The decision by NIST to not mention any products does hurt the understanding of each application. Being neutral is useful, but providing examples would have been immensely helpful here!
Deployment models
So, if your organization is interested in zero trust, what deployment options are there? According to NIST, you have four choices:
- Device agent/gateway-based deployment: Device agent installed onto each system and a gateway place between the system and resources, with the gateway handling the policy administrator role
- Microperimeter-based deployment: Agent installed on system with gateway between the system and resource enclave (could be microservices or entire private cloud)
- Resource portal-based deployment: Policy enforcement point acts as a gateway handling access to resources and doesn’t need an agent on system
- System application sandboxing: Compartmentalize (via VM, container, etc.) trusted apps within the system, with the apps talking to a policy enforcement point
Zero trust architecture use cases
What are some potential use cases for zero trust architecture? You can probably guess most of these if you have an understanding of zero trust, but NIST provides some examples if you aren’t sure. Use cases include enterprises with remote offices, organizations that use contractors or require non-employee access to resources, multi-cloud deployments, and organizations that collaborate beyond enterprise boundaries (e.g., federal and private organizations that share access to a database).
Threats enterprises might come across
An important part of deploying a new security architecture is what threats it brings that you might not have had to worry about before. NIST breaks down several threats enterprises need to consider and some advice on preventing each one.
- Subversion of zero trust architecture decision process: improper configuration (either during setup or unapproved later changes) of the policy engine and policy administrator
- DOS and network disruption: attacks to the policy administrator
- Insider threat: Attacker gaining valid credentials
- Visibility on the network: Encrypted traffic preventing proper analysis of traffic
- Storage of network info: Unauthorized access of data collected for analysis purposes
- Reliance on proprietary data formats: Locked into vendors and being unable to easily migrate or address issues
- Subversion of AI tools: Attacker tricks an API or other software agent to perform unauthorized tasks
How to plan and implement ZTA
While the NIST mobility guidelines are focused on providing organizations with a blueprint, this guide offers a much quicker look at how to deploy zero trust, leaving most on organizations. NIST says that they see two setups, pure zero trust architecture and hybrid with legacy architecture. If you have a legacy setup, NIST explains how to migrate to zero trust architecture, pointing out the steps one should take to determining what IT employees are needed, useful assets to integrate, and identifying processes and risks of adopting zero trust architecture.
Going zero trust
While this guide doesn’t provide the in-depth look at zero trust architecture that perhaps their recent NIST mobility guidelines, this does give orgs interested in zero trust a place to start and to understand what is needed. What really makes this latest guide useful is that it isn’t written by a vendor; there’s no particular product recommended to plug into the zero trust architecture over another.
The timing from NIST with this release is pretty good as some vendors have started writing about zero trust again and focusing on their particular products, Google and Beyondcorp and Citrix Workspace.
