NIST Zero Trust Architecture: Key Points to Learn

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.

Using Micro-segmentation

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.

Conclusion

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.