The National Institute of Standards and Technology recently released a draft special publication for Zero Trust Architecture (ZTA), with the aim of establishing a standard classification criterion for ZTA components. (Note, as of February 2020, NIST has released draft 2 of the Zero Trust Architecture Guidance).
What Is Zero Trust Architecture?
Zero Trust can be defined as the act of creating micro-perimeters around small resource groups beneath the traditional wide network perimeters for additional data security. The project was first developed by Forrester Research and has seen tremendous growth in popularity. Firms desperate to patch up as many vulnerabilities as possible in their network security systems use it.
Traditional security architecture assumes anything contained within a firm’s network is trustworthy, and thus only works towards preventing attacks from outside. The fact is, threats can arise from within a network, and any company relying on conventional security methods may not be able to detect them, let alone trace their origins. The wide network perimeters only capture what tries to go through them. If someone manages to bypass it, they will be free to run rampant and have access to all company data.
The prospect of an internal attack is the drive behind Zero Trust’s recent rise to prominence. ZTA is based on the philosophy “never trust and always verify”. Further, it aims to prevent lateral movement of threats within the network. This means undetected attacks will not automatically have access to everything in the organization’s database upon breaching the outer perimeter.
NIST, in its publication, breaks down the components of ZTA and some of the network assumptions ZTA enterprise network design is based on. Also, it gives an insight into the fundamentals of ZTA design. It also acknowledges that design can take different modi operandi but still achieve the same end product.
The Principles of ZTA Definition
NIST reckons that Zero Trust architecture is yet to find a definition that entirely covers the concept and shows how it differs from conventional security systems. The institution’s view is that ZTA definition must not necessarily bear anti-perimeter connotations. In its idealized delineation of Zero Trust, the following tenets should be adhered to:
Resources
All computing services and data sources are considered resources. All devices that access a firm’s resources can be regarded as resources regardless of whether the devices themselves are the enterprise’s property.
Threats
Every device is a threat.Requests for access from devices inside the network should go through the same security checks as devices from outside the enterprise-owned network.
Evaluation
Access comes after evaluation. Devices cannot connect to resources before being evaluated. Also, access grant to one resource does not make other resources automatically available to the requester.
Access
Access requests should be aligned with expectations. An organization should know all the resources it has and the specific data that various users would require. User accounts should be assigned these attributes and access should be granted to users whose attributes match the requests they make.
CDM Program
A CDM program should precede ZTA implementation. All enterprise-owned devices and systems should be checked beforehand for vulnerabilities. ZTA should only be run when everything has been scrutinized, and necessary patches have been applied. Connection requests from non-enterprise-owned devices may be treated differently after this.
Besides the tenets, NIST insists on the importance of being pessimistic while developing the network for ZTA implementation. The institution advises that, for enterprise-owned network infrastructure, systems should be built to act as if there is an attack on the network already. This can be done by not granting automatic access to some data even if the requester has been authenticated in an earlier stage. For non-enterprise-owned networks, NIST warns against trusting foreign networks. The networks should instead be treated as extremely hostile.
What Logical Components Make Up Zero Trust Architecture
According to NIST, the several logical components that a Zero Trust system is made can be condensed into three levels: the Policy Engine, the Policy Administrator, and the Policy Enforcement Point. The Policy Engine (PE) is charged with deciding who gets and who doesn’t get access to the enterprise’s resources. Further, it makes the access decision based on several factors and lets the Policy Administrator (PA) execute it. The PA can only connect a user to a resource if the PE deems the connection safe.
The functioning of these components is enabled by several local and external data sources that together make up the full access algorithm. They include CDM systems, Threat Intelligence Feeds, Data Access Policies, the Industry Compliance System, the ID Management System, and the SIEM system.
NIST believes logical components do not have specific duties they should handle. It may be recommendable to assign different responsibilities to different hardware or software systems, albeit having the same system handling the work of two or more core components will not affect performance.
The Access Decision-Making Process
The PE, which is responsible for granting or denying access to enterprise resources, runs on a process NIST calls the Trust Algorithm. Further, NIST provides these two approaches to Trust Algorithm conception:
- Criteria vs Score-Based Trust Algorithms
- Singular vs Contextual
Criteria-based Trust Algorithms assume attributes that must be met before access to specific resources is granted. A score-based Trust Algorithm, on the other hand, creates score thresholds and allows access to users who meet these thresholds. The scores are attained by adding up values assigned to different data sources. Singular Trust Algorithms make evaluations without regard to user history. The assessment of each request is done from scratch. This is the opposite of contextual Trust Algorithms whose evaluation process is based partly on the requester’s recent access history. NIST vouches for contextual TAs as the PE retains information on the access patterns of specific users. Indeed, attackers using genuine credentials can be detected if using a different pattern from the user.
Zero Trust Architecture Has Its Shortcomings
While ZTA can immensely reduce the risk of large-scale attacks from within, NIST warns organizations against thinking they are completely covered with Zero Trust. Threat risks to be aware of include subversion of the decision process by a user who has access to the Policy Engine and Administrator. DoS attacks can also cause disruptions on the enterprise’s operations as no action can be executed without permission from the PA.
Implementing a ZTA Strategy
Adopting Zero Trust Architecture is a process NIST advises against rushing into. Organizations must consider existing federal rules and guidelines in the planning phase. They must also ponder the adjustments that must be made to accommodate the system. After this, all assets and users must be cataloged and matched with the resources they can access from their accounts.
Implementation
Adopting a ZTA requires planners to have a detailed understanding of business processes, users, and physical and virtual assets in their network. This goes beyond just cataloging what the organization owns. Zero Trust Architecture also needs to be able to identify non-enterprise-owned devices accessing the enterprise’s network and resources.
ZTA implementation without sufficient knowledge of these factors may cause the PE to deny requests from employees and clients wrongly, and massively impact the overall user experience.
NIST urges organizations to consider taking comprehensive surveys of their users and assets, including anticipated changes, before planning a ZTA. The difficulty of implementation will partly be down to the number of users and systems that need to be integrated into the system. The presence of a network before the new installation may also have an impact.
For Businesses
In Greenfield projects, NIST believes organizations can build Zero Trust Architecture networks without the need for significant adjustments or leaving out some systems and assets. As long as the organization has a record of all its workflows, identifying the crucial components and mapping how they need to interact with each other should be an easy feat. For enterprises that have an existing network, this may not come as a workable strategy. However, Zero Trust concepts are useful where an enterprise needs to fulfill responsibilities with its own infrastructure. For instance, if an agency is requested to fulfil a responsibility that involves creating software and its database, they could base the design on the tenets of Zero Trust Architecture, such as having members evaluated before being granted access to resources.
Identification
In regards to identifying ZTA candidate workflow, NIST believes process importance and users affected should be considered. Once candidate business processes have been identified, the enterprise can start identifying solutions. On this one, NIST urges architects to ask themselves these two questions:
- Does the solution call for the installation of components on non-enterprise-owned devices that access the enterprise-owned network?
- Does the solution support situations where resources are located in enterprise premises and not in the cloud?
Upon identification of candidate workflow and Zero Trust components, you can kick off the deployment process. According to NIST, architects should consider executing the developed policies in a lenient manner. Then, be ready to adjust policies to improve user experience.
Learn More About Zero Trust Architecture
Download our guide to Zero Trust Security in Microsoft 365 for more information on ZTA building. You can also reach us by contacting us through here.
Published on: .
Sales@AgileIT.com