Zero Trust Network Access (ZTNA) is the latest security model being pushed by vendors and analysts as the next step in cyberdefense. It is often coupled with calls to deprecate, replace or kill VPN, a technology that has been a mainstay of remote access infrastructure for over 30 years. While it may be too early to rip and replace VPN for a ZTNA solution, especially as many companies will have heavily invested into scaling VPN architecture to accommodate a remote workforce, there are merits in beginning the transitioning to a Zero Trust model, and in particular Software-Defined Perimeter (SDP) technology.

How does SDP relate to ZTNA?

ZTNA is an approach to network security consisting of several security concepts, it is not a single principle and currently not one single solution, however, in the future, there will likely be vendors that do provide a complete suite. As outlined in Gartner’s Market Guide for ZTNA, there are two current forms with the favored deployment being Endpoint-Initiated based on the Cloud Security Alliance’s SDP architecture.

What are the differences between SDP and VPN?

The efficacy of remote access solutions can be judged by three criteria: strength of security, ease of management, and end-user experience. ZTNA is seen as the next generation of remote access technologies because it resolves many of the security, management, and user experiences shortcomings that come in tow with VPN.

Gartner predicts that by 2023, 60% of enterprises will phase out most of their remote access virtual private networks (VPNs) in favor of ZTNA.

VPN SDP
Security
  • Access before authentication
  • IP-based access
  • Network access is needed for access to applications
  • Open ports exposed to the internet
  • No device risk assessment
  • Difficult to enforce least privilege access
  • Authentication before access
  • Identity-centric access
  • Isolated application access to any application
  • Makes applications invisible until a user’s identity has authorized and authenticated
  • Continuous risk assessment at the device, user and application levels
  • Least privilege access through IAM integration
  • Secure access for any application, cloud or on-premise regardless of user location
Management
  • Heavily appliance-based
  • Inflexible infrastructure and static capacity
  • Administrative overhead of management
  • Susceptible to misconfiguration as well as dependent on the configuration of other technologies
  • Cloud-delivered
  • Dynamically scales according to business needs
  • Infrastructure management outsourced to the service provider
  • Integrates with IAM, SIEM and other parts of the technology stack
User Experience
  • Fragmented access experience and a constant need to re-authenticate
  • Only provides access for remote users
  • Unreliable on Wi-Fi and cellular connections as well as mobile devices
  • Legacy design creates speed and connectivity issues
  • Consistent access across device types and platforms
  • Provides the same access experience for remote users as well as workers on site
  • Efficiently handles network transitions and built for all device types
  • Distributed service edge allows for efficient routing to mitigate latency
  • Seamless authentication and SSO

Security

Although VPN has been traditionally used to provide remote workers with access to corporate resources, it’s only real security features are user authentication at the point of activation and encryption from the endpoint to the VPN appliance. In comparison, ZTNA is fundamentally security-driven, offering enhanced authentication and encryption while also adding other modern features.

Authentication

Traditional VPN is reliant on IP addresses to provision network access, this is problematic as an IP address provides no information about the user or device, and therefore shouldn’t be implicitly trusted even if it is a local address. User’s IP addresses also change frequently, accessing services from multiple devices, including personal; managing access based on IP becomes difficult to manage with more and more users.

Signing into a VPN is just like any other service: username, password, maybe Multi-Factor Authentication, such as a token or certificate, as well. Users are authenticated at the start of a VPN session to connect to a local network and thereon for application access. However, there is no risk assessment of the device, upfront, or throughout the course of the session. Just because a worker is able to prove their identity, this shouldn’t vouch for the health of the device. The endpoint could be harboring malware or there may be vulnerabilities such as an out of date OS, devices could also become compromised during the course of a session.

70% of Successful Breaches Originate on the Endpoint – IDC

VPN authentication protocols require open ports to be exposed to the internet, this provides attackers with information about the services that sit behind the perimeter and a target to attack. Authentication needs to happen before any services can be discovered.

ZTNA solutions integrate with IAM services in order to easily enforce users’ identity policies used by the business elsewhere and ensure that each user is assigned the correct permissions for their function and role. The use of Single Packet Authentication (SPA) requires the identity of the user before brokering access to the requested service, so only connection attempts from authorized users are recognized, making applications dark to anyone else

