Key Points to Learn About the NIST Zero Trust Network Architecture
The encroaching advent of cyber-attacks has evolved in leaps and bounds, such that it has forced our minds to think of innovative ways to augment digital security. The National Institute of Standards and Technology (NIST) proposed a new cyber-security framework called the ‘Zero Trust Network Architecture Model’ (ZTNA).
The NIST Zero Trust framework was introduced towards the end of 2020 to overhaul the digital security paradigms. This was done to equip organizations and help them tackle modern attacks, malware types, and intrusion mechanisms.
Zero Trust - What is it?
The NIST’s latest proposal in its SP 800-207 publication discusses the birth of a new set of cyber-security protocols. These protocols are designed to establish a new security paradigm that defends dynamic, network-based users, assets, and resource parameters. Modern web services rely on a vast cross-section of network endpoints that stretch their perimeters and render their cyber-security thin.
The Zero Trust Network Architecture (ZTNA) negates the scope of trust principles for planning industrial and enterprise workflows and architecture. NIST ZTNA does not assume any level of implicit trust for user accounts and assets, with physical and network location or asset ownership as the basis, even when the assets are enterprise or personally owned. It always guarantees standardized authorization and authentication before establishing every enterprise resource session.
Let’s have a look at some of the network security pain points that the framework aims to address.
Why invest in NIST’s Zero Trust Policy?
The NIST serves as a non-regulatory federal agency, one of whose many missions is to augment American cybersecurity standards. The NIST highly stresses a mandate for trusted users in every network topology.
The ZTNA hopes to uphold the severity of this diktat with a framework based on the following prominent concepts:
Addressing network endpoints and perimeter security challenges
ZTNA grants no implicit internal trust privileges to assets or user accounts based on physical network locations and asset ownership.
Resultantly, these parameters are no longer the prime deciding factors for attributing security to a given network resource. Hence, the services, workflows, assets, network accounts, etc., are better protected than the network segments.
Mandatory authentication and authorization for every session
The NIST ZTNA also proposes to make authentication and authorization stringent for every user and device on a given network. As per the ZTNA, every instance of such components on a network topology must begin with these two discrete functions.
Post verification, components are allowed to establish connectivity to the network itself or avail resources. We can consider an “implicit trust zone” to include only the entities that can be trusted to reach the given endpoints in the network topography. The level of resource trust is dependent on the last PDP/PEP gateway passed.
Elimination of inherent trust for components outside of the network jurisdiction
There is a trend among modern enterprises and IT users for engaging in remote computing and networking. This trend of Bring-Your-Own-Device (BYOD) and cloud-based assets is not traditionally a part of the enterprise network boundary, as it increases the scope of intrusive attacks.
The ‘never trust, always verify’ policy helps decrease the vulnerabilities stemming from malware residing on access points that do not traditionally fall within the network jurisdiction.
Thus, every fresh instance is checked for identity verification, and there is no scope for an unauthenticated or unauthorized component to log on.
Bridging resources to PDP/PEP gateway verification
The whole concept of NIST Zero trust hinges on strengthening the Policy Decision Point and Policy Enforcement Point's role in gatekeeping your network.
However, the possibility of getting a sanction by the PDP and PEP sanction for your connection and network is mainly dependent on the following points:
The device identity
The connection profile is based on information gathered from the handshaking protocol and the device's behaviour on the network.
The user identity
A user profile is based on the proper security credentials, the devices they use to access the network, and the segregation of device accesses based on existing trust policies or the lack thereof.
Nature of the request
The intentions with which a connection request is made to the network are essential for granting access. The framework determines whether a genuine person/process/sub-process/network operation has triggered the request with the right level of authorizations.
Augmenting network topology/architecture
The NIST ZTNA framework helps the policy engine take critical access decisions based on the following pivotal inputs:
Continuous diagnostics and mitigation systems
A well-delivered architecture collates information about an enterprise’s asset states and updates software components and configuration.
Threat intelligence feeds
Delivers information on internal and external sources to influence the policy engine’s capabilities. Helps unmask undiscovered flaws and loopholes in security and vulnerabilities.
Network and system activity logs
An aggregation of real-time network traffic info enables people to take action on resources, real-time event feedback. This helps strengthen the enterprise’s security posture.
Data access policies
Set the rules, policies, and attributes that a network resource must possess to gain access to a system.
Enterprise public key infrastructure
The network will register the logging certificates for services, applications, resources, and subjects.
ID management systems
User account and ID record create, read, update, and delete (CRUD) system.
Industry compliance systems
Synchronizes security protocol agendas with that of regulatory body compliance protocols.
Security information and event management (SIEM) system
A repository of security-centric information for posterior analysis. It helps identify the loopholes mentioned above, vulnerabilities, and concerns in a network topography.
How to implement ZNTA over existing network architectures?
Using Network Infrastructure and Software-Defined Guidelines
Software Defined-Networks and Intent-Based networks can help define the security of the lower OSI stack. Agent/gateway models can help overlay these NIST Zero Trust framework essentialities over the application layer. The Agent/gateway act as a single PEP to help establish secure data exchange and communication channels between the client and the resource.
Using Enhanced Identity Governance
Enterprise access policies are based on identity and assigned attributes. Factors such as granted privileges, used devices, asset statuses, and programming environment, help tailor the extent to which accessibility is granted.
Micro-segmentation simplifies ZNTA implementation by segregating your network resources into clusters. Access is granted on a dynamic basis upon request only. The protocol may or may not use multipart PEP depending upon security infrastructure availability.
To summarize the tenets of the NIST ZTNA:
- Accessibility must be granted on a ‘per session’ basis
- Limiting unauthorized/unauthenticated accessibility to data, services, infrastructure by mandating dynamic authentication and authorization
- Granularizing accessibility and control decisions
- Every data source and computational element in the topography is a resource
- Both external and internal communication must be secure at all times
- Build a detail-rich profile of the network and infrastructure
- Constant monitoring for the device security state
To implement ZNTA unilaterally, the model must include better support for:
- Peer-to-peer technologies
- Technical debt
- Legacy systems
- Digital transformation
Critics have already verified that in the modern web-service scenario, the ZNTA protocol can guarantee a Layer 7 threat protection model, especially if it is implemented properly.