Cloud SASE, SSE, and Zero Trust solutions have modernized thousands of on-premise solutions for corporate networks over the past ten years. This trend can be seen as a continuation of the shift to the cloud, similar to the transition from Microsoft Exchange™ to Microsoft O365™ in the past. While the cloud offers many benefits, let’s analyze whether the following argument from marketing material is true. “Traditional VPN fails to provide crucial capabilities for a zero-trust deployment since they allow traffic to the whole network.” This statement is brought up in almost every industry webinar and customer meeting. Whether it is true or a myth depends on how “traditional” is defined. Cloud Zero Trust – Myths or Facts delves into this topic.
What is considered traditional?
IPsec VPN Client (network-level connectivity) became the standard for remote connections in the mid-90s. The solution allowed for defined IP subnets or individual IP destination addresses. Gradually, the implementation was expanded with firewall rules, strong authentication, and NAC solutions. Regarding the claim about wide network connectivity and attack surface, it holds true only partially, if at all.
One of the challenges with IPsec VPN Client was granting access to the company’s applications for partners, outsourced administrators, consultants, and others, as well as distributing multiple IPsec client software to workstations. In 2002, we sought technology to address this specific need and started collaborating with Neoteris™ startup in 2003. Their marketing message was “Client-Less VPN” and application-level security.
Neoteris™ (later NetScreen Technologies™, Juniper Secure Access, Pulse Secure™, Ivanti Secure Access™) technology eventually became a market leader and gained a Gartner™ leading vendor position in the SSL-VPN market. Regarding this VPN remote access solution, the claim about network-level connectivity holds true only partially, if at all.
Client-Less SSL-VPN and Zero-Trust Access definition
Client-Less VPN access was defined at the application level (Layer 7 and/or proxy), not the network level. Profiles and Active Directory™ integration facilitated policy management. Identifying and authorizing endpoints and users in different situations were basic features. I argue that in the Client-Less SSL-VPN solution, the definition of Zero-Trust Access was achievable and implemented.
Euros triumphed over security
One of the key challenges of SSL-VPN was creating and maintaining access profiles for large enterprises. In a networked and constantly evolving business environment, managing application-level access profiles is challenging. It requires the customer to have a crystal-clear understanding of the requirements: what, who, from where, and when. The solution provider’s expert does not possess this information during the implementation phase. Cloud SASE and SSE do not change this.
There were also numerous different application architectures to contend with, such as client/server and Java™ implementations. SSL-VPN (OSI Layer 7 access or proxy technology) worked well with common HTTP applications and VDI solutions, but large enterprises had hundreds of other applications. Configuring and testing them was expensive expert work. When an application changes during a version update, the work had to be redone as a fault process.
To address these challenges, it was tempting to implement a Layer 3 network-level connection to the entire network, thus creating a wide attack surface. Configuring such a solution took an hour, and the solution was unaffected by application or application architecture changes. Therefore, the decision to implement a network connection could also have been a commercial one (one hour of expert work versus weeks of demanding expert work and continuous change management). Alternatively, the sales team simply could not explain and justify the significant price difference for service deployment and maintenance costs.
Price competition kills separate systems.
Microsoft Windows Server 2008R2™ Direct Access and its Always-On VPN were traditional network connections that Cloud SASE & SSE operators may possibly refer to. The integrated remote access solution on workstations as part of Microsoft™ licensing often replaced numerous expensive separate systems. At the same time, control over security shifted from network and security vendors to the Windows™ service provider. Concurrently, firewall manufacturers developed SSL-VPN solutions (practical implementations of L3 network connections) as part of the firewall. Price and ease of use triumphed over security.
Zero-Trust Access technology
I argue that Cloud SASE & SSE and its Zero Trust do not significantly differ from SSL-VPN “Client-Less” (proxy and Layer 7) implementation in terms of security technology. The greater impact and opportunities to implement it practically come from updates in application architectures over the past 20 years. Client/Server, old Java applications, and others have been updated, and there are more native web applications on the market. The chances of avoiding a “traditional” network-level connection are now better. However, this does not mean that application-level access solutions have not been implemented for decades. It also does not mean that a cloud solution is a “plug-and-play” process that takes an hour of work. We can also ask whether we have returned to the application proxy firewall architecture of the early 1990s.
Business benefits of Cloud SASE & SSE
Using security transition as a justification is unprofessional, in my opinion, unless one knows the customer’s current solution and implementation with 100% certainty. It underestimates the market and competitors or shows inexperience in enterprise network solutions. Instead, Cloud SSE, SASE, and NaaS bring significant business benefits, such as in corporate mergers and business scalability, compared to on-premise solutions. Despite the change in the security environment, total cost still plays a significant role in selecting solutions. We assist in these and many other areas.
Hannu Rokka, Senior Advisor
5Feet Networks Oy