Will VPN Security Vulnerabilities Accelerate ZTNA Adoption?
For decades, virtual private networks (VPNs) have been used by enterprises to provide remote workers with secure remote access to their corporate networks and workloads. Since the COVID-19 pandemic and the corresponding increase in remote and hybrid work, the use of VPNs for secure remote access has been on the rise.
At the same time, enterprises have been moving from perimeter-based security approaches to security approaches that are based on the principles of the Zero Trust security model. Akamai research discovered that 46% of organizations had implemented or had started to implement Zero Trust across their organization, while 43% of organizations had implemented or started to implement it for specific use cases.
Zero Trust Network Access (ZTNA) is an alternative method to traditional VPN access and is an essential solution for organizations that are moving to a Zero Trust architecture. However, the relative simplicity of implementing a VPN for secure remote access has led many enterprises to continue to expand investments in that platform, rather than transition to ZTNA.
VPNs introduce security risks
The major security risk with VPNs is that, by design, they need inbound network connections that require opening the perimeter firewall ports. To mitigate that well-known security risk, the VPN infrastructure is normally placed in a demilitarized zone that ringfences the VPN from the rest of the corporate network.
Further protection is provided by adding access controls and segmenting the internal network with additional security solutions, such as firewalls and, increasingly, microsegmentation.
However, the risk of a threat actor gaining entire network-level access to the corporate network through a VPN and moving laterally is still a significant root cause of many high-profile cyberattacks and data breaches.
Although that’s one significant security risk, there’s another risk that can be even more critical for organizations: when a security vulnerability is discovered in the VPN itself.
CVEs in VPNs
For example, a new security vulnerability was discovered in Ivanti VPNs in January 2024 when the company released information on two Common Vulnerabilities and Exposures (CVEs) for their Ivanti Connect Secure (formerly known as Pulse Connect Secure) and Policy Secure software. According to Ivanti, the use of these vulnerabilities together “... does not require authentication and enables a threat actor to craft malicious requests and execute arbitrary commands on the system.”
CVE-2023-46805 and CVE-2024-21887 have high and critical scores, respectively. They are being actively exploited by malicious actors in an attempt to:
Obtain the VPN appliance’s configuration data
Modify and download files
Establish reverse tunnels
Eventually enroll rogue malicious devices within the network to gain unauthorized access to critical assets and data
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued a directive that any federal agency with these Ivanti devices must disconnect them from their network by February 2, 2024, because the vulnerabilities are still being actively exploited by Chinese threat actors.
Additional vulnerabilities
Since the initial report, Ivanti has identified a couple of additional vulnerabilities in its VPN devices:
A privilege escalation vulnerability (CVE-2024-21888)
A server-side request forgery in the SAML component (CVE-2024-21893).
Ivanti is not alone in this disclosure; most VPN providers have disclosed CVEs — it's a fairly regular occurrence. The burden to deploy patches to remediate these vulnerabilities largely falls on the customers’ security administrators. That can be a daunting task for already-overworked network security teams.
Patching is challenging
Patching for security vulnerabilities is a constant in the world of security. Even customers that do a good job of staying up to date can be caught off guard when threat actors are quick to jump on newly announced vulnerabilities. Threat actors are extremely agile whenever a new CVE is released; for example, data collected by Shadowserver Foundation shows that, within days, CVE-2024-21893 was being targeted by threat actors. We’ve also seen significant scanning activity across our platform that has been targeting CVE-2024-22024.
It is often a struggle to stay ahead — and the cascading effect of multiple vulnerabilities announced in quick succession makes patching a very daunting task.
ZTNA vs. VPNs
Unlike VPNs that rely on implicit trust — for example, granting access to remote users who are on the VPN — ZTNA follows the key principles of Zero Trust to remove and replace implicit trust with explicit trust. Remote users, for instance, could be authenticated with multi-factor authentication from a corporate laptop, with a working security suite, and would be authorized to access only specific applications or resources based on the access control policy.
Akamai Enterprise Application Access is an enterprise-grade ZTNA solution deployed on Akamai Connected Cloud, the world's most distributed cloud security platform. It provides least-privilege, granular access controls for private applications based on strong authentication and context, and eliminates network level access. It simplifies access management, reduces an organization’s attack surface, and improves its security posture.
VPN security vulnerabilities can be the compelling event
These new VPN security vulnerabilities will likely be a source of concern for overwhelmed security teams and might even be the tipping point for many enterprises to reevaluate their use of VPNs and consider moving to a ZTNA solution — or to accelerate a transition that was already in flight.
An example of accelerated transition
One very large Akamai customer that was impacted by these most recent VPN vulnerabilities accelerated its plans to deploy ZTNA to reduce its reliance on VPNs.
The customer had been able to implement Ivanti’s emergency workaround, but some apps would not operate successfully after this mitigation. The customer had already started to migrate business-critical apps to Enterprise Application Access, but the Ivanti security vulnerabilities prompted them to accelerate the migration. One advantage is that it can be quickly scaled to add new applications or accommodate additional users.
The architectural limitations of VPN solutions
One of the underlying architectural limitations of VPN solutions is the dependence on gateway appliances that accept incoming connections, allowing user access directly to the network. When a VPN’s architectural weakness is exploitable through software vulnerabilities, as in the case of Ivanti, a threat actor could gain Layer 3 access to network resources inside the security perimeter.
To be fair, a breach at the VPN concentrator may not instantly give an attacker full access to all network resources; as we mentioned previously, there will likely be other security measures in place. However, with a foot in the door and access to a key network security component inside the security perimeter, a malicious actor has a heck of a starting point to move laterally within the network.
This is inherently less secure than the Enterprise Application Access solution, with which user connections from endpoints are terminated in the cloud and users are only only allowed to connect to the specific applications and resources that they are authenticated and authorized for.
Enterprise Application Access allows no inbound user connections to the network, but instead establishes secure outbound dial-out connections that are “stitched” together with authenticated and authorized user connections coming through Akamai Connected Cloud. This essentially shrinks the attack surface at the on-premises or cloud data center to nothing, and does not require beefy hardware or a virtual firewall to deal with inbound access attempts (whether benign or malicious).
In the case of the Akamai customer that accelerated their transition, the choice to migrate their critical business apps to a ZTNA solution suddenly became the only sensible security choice. However, the freedom to conduct this migration in a well-planned and efficient manner was lost in the throes of an active exploit on the existing vulnerable solution. In the end, many more resources were necessary than if the customer had been further along in its Zero Trust journey.
Traditional perimeters or VPNs that provide full network access can be exploited to access network devices and spread malicious software, such as ransomware, laterally. A ZTNA solution, such as Enterprise Application Access, limits exposure by operating at the application layer, granting access only on a per-session basis and following sound Zero Trust security tenets.
Adding defense-in-depth security
Adding defense-in-depth security layers will provide further protections against lateral movement if malicious actors breach the perimeter. Visibility, application dependency, and the ability to quickly respond and enforce policy is critical in protecting valuable assets in organizations.
Akamai Guardicore Segmentation
Layering on Akamai Guardicore Segmentation allows you to quickly and effectively take action in an increasingly advanced threat environment to eliminate lateral movement and limit the impact of malware and ransomware.
Akamai MFA
To prevent employee account takeovers, Akamai MFA provides the strongest level of user identity and authentication based on FIDO2 standards. It uses a smartphone app for a frictionless end-user experience and eliminates the cost and complexity of physical security keys. Akamai MFA can be seamlessly integrated with Enterprise Application Access.
Akamai App & API Protector
Akamai App & API Protector is a single solution that brings together many security protections including web application firewall (WAF), bot mitigation, API security, and distributed denial-of-service (DDoS) protection. The customer that was impacted by VPN security vulnerabilities (discussed previously) is leveraging the power of Akamai Connected Cloud to insert these protections in front of Enterprise Application Access, which will help mitigate the additional server-side vulnerabilities that were disclosed by Ivanti.
Conclusion
To avoid data breaches that can compromise sensitive information, customers should plan to adopt a Zero Trust framework, define a Zero Trust architecture that works for them, and enact a progressive plan for implementing it.
Many organizations have already started this journey, and could act to accelerate adoption, if necessary, in an emergency. Although it is not ideal to implement a new strategy under the threat of an active exploit, it is worse not to have a Zero Trust strategy at all.