What is zero-trust network access? ZTNA basics explained

What is ZTNA?

Zero trust is a security framework that eliminates inherent trust and requires strong, regular authentication and authorization of devices and users. As a zero trust subset, ZTNA — a Gartner-coined term — implements the concept of zero trust in the control of access to enterprise resources at the network level. It hides the network location — IP address — and uses identity-based authentication to establish trust and provide access.

ZTNA specifically does the following:

• controls whether network traffic is allowed to flow based on policy;
• treats policy as dynamic in real time;
• defaults to blocking all traffic;
• allows a traffic flow only when a policy explicitly allows it;
• verifies the identities of all parties to a network flow before allowing it;
• verifies, as best it can, that endpoints are still secure;
• does not grant implicit trust to any entity on the network at any time; and
• can be context-aware, with policies that take into account anything from time of day to geographic location of a user or endpoint.

The implications of ZTNA are important: No user or network is assumed to be trustworthy, no matter the person’s title or role, and no matter where a workload is running or where a session originates. Further, there is no assumption that prior trustworthiness indicates current trustworthiness. Every new flow will be evaluated afresh, because in the time between the previous, allowed flow from User A to User B and the current attempt, User A or User B could have been compromised, or a policy may have changed.

Implementing ZTNA implies preventing unauthorized nodes and users from being able to communicate with or even detect protected systems.

It is important to note that ZTNA is a concept or capability rather than a specific product. Several IT, networking and security suppliers implement ZTNA in different ways. Over time, these suppliers will implement ZTNA to replace aging VPN infrastructure and as part of an overall Secure Access Service Edge (SASE) architecture.

Why is ZTNA important?

Many organizations depend on the internet for users’ access to applications — either on premises through a VPN or through cloud-based, direct internet access. Internet access exposes IP addresses, which can locate users and resources and open them to attack. This visibility, combined with a model that implicitly trusts users and devices, makes the network, users and devices vulnerable.

The enormous growth in the remote workforce during 2020 exacerbated the old security model’s weaknesses. Users may work at home on unsecured consumer devices, on unsecured consumer Wi-Fi, and directly access applications through the internet. VPN technology is designed primarily for corporate-based applications — not cloud environments — and is difficult to scale, manage and troubleshoot.

How does ZTNA work?

The lack of a true security perimeter means users should not and cannot trust internal network connections. ZTNA products and services create identity- and context-based access, as ZTNA hides resources from discovery and provides access through authentication to a trust broker, which acts as a mediator between specific applications and authorized users.

ZTNA decouples access to resources and access to the network, as the internet is an untrusted point of access. The trust broker provides centralized control and management to IT teams, and teams can deploy the broker in data centers as software or an appliance, or they can provide it as a managed service in a cloud environment.

Also, ZTNA unifies access to applications, thus eliminating the bifurcation of private cloud, VPN and SaaS application methods. It provides centralized control, with the scalability and flexibility to offer users appropriate access given their devices, locations and times of day.

A ZTNA deployment should, at minimum, have one or more policy enforcement points (PEPs) that implement the access policies communicated to them by a policy administrator (PA). PEPs can be software clients running on protected nodes — for example, user endpoints, physical servers, VMs or containers — or they can be an appliance or gateway server, or a gateway running as a cloud service.

The PA, which can run on premises, run in an enterprise’s cloud presence or be offered via SaaS, decides whether specific network communications will be allowed or blocked.

How to implement ZTNA

After selecting a ZTNA product or service, most organizations take a phased implementation approach.

First, run the product or service in discovery mode to see where all the flows are, and begin to map out the access policies that will support current usage. Also, start spotting anomalies.

Next, implement a pilot use case built around a well-defined and limited subset of users and services, working out the kinks in the onboarding processes for both users and services during that pilot. After the pilot, expand ZTNA deployment, use case by use case.

Benefits of ZTNA

The potential benefits of deploying ZTNA in the enterprise include the following:

• simplified control of application and network access by unifying it under one product or service — for example, one ZTNA instead of several VPNs, virtual desktop infrastructures (VDIs) and internal firewalls;
• unified access controls for on-premises and off-premises users and systems if the ZTNA works for both;
• more granular access controls and context-sensitive policies; and
• reduced risk of lateral movement and, therefore, lateral attacks within an infrastructure, either by external bad actors or by malicious insiders.

Also, note that many cloud offerings only support access from remote sources to protected destinations but cannot protect a system from a user in the same building or from a different system in the same data center.

[embedded content]

Challenges of ZTNA

The main challenges of ZTNA include the following:

