Managed Security Services

2006 MSSP Survey, Part 4:
Managed Virtual Private Networks

ISP-Planet's biennial survey of MSSPs finds that virtual private network offerings are becoming increasingly sophisticated as they are used to differentiate a provider's service—and as the VPN market continues to grow rapidly.

by Lisa Phifer VP Core Competence, Inc. [December 21, 2006]

According to recent Infonetics research, the Virtual Private Networking (VPN) services market earned $23 billion worldwide in 2005; sales are expected to reach $29 billion by 2009. Approximately three-fourths of VPN service revenue came from Site-to-Site (S2S) VPNs, while Remote Access (RA) VPN represented 23 percent of 2005 revenue. No matter how you slice it, delivering secure business communication is a lucrative business opportunity for Managed Security Service Providers (MSSPs).

Over the past decade, S2S VPNs have helped many businesses migrate from pricey point-to-point links to virtual inter-office connections that ride a provider's network. RA VPNs have supplied corporate network access to offsite employees—travelers, teleworkers, day extenders, and mobile workers—over any handy internet connection. To constrain access to authorized users and protect private data sent over public links, many VPNs use a secure tunneling protocol like IPsec.

A managed VPN service includes installation and provisioning of one or more VPN gateways—devices that terminate tunnels and enforce policy on all traffic permitted to enter or leave the private network. VPN services also include management and monitoring, from on-going policy updates and routine maintenance to security event monitoring and tunnel usage reporting. Every participant in this year's MSSP survey offers both S2S and RA VPN services, detailed by the following charts (click to view full size).

Like managed firewalls, most managed VPN services use customer premises equipment (CPE), deployed at the edge of the customer's network or hosted at a data center. Four providers in this year's survey also offer network-based VPNs, where the point of tunnel termination occurs on a shared switch or router inside the provider's network. Virtela and Perimeter offer both CPE and network-based S2S VPNs, while AT&T and Megapath join Virtela in offering network-based RA VPNs. We had expected more growth in network-based services, particularly for S2S VPNs. In fact, some participants who described network-based VPNs in 2004 (Globix and MCI, acquired by Verizon) described only CPE-based VPNs in 2006. Is this a reflection of our sample size, or an indication that network-based VPNs did not achieve the economies that MSSPs were hoping for?

Infonetics predicts that IPsec VPN revenue will decline as MPLS, MPLS/IPsec, and SSL VPN revenue continues to rise over the next three years. This year, we found MPLS (Multi-Protocol Label Switching) offered by one-third of participants, always in conjunction with IPsec. This probably reflects the security focus of our survey. When used by itself, MPLS does not offer cryptographic protection. Readers interested in security services would likely require IPsec for first mile/last mile protection, using MPLS to switch traffic across the provider's backbone. Consequently, we found IPsec universally supported by this year's S2S VPN providers. Ten MSSPs even claimed to support IKEv2, the new improved Internet Key Exchange used to establish IPsec tunnels.

Many MSSPs supported additional protocols, usually for RA VPN services. For example, Microsoft's old Point to Point Tunneling Protocol (PPTP) is available with one S2S VPN and 7 RA VPN services. Some small businesses use PPTP because it works with VPN software built into every Microsoft client, from Windows 95 to Mobile 5. However, those really concerned about security migrated long ago to IPsec, used alone or under the Layer Two Tunneling Protocol (L2TP).

IPsec is more secure, but requires persistently-installed VPN client software. Every RA VPN service in this year's survey supports this option. Some MSSPs supply customers with IPsec clients, while others expect customers to obtain compatible VPN clients. Some providers offer a secure portal for client download and/or user helpdesk support. IPsec may be great for S2S VPNs, but anyone considering IPsec RA for a large workforce should assess the effort required to install, configure, and maintain client software, and how an MSSP can offload that IT burden.

