Testing Cisco’s new SSL VPN technology

Cisco has put its most-advanced SSL VPN technology into its Adaptive Security Appliance 5540 with Version 7.1. In our test of a late beta of that software, we found that while it provides a solid and compact feature set for creating smaller SSL VPN extranets or adding SSL VPN network extension to improve compatibility for road warriors, its does not equal the capabilities of standalone SSL VPN products.

Cisco has put its most-advanced technology into its Adaptive Security Appliance 5540 with Version 7.1. In our test of a late beta of that software, we found that while it provides a solid and compact feature set for creating smaller SSL VPN extranets or adding SSL VPN network extension to improve compatibility for road warriors, its does not equal the capabilities of stand-alone SSL VPN products.

The Cisco ASA has a more advanced SSL VPN feature set than the VPN 3000 series it will eventually replace. Additionally, Cisco will let you add a less sophisticated SSL VPN feature set to both IOS routers and Catalyst 6500-series switches (in the form of a SSL VPN service module).

We put the Cisco ASA through a slightly reduced testing cycle than we used in our recent industrywide test.

In our authentication and authorization tests, we discovered that while the ASA claims to support Active Directory and Sun’s server, it didn’t support our schema of the Sun LDAP server. When we tried switching over to our SecurID server, we discovered that Cisco fully supports the additional RADIUS messages required to integrate with SecurID.

However, Cisco had no flexibility in mapping users to groups, and would have required us to change our existing RADIUS schema, breaking all the other applications plugged into SecurID. The ASA SSL VPN implementation does allow users to authenticate with digital certificates, but we didn’t test this feature.

In our fine-grained access-control tests, we found that the ASA uses numbered access-control lists (ACL) to define what Web and file resources a client can use when connected to the SSL VPN. Each client can be in one group, which then has a single access list, a barrier to scalability and flexibility.

Our policy from the SSL VPN test couldn’t be translated to the ASA, because the ASA doesn’t have the same fine-grained access controls we were looking for, such as the ability to limit access to applications within a Web server.

We found the management style for resources to be confusing. In addition to the ACLs for Web and file resources, there’s an additional place in the GUI for port forwarding, while access controls on network extension features are in a third place.

Also as part of our endpoint-security assessment, we looked at how an SSL VPN device behaves when a user’s PC somehow fails the host integrity check. In the ASA world, host integrity is a pass/fail indicator: If you pass, you get one ACL, and if you fail, you get a different ACL.

You can’t use the status of the endpoint-security check as part of your access controls in a generic way. This might be a good strategy for a deployment where endpoint security is black-and-white, but we found with Cisco, as with most of the other SSL VPN vendors, that endpoint-security checks will have a very high false-positive rate.

However, it’s obvious from watching Cisco’s Network Admission Control initiative evolve that the company is taking a more sophisticated look at questions such as endpoint-security assessment. Because this version of the ASA is not yet fully integrated into the NAC schema, we can hope that all of this will be overhauled when NAC does make its way to the SSL VPN product.

Application interoperability

Our next set of tests checked application interoperability. We had good success with basic applications – small problems with the ever-popular Outlook Web Access, but lackluster behavior when we moved to iNotes.

The port-forwarding functionality in the ASA worked quite well; it was much faster than the HTTP rewriting behavior with Outlook and iNotes. And, the best experience of all, as long as you’re a Windows user with administrator rights, came with the Cisco SSL VPN client.

The biggest problem we had, and this might have been a side effect of having no documentation available in this late beta, was understanding the interaction between the ASA firewall, VPN and application-layer gateways. This is a complex issue, but it seemed like we were losing some of the power of the rest of the product as we let traffic into the network via the SSL VPN. Because only one other SSL VPN product we tested really has a fully integrated firewall (Fortinet’s Fortigate), it’s not exactly clear how much the SSL VPN and the firewall should interact at this stage in the marketplace.

However, Cisco is positioned to be an innovator in this space, if it chooses to run with it. Given the real strengths of the product, however, which seem to be largely user remote network access focused, Cisco’s attention may be elsewhere.

Endpoint security

The last area we investigated in the ASA’s SSL VPN was endpoint security. Through the Twingo acquisition last year, Cisco picked up an outstanding endpoint-security tool for its SSL VPN product line, which it has rebranded as Cisco Secure Desktop.

Unfortunately, we weren’t able to map our policy into the capabilities of Cisco Secure Desktop, because it didn’t support our anti-virus tool (Sophos) or our anti-spyware tool (Webroot). The capabilities of Cisco Secure Desktop are fairly similar to those of Symantec’s Sygate endpoint-security tool, with a series of “locations” defined, and users fitting into those locations based on registry entries or IP addresses.

Each location has a set of security features that must be enabled, and the result is a pass/fail verdict from Cisco Secure Desktop.

In the case of “fail,” you have the option to create a second Web ACL, though features like file server access, port forwarding and network extension can be enabled or disabled based only on failing the endpoint-security check.

Cisco Secure Desktop has several other features that we saw in some but not all of the SSL VPN products tested. Those features include a cache cleaner, a virtual desktop that helps to reduce the risk of leaving files around and a persistent “vault” which lets the virtual desktop be disabled and encrypted when you log out and then reconstituted and decrypted when you log back in. All of this worked on Windows, as long as we had administrator rights. When administrator rights weren’t available, we had a lower success rate of even loading the Secure Desktop tool.