To the letter: Zero Trust Architecture (ZTA) according to NIST 800-207 (#1)
“To the letter” is a series around the analysis of standards, frameworks and RFQ/RFC that I find interesting — where I take the time to read and summarize my findings on the documents.
Kicking it off with a hot topic, Zero Trust.
I’ve discussed the topic on a few occasions, covering the recent history and even the (very) basics of NIST 800–207 and what the industry is offering recently.
But what does the NIST 800–207 publication entails in full?
Well, let’s discuss, this is part 1 of this series — from this point onward everything is based off of the publication.
./publication
The public document can be found online (check the sources). It was published in August 2020 and is 59 pages long.
Did you know: According to the organization itself, NIST’s 800 series is about:
The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations
The document is aimed at Enterprise Architects.
./zero-trust
Definition:
An evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.
It’s based on a few assumptions:
- no implicit trust from users to assets (data) regardless of ownership network location;
- authentication & authorization are established before access to assets.
- focus on protecting assets/resources not network segments.
- attacker is present in the environment
./1-introduction
Modern Enterprise networks are made up of multiple entry points, the perimeter no longer exists from a user to data perspective. Also, the perimeter shows its inefficiencies when after it is breached, it is incapable of preventing lateral movement.
The need to protect assets instead of network access is what has accelerated the need for the Zero Trust (ZT) approach.
Author’s P.s.: The document does highlight how asset can be data, users, applications, resources and more from the environment. Due to this wide meaning, it utilizes the term “subject” to assets and “user” for when end user is specifically called out.
Zero trust Security Models assume that attackers are present in the environment and that every network (regardless if Enterprise or non-enterprise) is not trustworthy.
This means that in this model, continuous analysis and risk evaluation must happen to each & every asset access request — since there’s no implicit trust (being inside the castles’ walls does not mean you’re trustworthy).
The publication covers Architecture Components, Possible Deployment scenarios and threats and even provides a road map for organizations that want to start on the ZT journey.
ZT is a set of guiding principles and system design to improve security posture of any classification or sensitivity level, at this stage, the publication refers to FIPS 199, a set of standards for security Categorization
Author’s P.s.: the importance of data classification and sensitivity is made explicit by NIST, something that ultimately requires cutting edge technology for scanning and applying auto-labels, since no admin will ever be able to manually categorize documents at a higher rate than new documents are created in the environment.
I do want to emphasize a piece of text from the publication:
When balanced with existing cybersecurity policies and guidance, identity and access management, continuous monitoring, and best practices, a ZTA can protect against common threats and improve an organization’s security posture by using a managed risk approach.
The document mentions the original genesis of “Zero Trust” to a period before the Jericho Forum in 2004 (which is often mentioned as the start of the zero trust principles), that would be called “Black Core” [BCORE] , which would have been published by the Defense Information Systems Agency (DISA) and the Department of Defense on a more secure enterprise strategy.
Read through the document to find out more about it.
./2-basics
Zero Trust architecture is end-to-end approach to resource and data security that encompasses continuous verification and validation in multiple layers of the infrastructure.
Quote from the document:
The initial focus should be on restricting resources to those with a need to access and grant only the minimum privileges (e.g., read, write, delete) needed to perform the mission.
It is stated that Enterprises and Federal agencies have struggled with unauthorized internal lateral movement.
And though federal mandates have addressed perimeter defense with the Trusted Internet Connections (TIC) for agencies, internal, lateral movement and remote workers are less useful in detecting attacks.
Another quote from the document, looking at Zero Trust from an Operation perspective:
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 utilizes 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 zero trust architecture plan.
An important definition is then made about how ZT and ZTA includes Granular access control to Data and/or Resources.
Alongside Authorization, Authentication ZT(A) will focus on reducing trust zones as much as possible, think of moving away from traditional Inside, Outside, DMZ zones in your firewall to more specific domains with reduced blast radius.
Author’s P.s.: The above is key especially when modernizing applications, to move away from traditional trust zones to more specific, narrower domains.
Looking at how this model looks like, the publication shares an image representing the importance of a Conditional Access Engine, called Policy Decision Point / Policy Enforcement Point (PDP/PEP). This checks the request prior to granting access to the resource.
The document explains what kind of information could then be considered by the policy in order to determine the request’s authenticity. Multiple factors should be taken in consideration, with implied trustworthiness having to be ruled out.
The Implicit Trust Zone is the required area after approval prior to accessing resources, the document uses the analogy of an airport boarding area after security check. This must be as small as possible.
Essentially, the closer that PDP/PEP is to the Resource, the better.
./2.1-Tenets
NIST wants to define ZT(A) by what it includes, not what it excludes (such as the concept of “perimeter”). ZT(A) then is defined by some tenets according to the publication:
- All data sources and computing services are considered resources.
- All communication is secured regardless of network location.
- Access to individual enterprise resources is granted on a per-session basis.
- Access to resources is determined by dynamic policy — including the observable state of client identity, application/service, and the requesting asset — and may include other behavioral and environmental attributes.
- The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
- All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
- The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.
These are technology agnostic.
./2.2-Network
The Enterprise network resources and Enteprises-owned resources must take some ZTA concepts into their own planning and deployment.
The publication highlights these assumptions to these items:
- The entire enterprise private network is not considered an implicit trust zone.
- Devices on the network may not be owned or configurable by the enterprise.
- No resource is inherently trusted.
- Not all enterprise resources are on enterprise-owned infrastructure.
- Remote enterprise subjects and assets cannot fully trust their local network connection.
- Assets and workflows moving between enterprise and nonenterprise infrastructure should have a consistent security policy and posture.
./halt
I will resume this in the next article of this series.
Learn more about my Cloud and Security Projects: https://linktr.ee/acamillo
Consider subscribing to Medium (here) to access more content that will empower you!
Thank you for reading and leave your thoughts/comments!
./references
Scattered throughout the document.