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

This post is also available in: 日本語 (Japanese)

ZTNA 2.0 Protects Against Suspicious Activity with Continuous Trust Verification

This is part 2 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.

In my previous post, 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, 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, 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 function required for ZTNA 2.0.

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 third principle of ZTNA 2.0.