One of the big differentiators of SDP-based ZTNA is that it allows contextual risk to be considered during the assessment of the access request. The use of adaptive (or conditional) access controls ensures that an endpoint complies with security policy as well as assesses other factors like geolocation and time of the request. This is particularly pertinent in the case of BYOD and unmanaged devices (as with third parties) where there is a lack of oversight of the device and no guarantees as to whether baseline security requirements are met. Furthermore, a user’s session can be monitored in real-time, if the access policy requirements are no longer being met, access can be dynamically restricted.

Network Access v Application Access

A VPN is typically a blunt instrument when it comes to remote access, giving broad visibility and reachability to applications and resources on the network. VPN is IP-based, often providing a user with a local address, as if they were physically on the network, to access any tool. This access is unnecessarily broad, a Sales Person doesn’t need visibility of Finance’s accounting software, it’s completely irrelevant to their role.

Nearly 60% of attacks now involve lateral movement. – VMWare

IT teams can create network segments to limit lateral movement from VPN connections, but this is often difficult to set up and manage, particularly when opening up digital ecosystems to partners. Sometimes these partners will need access to just one system, sometimes a department’s entire suite of applications. For example, an auditor needs access to financial records but does not need to see the CRM. VPN fails to effectively offer the granularity of access to adequately reduce a company’s attack surface.

With perimeter-based security (and VPN), the assumption is that users/devices on the network can be trusted. If someone is coming from an internal IP or has been given one by their VPN, this trust is extended to them.

SDP moves away from a network-centric approach, creating an isolated, private tunnel between each user and application avoiding the need to configure ACLs or Firewalls. As SDP is identity-centric, least privilege access can be enforced based on the user’s individual permissions universally due to a centralized policy engine. Rather than providing access to the underlying network, users are simply routed to the application. This ultimately removes the network location point as a position of advantage and also eliminates the excessive implicit trust that IP addresses offer.

Cloud Protection

Despite VPN services connecting remote users to the corporate network, they are unable to encrypt traffic to cloud applications and leave those connections vulnerable to attacks. Unlike applications that are hosted on-premise, VPN is optional for remote users wanting to connect to cloud applications, any form of protection offered by the corporate network is lost if the user decides to connect directly.

SDP brokers the connection between users and cloud applications, ensuring that appropriate authentication is applied and that only authorized parties are able to see and access the application. Some application suites like Microsoft 365 have Zero Trust technology built-in, for them, ZTNA augments secure access with device risk posture information but doesn’t broker or route traffic.

Management

Configuration & Vulnerabilities

A quick Google search reveals that VPN has numerous vulnerabilities and is easily misconfigured, particularly when integrating with other technologies. Last year, the NCSC investigated the exploitation of vulnerabilities in SSL VPN products from a number of top tier vendors. And recently, the NSA published guidance on how to secure IPsec VPNs. To enforce a degree of network segmentation, multiple VPNs can be deployed, but each of these requires their own appliances, management, and configuration. What’s more, it is never neat. IT admin has to configure and manage each of these VPNs and when policy changes occur they have to go through and update each, taking a lot of time just to maintain the service.

Another maintenance problem with VPN is that they’re expected to be always available, particularly in times when such a big proportion of the workforce is working remotely, so security patching, configuring and hardening doesn’t get done.

With SDP, the burden of infrastructure maintenance sits with the service provider, they are responsible for making sure that any vulnerabilities are patched immediately. Being an overlay technology, configuration is far simpler and can be neatly integrated with existing technologies like UEM, SIEM, IAM, and so on through the use of APIs. As access policies are formed and applied based on a user’s identity, administrators can be far more precise about access and apply consistently across devices, platforms as well as whether the end-user is sitting in the office or working remotely.

Appliance-based v Cloud-delivered

There are a number of hardware and software components required to deploy a VPN. VPN clients need to be installed at the user endpoint, VPN appliances need to be deployed in the data center to manage traffic, and depending on capacity there are various other bits of equipment such as routers and switches that need to be used. Then firewalls, ACLs, DMZs all need to be configured to allow VPN connections. If more users need remote access, then the infrastructure needs to be manually scaled, appliances need to be installed and configured as well as additional licenses.

With more and more applications migrating to the cloud, it is only natural for security solutions to also move to the cloud. As SDP is a cloud-delivered service, the need for hardware is removed. Infrastructure is not bound to the capacity of appliances, SDP can scale dynamically to accommodate business needs. As the service provider is responsible for the integrity of the platform, companies reduce the administrative burden of maintenance but also benefit from highly specialized skill sets. Avoiding hardware eases deployment for IT teams, there’s no need to be onsite to set up appliances at the data center or be in physical possession of a device to install an endpoint agent, this can all be done remotely.

