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 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 Lightweight Directory Access Protocol server, it didn't support our schema of the Sun LDAP server. When we tried switching over to our SecurID RADIUS 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.