Benefits of Zero Trust Architecture as Defined by NIST
NIST has released a draft of SP 1800-35, Implementing a Zero Trust Architecture. The lengthy documents lay out their definition of Zero Trust Architecture (ZTA), the benefits, why it’s important, a few examples of how an organization can implement them, expected results associated with their example builds, and a mapping of ZTA security characteristics to current cybersecurity standards and compliance.
We highly encourage technical practitioners to thoroughly review SP 1800-35. To simplify things, we wrote this piece to explore a specific section where NIST lists the benefits of zero trust architecture and comment on their significance and impact on security controls in more detail.
(Not entirely sure what Zero Trust security model even is? Here’s a no-marketing-fluff Children’s Guide to Zero Trust you can read to your children… or executives!)
So, what makes ZTA worth considering for organizations? What are the benefits?
Benefits of Zero Trust Architecture for Productivity, Security, and the Bottom Line
The full list of benefits can be found in Section 1.3 of NIST SP 1800-35B, which outlines the benefits of ZTA.
Support teleworkers by enabling them to securely access corporate resources regardless of their location—on-premises, at home, or on public Wi-Fi at a neighborhood coffee shop.
At first glance, this only reads like ZTA supports remote work. But can’t any VPN do that?
Most organizations utilize corporate VPNs to accomplish this by having the VPN treat end users as already part of the corporate network. And yet, the perimeter-defense system (also known as the network perimeter) is exactly what the U.S. Government is trying to avoid with their speedy adoption of ZTA.
Or in NIST’s own words on line 259:
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.
Organizations looking to embrace remote work but have security qualms should rejoice. Adopting ZTA will fully enable remote work to help businesses ensure their resources are well-protected while tapping into global talent pools. Provisioning access for temporary contractors or third-party vendors also becomes easier, with ZTA providing better operational agility than before.
Protect resources and assets regardless of their location—on-premises or in the cloud.
So? One of the benefits of zero trust architecture is to provide security to your organization’s assets? Can’t any security solution do this?
What’s implied but unsaid here is that organizations should no longer be assigning a special meaning to the user or asset’s location. Physical locality is meaningless in ZTA because everything is assumed to be untrusted until proven otherwise. The goal of ZTA is to enforce authentication and authorization at every boundary.
But where does that put us? How can organizations protect their assets if location can’t be trusted? What’s the trust model now?
ZTA’s solution is for organizations to integrate identity and context, with context being as much information as you can feed the access control system. Organizations that can fully leverage data in access control decisions will mitigate malicious insider risks and reduce their exposure to breaches.
Provision healthy devices from vendors that can verify that the device is authentic and free of known exploitable vulnerabilities.
We want to add here that devices aren’t the only issue, but also third-party software (supply-chain risk, remember?). Unfortunately, the only method for verifying the risk of third-party software is by verifying it yourself.
“Never trust, always verify.” At the end of the day, who watches the watchmen? When you ZTA, everything is dangerous until proven safe. So, how do you assert a device isn’t hacked and can be trusted?
Organizations should verify that a device is authentic and free of known vulnerabilities before granting access. This mitigates the risk of their networks and resources from being exposed to compromised devices. Personally, we’re a fan of secure enclaves and WebAuthn, an open standard that is being widely adopted.
Limit the insider threat by rejecting the outdated assumption that any user located within the network boundary should be automatically trusted and by enforcing the principle of least privilege.
Repeating here: perimeter-defense functions on outdated assumptions. Any organization that still utilizes it (you are if a VPN is involved) should roll out steps for VPN-alternatives.
This comes from a simple yet pertinent question: how do you defend against what’s already inside?
It’s a good question because insider threats are arguably more dangerous than outside hacker. Insiders have pre-existing knowledge of and/or access to the organization’s infrastructure. If an organization’s infrastructure implicitly trusts users because they’re already inside, this can have devastating consequences.
ZTA assumes that insiders are dangerous too and asserts the principle of least privilege access based on identity, role, context, and more to keep the organization’s assets and resources safe.
Limit breaches by reducing an attacker’s ability to move laterally in the network. 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.
This is also a repeat but with a different nuance: not only should organizations pivot away from the perimeter-defense, but ZTA asks organizations to apply access controls “on an individual resource basis.” This best practice enables preventing lateral movement. Compromising any one aspect of your network should not provide attackers meaningful leverage into any other resource, period.
In theory, an organization could “micro/nano/pico-segment” each and every layer of an application stack to ensure appropriate access controls. However, this results in one of two extremes: a very precise yet error-prone boundary that requires constant maintenance and management, or a lax boundary that accepts more risk with the trade-off of being less resource-intensive to update and manage.
We’ve seen it happen everywhere and it’s even called the Goldilocks problem: IT does too much security and people don’t get their jobs done, or IT does too little and access is access.
Perimeter-based approaches and their network segmentations create virtual and physical boundaries around services that need to communicate. Organizations that adopt ZTA to rethink their architecture will effectively limit lateral movement and gain improved operational agility.
Improve incident detection, response, and recovery to minimize impact when breaches occur. Limiting breaches reduces the footprint of any compromise and the time to recovery.
“In 2022, it took an average of 277 days—about 9 months—to identify and contain a breach.” — IBM’s report.
Everything plays together: by applying access controls on an individual resource basis and being able to enforce a standardized central access policy, organizations will naturally be able to detect and respond to breaches much faster. IBM found that faster detection and response also saves money when it comes to costs associated with the data breach.
Implementing ZTA will reduce the time to detect and contain breaches, saving organizations money in the long run.
Protect sensitive corporate data by using strong encryption both while data is in transit and while it is at rest. Grant subjects’ access to a specific resource only after enforcing consistent identification, authentication, and authorization procedures, verifying device health, and performing all other checks specified by enterprise policy.
There’s two parts here when it comes to protecting sensitive corporate data:
- encrypting said data
- enforcing central access policies before granting access
Encrypting sensitive corporate data certainly isn’t a ZTA-specific best practice (but it’s definitely not well practiced, if you’ve been following most of 2022’s breaches). What is ZTA-specific here is how it goes far beyond authentication and authorization protocols in access control before granting access.
Many organizations aren’t able to enforce the additional checks specified because their infrastructure lacks the tools to do so. Implementing good ZTA access controls on an individual resource basis will ensure organizations can better protect their sensitive data.
Improve visibility into which users are accessing which resources, when, how, and from where by monitoring and logging every access request within every access session.
This is more or less an accompanying benefit of the logging and auditing discussed earlier — a good ZTA infrastructure should give the organization strong visibility into who is accessing what and all associated information of that access.
The major difference ZTA is advocating for here is to go beyond identity for authentication and authorization in access control. Existing attack vectors are already breaching organizations that rely on identity alone. ZTA’s desire to have full, real time context and visibility into what users are doing will bring organizations closer to auditing and compliance mandates.
Perform dynamic, risk-based assessment of resource access through continuous reassessment of all access transactions and sessions, gathering information from periodic reauthentication and reauthorization, ongoing device health and posture verification, behavior analysis, ongoing resource health verification, anomaly detection, and other security analytics.
Everything prior is leading up to this statement, the holy grail of ZTA. If ZTA wants organizations to pivot away from perimeter-based access control, then what is ZTA? What is the replacement for the concept of dangerous outside and trusted inside?
This is it.
The keywords here are “continuous” and “ongoing.” Many existing tools and infrastructure will authenticate and authorize at the beginning of the session — then for some reason, the assumption is that the session and accompanying requests are to be trusted.
ZTA calls that assumption flawed — session tokens can be stolen, malicious employees exist, devices can contain malware, and credentials are easily compromised.
“Never trust, always verify” has very different implications in a digital environment. Enabling your network infrastructure to continuously validate and constantly verify a user’s session to grant per-request privileged access is one of the ultimate benefits of zero trust architecture for organizations.
Implementing Zero Trust Architecture
Luckily, implementation doesn’t need to happen overnight. NIST acknowledges it on line 561:
Enterprises should use a risk-based approach to set and prioritize milestones for their gradual adoption and integration of ZTA across their enterprise environment.
Adopting ZTA is never rip and replace and should be a gradual roll-out across their enterprise environment. For those who want to see some architecture examples and expected results, NIST includes How-To Guides and Functional Demonstrations in NIST SP 1800-35.
If you just want to start implementing zero trust access control to sensitive resources today, get started with Pomerium, an open-source context-aware access gateway to secure access to applications and services following NIST’s best practices as outlined above.
Our customers depend on us to secure zero trust, clientless access to their web applications everyday.