Mapping access rights. Deciding on and defining who or what needs access to what data and resources requires time, effort and sometimes additional tools.

Entrenched products and services. Winning political battles with people who are all-in on an incumbent technology or vendor can be a challenge to getting a ZTNA project launched and expanding it into all logical use cases. Expect the oppositional position to be, “If we evaluate the ZTNA as a VPN replacement, it is not as good as our existing VPN.”

Objections will often center on specific scenarios for which the new product or service may be less suitable than the old one, even if they are small edge cases. Opponents also will focus in on functionality the existing product or service provides that the new one does not, even if it is functionality the organization does not use or require.

The main strategy against this kind of resistance is to emphasize where and how ZTNA is better at controlling access and how it can simplify the lives of users and IT staff, as well as how the more it replaces, the more likely it is to save time and money while improving security.

End-user friction. Many organizations have seen hard pushback based on the “need” to avoid disruption to end users. Most IT departments have had a few seriously failed deployment projects that foundered on resistance to change among the user population. Such events have a long-tail effect on IT’s credibility in future deployment efforts.

Forcing staff to change what they do or how they do it while providing the same service — such as remote access, for example — is hard to justify if IT doesn’t trumpet, early and often, the ways in which the replacement will serve them better, be more reliable and be easier to use.

Cost. A ZTNA system can cost a lot. It can be hard to justify if it is not displacing other spending. IT and cybersecurity should be diligent and creative in identifying and pursuing offsetting savings as a part of the deployment planning for ZTNA.

Policy beyond the laptops, desktops and mobile devices. Building consensus on how to handle non-managed devices and IoT devices can be difficult, and the product or service may not offer much help for IoT devices that can’t run a client. That doesn’t mean IoT systems don’t need zero trust; it just means they may need a separate zero-trust initiative.

ZTNA use cases

Enterprise security is rapidly shifting to zero-trust approaches to help mitigate the constantly escalating risks of breach and compromise, especially from ransomware.

The main use cases for ZTNA include the following:

• Remote work/VPN replacement. Gated access to a network with multiple resources is replaced with the ability to see only the resources one is allowed to use and reach them only in the ways allowed.
• Internal firewall replacement. ZTNA clients on each server — physical or virtual — control access and securely separate resources by policy instead of via physical network separation.
• Network access control replacement. ZTNA clients perform or consume health checks to determine if a node is trustworthy enough to join the network. They also help enforce policies about what a node can do while on the network.
• Terminal services/VDI replacement. ZTNA can replace VDI and terminal services when they are being used to provide identity-based access control to resources instead of providing LAN-equivalent access — for example, access to software that cannot handle WAN latency — or when they are being used to keep data physically in a specific place.
• Private WAN replacement. When a private network exists primarily to secure user access to internal resources, ZTNA over the bare internet can replace the private connectivity.

ZTNA vs. VPN

A VPN controls access to networks, not individual resources on the network. Traditionally, VPNs have been appliance-based, meaning access though a VPN controller allows access to all resources on the protected network behind it. The need to implement multiple segregated environments traditionally requires having a VPN controller for each, managed separately from each other.

By contrast, a ZTNA would manage all access to all sets of resources through the one policy engine and enforce all those policies via the same set of policy enforcement points.

ZTNA vs. SDP

The idea of a software-defined perimeter (SDP) grew out of Air Force research that predates the broader concept of zero trust. They both have the same objective: allowing packets to flow among network entities only if a policy explicitly allows that packet to flow.

The distinctions are pretty minor, and it is therefore reasonable to treat ZTNA as SDP 2.0.

ZTNA vs. SASE/SSE

SASE is a broader concept, and ZTNA is only one of the main functional pillars associated with SASE and security service edge (SSE). Other aspects of SASE include cloud access security broker functionality, secure web gateway functionality, firewall-as-a-service functionality and SD-WAN functionality. Note that the lack of SD-WAN makes something an SSE as opposed to a SASE.

ZTNA vendors and products

Just about any product or service provider promising SASE or SSE services should provide a cloud-modeled ZTNA service that can, at a minimum, fill the VPN use case for remote users. Such vendors include Cato Networks, Cloudflare and Zscaler.

ZTNA can also be approached from a more appliance-based angle, so vendors such as Fortinet also offer ZTNA.

SDP vendors such as Appgate and Illumio offer products and services that can be on-premises-based or in the enterprise’s cloud. These may develop into hybrid on-premises and SaaS offerings as well.

Editor’s note: This article includes previous coverage by Lee Doyle.