Deployment

Digital certificates are a common method of identifying an authorized endpoint for VPN services and are seen as a more secure alternative to pre-shared keys. But they’re by no means bulletproof from a security standpoint and there are a number of real-world cases where hackers have taken advantage of this system of trust. What’s more, deployment of certificates is time-consuming, susceptible to misconfiguration, and often requires some form of device management.

SDP uses an endpoint agent. A user can simply download an app, log in via SSO and this will automatically configure the device based on their identity credentials. Alternatively, a UEM can push the SDP app to the device or shareable links can be used, providing a number of zero-touch, low friction ways to deploy the app. The endpoint agent can be multiple purpose, providing a number of diagnostics of the device to enforce adaptive access controls.

User Experience

Speed

While VPN provides the bare essentials for remote access to corporate applications, it can’t necessarily be described as ‘user-friendly’. Users have come to expect enterprise apps to have the same level of service experienced as consumer apps, and these expectations are high. In general, users will abandon a session if a web page takes more than three seconds to load, so if you combine VPN with mobile devices, temperamental internet connections, high bandwidth applications, speed of service can be a problem.

Latency and speed issues are a natural byproduct of VPN design, and there are a number of causes:

  • Proximity to the server: if a user is logging in from Delhi and the VPN gateway is located in New York, purely due to the distance the request has to travel, there will be time delays.
  • Encryption: isn’t instantaneous; data has to be encrypted and decrypted as it passes through the VPN gateway. The amount of time can be mitigated by using a lower encryption strength, but this inevitably downgrades security.
  • Server capacity: the number of people using the VPN will affect performance. If the VPN has capacity for 20-30 users at any one time, any more would see performance deteriorate. What’s more, SaaS enterprise staples like M365 were designed for direct, reliable connections, these high bandwidth services put pressure on the infrastructure and if improperly managed, will bring VPN service speed down to a crawl.
  • Handshake: VPN technology has a protracted handshake process meaning any interruption results in disruption while the service reconnects.
  • Traffic hairpin: All VPN traffic is tunneled back to the appliance and is then routed from there, while this is suitable when accessing on-premise applications it is not for traffic destined for cloud applications or the internet.

Cloud-based SDP doesn’t rely on appliances, so doesn’t suffer from the same infrastructure limitations. It can scale up and down in line with business demand while offering a consistent level of service. Instead of routing users all the way back to a data center, users are directed to the nearest service edge to retain the locality of a session and mitigate latency. Single Packet Authorization helps ensure that users have a consistently good experience regardless of their connection type, whether that be office network, roaming on cellular or Wi-Fi from home.

Logging in, logging in and logging in

Most corporate VPN providers enable integration with a company’s identity directory to allow Single Sign On (SSO) and streamline the authentication process. VPN connections are temperamental, particularly over Wi-Fi or cellular connections, and having to re-authenticate every time it drops is burdensome. The user experience challenges are magnified on modern mobile devices that work differently than their desktop-bound siblings and are “awakened” 90 times per day on average. VPN was developed with traditional Windows devices in mind and has been retrofitted to the more modern smartphone form factor.

There may also be a need for users to switch between VPNs. It’s not unusual for a salesperson to need access to a CRM hosted on AWS, a partner’s lead management portal sitting on Azure and a recruitment tool hosted on-premise. Having to connect and disconnect to different services creates a frustratingly fragmented user experience, and inevitably leads to productivity drain.

Like VPN, SDP can integrate with IdP solutions, however, the difference lies in an SDP’s ability to provide continuity of service, even when transitioning between networks, thereby mitigating constant re-authentication requirements. Designed for more diverse IT environments, SDP can operate effectively on mobile devices without excessive battery drain. As access is policy-based, it eliminates the need for having separate VPN services to enforce a degree of network segmentation. Users simply connect to the service and are able to maintain contemporaneous connections to multiple applications across multiple hosting solutions.

Conclusion

Only 30% of companies successfully capture value from digital transformations. As companies continue with these projects, the entire user experience needs to be considered, not just the application layer. The benefits of new technologies will only be realized when infrastructure has been modernized. While VPN still has its uses, it should be augmented alongside SDP to upgrade the access experience and fully leverage a mobile workforce.