To provide remote access to employees and business partners, companies most often choose between two primary types of VPN solutions – IPSec and SSL. IPSec is the original VPN with a well-established market of $2 billion in revenues for 20031. In the same timeframe, SSL VPN revenues were less than 5% of the IPSec market. However, the SSL VPN market has shown significant expansion in recent years with predicted growth to 25% of IPSec revenue by 20081. This trend reveals a notable market shift, as enterprises search for solutions that effectively address the major shortcomings of IPSec.
IPSec – The clientful VPN
For many companies, IPSec VPNs present a good option for connecting branch offices, as well as providing fully-trusted users with an in-office desktop experience for native applications. Since their introduction in the mid-90s, IPSec VPNs have greatly reduced the high cost and application limitations of original direct-dial up methods. Nevertheless, while IPSec delivers considerable benefits for power users and site-to-site connections, important disadvantages still exist.
For network security managers, the major "headache factor" with IPSec is the management of client-side software which is often difficult to install, incompatible with other vendors' IPSec gateways, and costly to update and maintain. In addition, the clientful characteristics of IPSec make it an unrealistic option for enabling secure access from unmanaged, non-corporate assets – such as home PCs, business partner desktops or other non-IT controlled devices. In fact, a recent survey of IT administrators and C-level executives conducted by Permeo Technologies revealed that the primary reason companies switched or would consider switching from IPSec to SSL VPNs was to eliminate client installation and maintenance.
First generation SSL VPNs
SSL VPNs arrived on the scene in the late '90s as an alternative access solution designed to overcome the shortcomings of IPSec. Functioning on top of the IP infrastructure, SSL VPNs offered remote users access to corporate web applications by leveraging the Web browser's built-in SSL capabilities. With the advent of browser bundling in major operating systems, access to VPNs via a Web browser meant that network security managers could avoid the need for client-side VPN software. Thus, vendors began to claim that they provided "clientless" VPNs when, in reality, clientless VPNs never existed. Instead, SSL VPN solutions were simply taking advantage of the bundled VPN (SSL) software in the browser.
Still, organizations deploying HTTP-based SSL VPNs can realize two significant benefits: 1) greatly reduced cost and administrative overhead in deploying and managing remote access implementations and 2) the ability to extend remote access to diverse groups of users on non-IT controlled devices.
As with IPSec, while this new alternative provided benefits over previous remote access models, it posed some important challenges – primarily with regard to providing robust connectivity to all types of applications. Although users could now seamlessly access applications with Web-based front ends, un-webified client/server or legacy applications were not easily extended to SSL VPN users. Browser-based SSL VPN users were also unable to easily access complex Web applications, i.e., those that spawn multiple windows or connections. Unfortunately, many of today's critical enterprise applications – such as sales force automation, supply chain management, human resources management, and even voice-over-IP – need multiple connections for full functionality.
Thus, while first generation "clientless" SSL VPN solutions greatly advanced simple, HTTP-based remote access, they failed to meet changing remote access needs.
SSL VPN modes of access
In an effort to overcome the limitations of simple HTTP-based access, SSL VPN vendors have expanded their "clientless" solutions to provide broader access to complex, business critical applications. A variety of approaches have been taken, with many vendors offering three different modes of access. While each access mode provides broader connectivity, with increased connectivity comes a marked increase in the required administrative burden. So, despite their promise to ease IT administrators' headaches by eliminating thick client software, SSL VPN vendors have continually bulked up their client plug-ins, falling into the same maintenance and administrative cost trap as their IPSec predecessors
As a result, SSL VPN vendors have failed to deliver on the original promise of "clientless" access – low administrative costs and remote access for more diverse user groups.
Today's SSL VPN solutions have become just as intrusive and costly to maintain as their IPSec brethren. In addition, providing connectivity to complex applications typically requires that end users have administrative privileges for deployment. In situations where IT does not control or manage the device, such as a business partner laptop or an employee's home PC, it is unlikely that the end user will be authorized, or even willing, to make modifications or download software to that device. Therefore, these solutions offer no viable options for providing secure remote access to users operating on unmanaged devices.
The remote access imperative
Businesses seeking to extend remote access have traditionally made difficult trade-offs between application support, manageability and network security. This tradeoff is no longer viable. A new breed of remote access VPN solutions is needed – one that delivers:
- Efficiency for IT administration: IT managers should no longer be forced to accept the installation of clients as the inevitable result of increased connectivity. Solution providers must deliver on the original promise of SSL VPN – the elimination of permanent client-side software, i.e., zero client provisioning or maintenance. This is especially essential for extending the boundaries of the enterprise to partners, suppliers, customers and contract workers who operate on non-corporate owned devices.
- Transparency for the end users: Providing access to diverse groups of remote end users demands a simple, user-friendly approach. Remote access solutions must provide the intuitive user interface and access to native applications essential for increasing end user productivity and reducing support requirements.
- Access to any application or application protocol: SSL VPN providers must deliver the robust access capabilities that enterprises need to eliminate the parallel deployment of IPSec VPNs which is still prevalent today. This requires the full out-of-the-box support of any application – productivity, enterprise, custom in-house, and complex web – without modifications to the application.
- Integrated endpoint security for all users: SSL VPN solutions must not only fulfill the connectivity and manageability requirements intrinsic in extending remote access. They must also secure data at the endpoint, not simply in transit. In addition, solutions must provide fully integrated information security controls to prevent leakage or theft of sensitive corporate information once the data arrives at its destination. Although endpoint security is outside of the scope of SSL or IPSec standards, it is a critical element in delivering a well-balanced remote access solution.
Ultimately, meeting the remote access needs of today's extended enterprise means providing the best of both these worlds--the rich connectivity of IPSec VPNs and the simplicity of SSL VPNs. In addition, providing truly secure remote access means viewing endpoint security in a new way, i.e., extending the "end" to "end of use" and incorporating capabilities that secure the data post-delivery, rather than stopping at the point of transmitting.
Finally, enterprises should look to their solution providers to address all of their secure remote access needs, including providing full connectivity to both IT managed and unmanaged devices. Secure remote access should be a business enabler, not a business disabler.
Mark Elliott is a network security veteran and vice-president of product management for Permeo Technologies.