Zero Trust Network (ZTNA) - What is it for, How to use it?
By Douglas Bernardini
Zero Trust Network Access (ZTNA) is the technology that makes it possible to implement a Zero Trust security model. “Zero Trust” is an IT security model that assumes threats are present both inside and outside a network. Consequently, Zero Trust requires strict verification for every user and every device before authorizing them to access internal resources.
ZTNA is similar to the software-defined perimeter (SDP) approach to controlling access. In ZTNA, like in SDP, connected devices are not aware of any resources (applications, servers, etc.) on the network other than what they are connected to.
Imagine a scenario in which every resident gets a phone book with the phone numbers of every other resident of their city, and anyone can dial any number to contact any other person. Now imagine a scenario in which everyone has an unlisted phone number and one resident has to know another resident’s phone number in order to call them. This second scenario offers a few advantages: no unwanted calls, no accidental calls to the wrong person, and no risk of unscrupulous persons using the city’s phone book to fool or scam the residents.
The ZTNA is like the second scenario. But instead of phone numbers, ZTNA uses “unlisted” IP addresses, applications, and services. It sets up one-to-one connections between users and the resources they need, like when two people who need to contact each other exchange phone numbers. But unlike two people exchanging numbers, ZTNA connections need to be re-verified and recreated periodically.
ZTNA vs. VPN
Virtual private networks (VPNs) are what many organizations use to control access instead of ZTNA. Once users are logged in to a VPN, they gain access to the entire network and all the resources on that network (this is often called the castle-and-moat model). ZTNA instead only grants access to the specific application requested and denies access to applications and data by default.
There are differences between ZTNA and VPNs on a technical level as well. Some of these differences include:
- OSI model layer: Many VPNs run on the IPsec protocol at layer 3, the network layer in the OSI model. ZTNA typically operates on the application layer. (Some VPNs do run on the application layer using the TLS protocol for encryption instead of IPsec; ZTNA usually has a similar approach.)
- Endpoint software installation: IPsec VPNs require the installation of software on all user devices. This is sometimes the case for ZTNA, but not always.
- Hardware: VPNs often require the use of on-premise VPN servers, and user devices connect to these servers, typically by getting through their organization’s perimeter firewall. ZTNA can be configured in this way, but most often is delivered through the cloud, enabling users to connect from anywhere without impacting network performance.
- Level of connectivity: ZTNA sets up one-to-one encrypted connections between a user’s device and a given application or server. VPNs give users encrypted access to an entire LAN all at once. If a user’s IP address connects with the network, it can connect with all IP addresses on that network.
Finally, VPNs are imprecise, largely treating users and devices the same, regardless of where they are and what they need to access. With “bring your own device” (BYOD) approaches becoming increasingly common, it is dangerous to allow this access, as any malware-compromised endpoint can then infect an entire network. For these reasons, VPNs are a frequent attack target.
How does ZTNA work?
ZTNA is configured slightly differently by each organization or vendor. However, there are several underlying principles that remain consistent across ZTNA architectures:
- Application vs. network access: ZTNA treats application access separately from network access. Connecting to a network does not automatically grant a user the right to access an application.
- Hidden IP addresses: ZTNA does not expose IP addresses to the network. The rest of the network remains invisible to connected devices, except for the application or service they are connected to.
- Device security: ZTNA can incorporate the risk and security posture of devices as factors in access decisions. It does this by running software on the device itself (see “Agent-based ZTNA vs. service-based ZTNA” below) or by analyzing network traffic to and from the device.
- Additional factors: Unlike traditional access control, which only grants access based on user identity and role, ZTNA can evaluate risks associated with additional factors like user location, timing and frequency of requests, the apps and data being requested, and more. A user could sign in to a network or application, but if their device is not trusted, access is denied.
- No MPLS: ZTNA uses encrypted Internet connections over TLS instead of MPLS-based WAN connections. Traditional corporate networks are built on private MPLS connections. ZTNA is built on the public Internet instead, using TLS encryption to keep network traffic private. ZTNA sets up small encrypted tunnels between a user and an application, as opposed to connecting a user to a larger network.
- IdP and SSO: Most ZTNA solutions integrate with separate identity providers (IdPs), single sign-on (SSO) platforms, or both. SSO allows users to authenticate identity for all applications; the IdP stores user identity and determines associated user privileges.
- Agent vs. service: ZTNA can either use an endpoint agent or be based in the cloud. The difference is explained below.
Agent-based ZTNA vs. service-based ZTNA
Agent-based ZTNA requires the installation of a software application called an “agent” on all endpoint devices.
Service-based or cloud-based ZTNA is a cloud service rather than an endpoint application. It does not require the use or installation of an agent.
Organizations looking to implement a Zero Trust philosophy should consider what kind of ZTNA solution best fits their needs. For example, if an organization is concerned about a growing mix of managed and unmanaged devices, agent-based ZTNA may be an effective option. Alternatively, if an organization is primarily focused on locking down certain web-based apps, then the service-based model can be rolled out swiftly.
Another consideration is that service-based ZTNA may integrate easily with cloud applications but not as easily with on-premise infrastructure. If all network traffic has to go from on-premise endpoint devices to the cloud, then back to on-premise infrastructure, performance and reliability could be impacted drastically.
What are other important ZTNA solution considerations?
Vendor specialization: Because identity and access management (IAM), network services, and network security traditionally have all been separate, most ZTNA vendors typically specialize in one of these areas. Organizations should either look for a vendor with an area of specialization that fits their needs, or one that combines all three areas into one cohesive solution.
Level of implementation: Some organizations may have already invested in adjacent technology to support a Zero Trust strategy (e.g. IdP or endpoint protection providers), while some may need to build their entire ZTNA architecture from scratch. ZTNA vendors may offer point solutions to help organizations round out their ZTNA deployments, create entire ZTNA architectures, or both.
Support for legacy applications: Many organizations still have on-premise legacy applications that are critical for their business. Because it runs on the Internet, ZTNA supports cloud applications easily but may need additional configuration to support legacy applications.
IdP integration: Many organizations have an IdP already in place. Some ZTNA vendors work only with certain IdPs, forcing their customers to migrate their identity database to use their service. Others are IdP-agnostic — they can integrate with any IdP.