ZTNA 1.0’s Allow-and-Ignore Model Is a Recipe for Disaster

In my previous article I described how initial Zero Trust network access (ZTNA 1.0) solutions were designed to protect organizations by limiting their exposure and reducing their attack surface. They essentially work as an access broker to facilitate connectivity to an application. When a user requests access to an application, the access broker authenticates the user and determines whether the user should have permission to access the requested application or service. Once the permission is verified, the access broker grants access, and the connection between the user and his or her app is established.

And that’s it. The agent no longer is in the picture, and the user is now given complete access to whatever is within that application without any additional monitoring from the security system. This dynamic is known as the “allow and ignore” model.

ZTNA 1.0 Follows an “Allow and Ignore” Model

“Allow and Ignore” is very risky. Why is that, you ask? Once the access broker establishes the connection between the user and the application they are trying to access, there is no more interrogation of the user, device, or application. Essentially, the broker presumes that connection is trusted implicitly, or at least for the duration of that session, and all user and device behavior for that session goes unchecked.

Verifying trust only once, without checking again, is a recipe for disaster. More so, it goes against the principles of Zero Trust. In a Zero Trust model, trust is not implicitly assumed, but rather something that should be continuously assessed. After all, a lot can happen after trust is verified. User, device, and application behavior can change; applications can be compromised, and data can be stolen.

Security breaches can’t happen unless someone or something is allowed in to wreak havoc and cause harm. In fact, many modern cybersecurity threats only piggyback on allowed activity to avoid triggering alarms.

ZTNA 2.0 Leverages Continuous Trust Verification

With ZTNA 2.0, continuous trust verification capabilities constantly monitor for potentially malicious or risky changes to device posture, user behavior, and application behavior. This enables the system to respond appropriately in real-time.

For example, has XDR been disabled on the user’s device? Is a user now accessing an app from an unexpected location? Is the traffic running on port 445 actually SMB? If any suspicious behavior is detected, access can be revoked in real-time.

Unlike traditional ZTNA 1.0 approaches that leverage an app broker, ZTNA 2.0 solutions should be deployed in-line with the traffic, to be able to respond and take appropriate action against changes in behavior, providing the best protection for corporate data while ensuring optimal security outcomes for today’s digital workforces.

ZTNA 2.0 Is Zero Trust with Zero Exceptions

The core objective of Zero Trust is to remove implicit trust wherever possible. That’s why continuous monitoring for potentially risky changes to device, application and user behavior is a foundational capability required for ZTNA 2.0. Be sure to watch our ZTNA 2.0 virtual event, where we discuss additional innovations and best practices for securing the hybrid workforce with ZTNA 2.0.

Kumar Ramachandran serves as Senior Vice President of Products for Secure Access Service Edge (SASE) products at Palo Alto Networks. Kumar co-founded CloudGenix in March 2013 and was its CEO, establishing the SD-WAN category. Prior to founding CloudGenix, Kumar held leadership roles in Product Management and Marketing for the multi-billion dollar branch routing and WAN optimization businesses at Cisco. Prior to Cisco, he managed applications and infrastructure for companies such as Citibank and Providian Financial. Kumar holds an MBA from UC Berkeley Haas School of Business and a Master's in Computer Science from the University of Bombay.