This post is also available in: 日本語 (Japanese)
It has been over 20 years since the first mobile virtual private network (VPN) products were commercialized. The original intent was for a small subset of the IT industry to leverage VPNs to reach remote systems via the internet. At the time, the idea was not really conceived as a replacement for sitting at a workstation in the office, but more of an emergency solution to perform operations outside of the normal daily routine, especially in critical environments.
VPNs and Their Cybersecurity Gaps
These initial implementations did not offer much on the side of security, but leveraged proprietary clients and often unsecured protocols to grant connectivity back to the office or the data centre. With the evolution of cyberattacks and the wider adoption of the technology, it became clear that mobile access VPN constituted a weak link in the security infrastructure and needed to include stronger features around authentication and encryption.
Things did not progress much further over the following decade. When discussing use cases with businesses, I still find that their perception of mobile VPNs has not evolved from their initial purpose – securely connecting a user to a location.
What certainly evolved is the location’s definition: data, services and applications started spreading over a multitude of cloud platforms, making it very complicated for mobile VPN technologies to keep up with their original mission.
VPN is Dead — Long Live the VPN!
As often happens, when a new problem arises, technology is engineered to solve it. In this case, the solution was found with the creation of a brand new category of products: software-defined perimeters (SDP).
The premise is quite simple. If users need to reach applications that can’t be protected in a single location by a common perimeter, we need to redefine this perimeter and make it flexible to the use case – a perimeter defined by its requirement (SDP).
The Flow Steps:
- A remote user needs access to an application.
- The user’s device connects to the SDP.
- The SDP evaluates the identity of the user and their right to access the application.
- If the SDP evaluation is allowed, the SDP bridges the user device towards the app, regardless of where it is located.
It is a solid plan and it makes perfect sense for this adaptive perimeter to also not be constrained to a physical location. It leverages the ubiquitous nature of the cloud and guarantees users the best experience no matter where they connect from.
So, why do I have Zero Trust Issues here? I have issues because the market shifted from defining these solutions as “Software Defined Perimeter” to labelling them “Zero Trust Network Access” (ZTNA) products.
As any Zero Trust practitioner knows, Zero Trust has been formulated as a change of direction and mentality from perimeter-based security. Its fundamental purpose is to remove implicit trust and continuously validate every digital interaction, regardless if internal or external to a perimeter. Yet, even though we are now dealing with a truly distributed perimeter, for some reason we are still calling it Zero Trust compatible! In my opinion, this is a clear contradiction and it needs to be clarified appropriately.
ZTNA ≠ Zero Trust
Most ZTNA solutions rely on the principles of authentication and authorization in order to grant user access to an application. These are valid components of a Zero Trust framework as they address the identity and destination criteria required to evaluate if the access should be granted. In other words, they remove implicit trust from “who the user is” and “where the user is going.”
Unfortunately, granting access to a resource based on valid authentication and authorization alone is like walking straight on to a plane once the boarding documents and passport are verified. As we all know, it’s not that simple. Security checks are performed before boarding to effectively remove an additional layer of implicit trust and guarantee that a passenger will not carry on-board anything that could potentially harm the plane and its occupants. Full body and carry-on luggage scans are required because the airport cannot implicitly trust anyone on the basis of identity and authorization alone. In the same way, a controller, gateway or connector should not trust traffic simply because it knows who the source users are and what application and data they are allowed to access.
For the typical ZTNA solution, a user must be authenticated before they are granted access to specific applications or services, based on their role and need-to-know basis. However, this approach falls short if no transaction inspection is performed for user traffic after they connect to a service or application.
If the goal is Zero Trust, it simply doesn’t make sense to trust the user with unfettered access to any resource, even if they’ve been limited on the basis of least privilege. This is where ZTNA solutions differ fundamentally in their approach and where the gap lies between ZTNA products and implementing a Zero Trust architecture.
Don’t Trust Remote Access!
Is there a way to achieve true ZTNA while utilizing the full extent of Zero Trust principles? Yes, but only by following the requirements of validating user identity, verifying user’s device integrity, limiting access on the basis of least privilege and also always performing inspection of allowed transactions up to layer seven (application) and down to the detail of the content (threat inspection and data loss prevention) to verify if the connection is trying to abuse any implicit trust within the environment. All these capabilities can be effectively delivered to remote users from a cloud native middle-ware, defined by Gartner as the Secure Access Service Edge (SASE). In a SASE architecture, both network connectivity and security, including Zero Trust capabilities, are effectively aggregated and delivered to remote users by leveraging the power and scalability of the cloud.
Within the SASE, we are able to not only provide seamless-application or data-specific connectivity to users, but also to offer true ZTNA in the way it was meant to be, by removing all layers of implicit trust before allowing traffic through to its destination while continuously monitoring ongoing transactions.
In conclusion, beware of ZTNA point solutions that only partially satisfy the requirements and capabilities for Zero Trust. Leveraging a true Zero Trust framework for remote users is possible, when delivering ZTNA as part of the SASE architecture. With this approach, we can offer exceptional advantages and real security benefits while taking one more step in the removal of implicit trust from the entire enterprise. Learn more about ZTNA and Zero Trust by contacting our experts to discuss the outcomes of a SASE architecture.
Read the first in this blog series, "Why I Have Zero Trust Issues."