SSL VPNs are another way to simplify RA VPN deployment. These VPNs take advantage of Netscape's Secure Sockets Layer protocol (SSL) or the standard Transport Layer Security protocol (TLS) embedded in web browsers. With an SSL VPN, users point their browser to an SSL gateway. Applications behind the gateway are reached through ordinary web pages, Java applets, or ActiveX controls that mimic native GUIs or forward messages through SSL/TLS tunnels.

This year's survey illustrates the continued shift towards SSL VPN. All but three surveyed RA VPN services now support SSLv3; four also support TLSv1. Several providers explicitly recommended SSL VPN over IPsec, but all clearly consider it still necessary to offer IPsec for customers who require that protocol. Similarly, 5 of 16 services require permanent VPN clients; the rest also support temporary clients or vanilla browsers. The latter reduces client administration, but you still need to be careful about client platform limitations. For example, some temporary clients only work on devices with Java or ActiveX, or where the user has administrative rights. MSSPs did not enumerate such constraints, but don't assume that an SSL VPN will run on any device.

Platform and protocol choice has a direct impact on a VPN service's encryption and authentication features. 13 of 15 S2S VPN services now support the Advanced Encryption Standard (AES), a significant shift compared to 2004 results. The older 3DES has become the common denominator supported by all. Just a few still support DES for international use. The same trend can be seen in this year's RA VPN services, where 7 providers also support RC4 with PPTP and/or SSL. Still, if you require AES to meet internal policies or external mandates, verify that your provider supports it.

Similarly, all surveyed S2S VPNs support PreShared Key (PSK) authentication—a numeric password configured into each gateway. Twelve also support digital certificates, making it harder for an attacker to crack your PSK and masquerade as a gateway. Due to IPsec/IKE limitations, PSKs are less common with RA VPN services. But many MSSPs offer sub-authentication using text passwords or RSA SecurID tokens. In IPsec RA VPNs, combining certificates with token sub-authentication creates a strong multi-factor solution that is hard to hack. Just three surveyed services lack this feature, and several support biometrics in addition to tokens.

With a S2S VPN, the MSSP configures each gateway during initial setup. Later changes are relatively infrequent—for example, configuring a tunnel when adding a new office. Your MSSP should provide on-going gateway maintenance, including security patches, and access to traffic logs and reports. With an RA VPN, you will work more closely with your MSSP to add, change, and drop users on a continuing basis. Ten surveyed RA VPNs can be used with either provider or customer-managed user databases. Four services require provider-managed authentication, while two offer only customer-managed authentication. If you want to use an existing user database, ask about supported protocols and datastores. If you would rather offload that task, evaluate the provider's user management process, including related SLAs.

In either case, consider the access control lists (ACLs) applied to VPN tunnels—especially RA VPN groups and users. Because SSL VPNs can provide more granular access, we decided to ask MSSPs to enumerate supported ACLs. A whopping 80 percent claimed to control access down to the URL / data object level. Half were able to filter on endpoint device identifiers, and half were able to incorporate endpoint scan results in access decisions. Such features are useful when permitting access from unmanaged devices like home and public PCs. When shopping for an RA VPN, consider the VPN's ability to check for the endpoint security products that you use and support for emerging NAC/NAP/TNC architectures.

To facilitate comparison, we included S2S and RA VPN feature checklists in this year's survey. Results proved interesting. S2S hub and spoke topologies are very common; full-mesh topologies less so. High availability is a common option for S2S VPNs, but occasionally included at no additional cost. The most common RA VPN included "extra" was provider-supplied user helpdesk, available with 12 services, but only included with 7. The least common was bundled internet, available as an option with 9 services but included with just one: Fiberlink. See tables to compare additional VPN add-ons and features that may be of interest to your business.

Finally, readers may note the absence of change management, monitoring, and SLA details in this year's tables. In the past, we found that most MSSPs applied very similar processes to their managed firewall and VPN services. So this year, we focused on comparing VPN-specific features. However, some providers included process or SLA details with this year's VPN response, summarized under the "additional comments" columns. We still believe that the provider's processes and SLAs are a critical consideration when selecting managed VPN offerings, so be sure to include such questions on your own VPN RFP.

—End