This post is also available in: 简体中文 (Chinese (Simplified)) 繁體中文 (Chinese (Traditional)) 日本語 (Japanese) 한국어 (Korean)
This is part 1 of a 5-part series, “ZTNA Straight Talk,” where we take a closer look at the five tenets of ZTNA 2.0, the new standard for securing access.
The concept of Zero Trust – the removal of all implicit trust from our networks and digital transactions – is universally endorsed as the best approach to secure organizations today. However, as Nir Zuk pointed out recently, existing Zero Trust Network Access solutions contain five alarming deficiencies that put organizations at risk:
1) They violate the principle of least privilege.
2) They “allow and ignore.”
3) They don’t perform security inspection.
4) They fail to protect data.
5) They only protect a subset of enterprise applications.
The first failure, which I’ll focus on today, explores how ZTNA 1.0 violates the principle of least privilege.
The principle of least privilege is an information security concept, dictating that only the minimum amount of access required should be granted to a user or entity to conduct their work. The idea is that limiting access to the bare minimum will reduce your exposure if something goes wrong.
Least privilege is fundamental to a Zero Trust posture and is often claimed by ZTNA 1.0 providers as “built-in” to their solutions. However, an architectural deficiency in ZTNA 1.0 leaves a large gap in their ability to deliver on this concept.
Before we can discuss what’s wrong with ZTNA 1.0, we first need to talk about remote access VPNs. VPNs have long been used to provide remote access to corporate networks. While this approach of granting broad access to entire networks was never ideal, there were no practical alternatives, and it was deemed acceptable because it was infrequently used by only a relatively small number of users who were “trusted” once they were connected. However, the rapid shift to hybrid work and the sophistication of modern threats (especially attacks that involve lateral movement) have finally rendered traditional VPN obsolete.
ZTNA was intended to solve one of the biggest challenges of VPN by limiting users’ access to only the specific applications they need, rather than entire networks. However, the way vendors implemented ZTNA 1.0 solutions essentially translated an application into Layer 3 or Layer 4 network constructs like IP (or FQDN) and port number. This limitation requires the administrator to paint with a broad brush when writing access control policies, ultimately granting far more access than intended.
For legacy applications where the application components use static IP addresses and port numbers, the approach of using IP/Port to identify an application can be acceptable. However, almost every enterprise these days use cloud-native applications that provide several capabilities, each of which is delivered via separate URLs, or similar higher-order concepts. Similarly, business applications commonly use dynamic IPs and ports, server-initiated connections, and other scenarios where creating static access control policies based on IP and port alone completely breaks.
As I discussed earlier, the principle of least privilege is all about providing the minimum amount of privilege possible for users to get their work done. To address SaaS and other modern apps that use dynamic IPs and ports, ZTNA 1.0 solutions require you to allow access to broad IP and port ranges in order to get the access control (and application) to even work. This clearly violates the principle of least privilege as it creates a huge hole in your network that can be exploited by an attacker or malware.
With ZTNA 2.0, the system can dynamically identify the application and the specific function within the app across any and all protocols and ports using App-ID, regardless of what IPs and ports the app might be using. For administrators, this eliminates the need to think about network constructs and enables very fine-grained access control to finally implement true, least-privilege access.
The next type of app that doesn’t play nicely with ZTNA 1.0 solutions are apps that require connections to be established from the server to the client. This includes mission-critical applications such as update and patch management solutions, device management apps, and help desk apps. The way ZTNA 1.0 has been implemented by many vendors, it only works when your users initiate these connections, and doesn't allow app or server-initiated connections at all. We have seen numerous examples where customers have tried to implement ZTNA 1.0 solutions, but were forced to maintain their legacy VPN solution purely to solve this use case!
ZTNA 2.0 solutions like Prisma Access, which allow bi-directional access control using App-IDs to define application access policies, can easily enable least privilege access for all types of apps, including apps that use server-initiated connections.
Many private applications lack the built-in, fine-grained access control capabilities that exist in most modern SaaS apps. Something as simple as allowing users to access an application to view data, but not upload or download data, is simply not possible in a ZTNA 1.0 solution where the app is identified purely based on IP address and port number only. Providing this level of granular control at the sub-app level (i.e. to specify access to an app, but restrict upload/download) is trivial for ZTNA 2.0 solutions that leverage App-ID constructs to identify apps and sub-apps).
In a world where applications and users are everywhere, embracing the principle of least privilege is critically important to adopting Zero Trust effectively and reducing an organization’s risk. As discussed, ZTNA 2.0 enables precise access control for all types of applications, independent of network constructs like IP addresses and port numbers. This is a significant leap forward in securing access and finally enabling us to move away from legacy, remote access VPNs.
Watch our ZTNA 2.0 launch event, where we’ll discuss innovations and best practices for securing the hybrid workforce with ZTNA 2.0. Stay tuned for the Palo Alto Networks blog next week, where I’ll discuss the second principle of ZTNA 2.0.
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.