By Joel Snyder
Network World, December 19, 2005
Original Article on Network World Web Site
SSL products serve up various degrees of access control.
When it comes to the philosophy of access control, the products we tested ranged from the far right to the far left.
At one end of this extreme SonicWall's approach with its SSL-VPN 2000, which defaults to an "allow" policy for the entire system, meaning any users who successfully authenticate can go anywhere they want unrestricted. This might be a fairly natural policy initiative for a small company that is simply replacing IPSec remote access with SSL VPN remote access.
However, one of the main arguments in favor of SSL VPN technology is that it has the capability to bring a wide range of people into the network, in a very controlled way. This use case, usually called an extranet, includes not only employee access as you might see in IPSec VPN but also auditors, business partners, consultants, contractors and customers. With extranet usage, access control is crucial.
At the other end of the spectrum is Juniper's SSL VPN Secure Access (SA) 6000, the access-control king. If you want to allow write access to a particular file on Thursdays after 5 p.m. for AOL users running Netscape 2, then Juniper's your product.
All other boxes tested fall somewhere between these extreme access-control schemes. Finding the right SSL VPN product for your application means thinking about four aspects of access control: granularity, end-point security, group tools and manageability.
Granularity is the easiest to think about. How detailed do you need your access controls? In our test security policy, we made a distinction between different parts of a single Web server. We also wanted to control access to specific Web services. And we wanted to impose additional read-only controls on some file-based services, such as a Windows file server. Only the Caymas 525, Juniper's SA-6000 and Nokia's Secure Access System could handle all of those requirements with aplomb.
Still, there's a distance between what we asked for and what we found to be poor security practice with regard to access control. The products that failed to give what we considered minimum-security controls, settings so basic that they can give different controls to different parts of the same Web server, include Array, Fortinet and SonicWall. None of these offer any granularity tighter than the Web server itself. If your SSL VPN is composed of "friendlies," such as employees using it for remote access, or if you have a single application that you're trying to export over the Internet, these might work for you. But as generic workhorse SSL VPN devices, they should be avoided.
The second decision-making criteria addressing granularity is the integration of end-point security controls. All of the products we tested except for SonicWall and Fortinet let you check the status of the SSL VPN client either before or after logon time (or both). The question is: what do they do with that information? If the reason you are installing an SSL VPN is to give employees with company-managed laptops access, then you probably have very simple end-point security requirements, such as a "go/no-go" decision. Either you pass the scan or you fail it, and if you fail it, you don't get access to anything. Any of the products we looked at (except for SonicWall and Fortinet) can do that.
Because most SSL VPN vendors added end-point security to their products after they were well down the engineering path, the integration with their access-control mechanisms is often clumsy and difficult to manage. For example, Nortel's VPN Gateway 3070 has one set of access controls in its product that don't encompass end-point security, and a second, completely separate set of access controls with a complex, difficult-to-use interface that do include end-point security measures. The same is true of Aventail's EX-1500 management system. Although you can express fairly complicated policies, it's difficult to predict exactly what the EX-1500 will do in any situation, because the degree of control you have depends on the access method.
The cleanest integrations of end-point security come in three flavors. AEP's and Array's implementations fit into the go/no-go philosophy, which is not very powerful but is very easy to understand and manage.
The Caymas 525 and Check Point's Connectra both link end-point security information to specific resources. It doesn't matter who you are; if your end-point security is not up to snuff, you don't get access. The downside to this implementation is that a security manager doesn't have the flexibility to make exceptions. Our test security policy required the ability of some groups to bypass end-point security restrictions (think IT emergency support team), and so these two products technically failed our test. However, for many implementations, this is a clean way of defining policy, and if you are happy with that level of flexibility, you will be glad that endpoint security is not cluttering up the management interface.
Products tested from Aventail, F5, Juniper, Nokia and Nortel all take end-point security to the next level by allowing you to consider both resources and user groups as you are implementing end-point security measures. If you're looking to use this integration extensively, you'll want to focus on Juniper's SA-6000, and to a lesser extent Aventail's EX-1500 and Nokia's Secure Access System 500s. Juniper lets you run your end-point security either before or after authentication, lets you decide to allow or block the user based on security status, lets you modify the group the user joins based on security status, and lets you evaluate security status as part of the access control down to the individual URL level.
Nokia also has a weak spot: End-point security and its network-extension client are linked differently than for all other resources, so you fall back to a much less flexible and capable security model with that access method.
F5's and Nortel's offerings fall into the category of "you can do this, but you'd never want to," because of the level of difficulty of really including end-point security in complicated access-control lists. For example, with F5's management system, you'd have to replicate all of your resource definitions for every single group to apply different end-point security policies at the same time. But if you want to tie endpoint security to the resource, you only have to define it once.
If parceling out resources is one part of the access-control question, handling groups is the other. Each user has to be assigned to a set of groups in order to make access control manageable. While being able to dive down into the individual user level to set security parameters makes sense once in a while, best practice suggests focusing on the group level for policy control.
Most of the products let you pull group information out of the directory, especially if you're using Lightweight Directory Access Protocol (LDAP), and to a lesser extent RADIUS, for authentication. Of the lot tested, products from Aventail, Caymas and Juniper all reach into your LDAP directory, find the groups that exist and make it easy to map them into your access control list and policies. SonicWall's SSL-VPN 2000 failed our group assignment test, because a user can only be a member of a single group.
However, we had a fairly simple LDAP server in place for authentication and group assignment. If you have a more complex directory, or if you need to map to groups based on other attributes (such as going to a different directory), be careful to define these requirements before evaluating products. You may very quickly hit the wall, as we did in working with Check Point's LDAP lookups. Check Point was able to work undocumented black magic and get us running, but not every directory is going to work with every SSL VPN device.
There is a considerable gap between what these SSL VPN products can do, and what you would want to do with them. For example, while it's possible to generate a very secure and precisely controlled configuration with F5's product, you'd never want to do that with the tools they give you - the GUI is not designed to facilitate fine-grained access control.
We found the F5 FirePass to be especially deceptive, because it seems like you're defining access to resources. However, when you dive deeper into the product, you'll discover that what you're defining is the placement of resources on a portal, with fine-grained access control hidden on a third-level, oddly worded, menu off to the side of the product.
We had similar problems trying to apply policy to the Aventail EX-1500. Its access control is made more complicated by a design scheme that tries to separate out the definition of a resource from how you connect to that resource.
We had more disappointing management experiences with Array's SPX-5000 and Nortel's VPN Gateway 3070. While both of these products have some level of access control in them, their poorly designed management systems actively discourage much in the way of fine-grained controls.
The best compromises between control and complexity lie in the Caymas and Nokia products. Both allow you to easily see and create access control across resources. Nokia's ability to jump between "simple" and "advanced" access controls is a particularly elegant choice that lets you be complicated when you want to - and speedy and easy the rest of the time.
Juniper's management system for access controls is one that you'll love to hate, and hate to love. While Juniper shares with Nokia the idea of simple vs. advanced (what Juniper calls general and detailed) controls, there are an additional 20 screens available to define the finest grained policy and control you can for Web-based resources. While learning Juniper's interface, it's more important to discover what you can ignore rather than what you should pay attention to.