|
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] Assembling 'Team VPN'
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
We assembled a medium-sized team to gather all the expertise required to configure our five products. You should be prepared to assemble a similar team when testing and deploying your SSL gateway.
This is because the SSL gateway touches many different parts of your enterprise computing infrastructure. If you have segregated your support into desktop, server, network backbone, network applications and end user departments, as Stanford does, you will need representatives from each of these groups.
For example, while testing our products we needed one person to correctly specify the parameters for Stanford's LDAP and RADIUS servers; another to determine how to connect to its Windows file servers; a third person to configure desktops; a fourth for the firewalls, routers and switches; a fifth to set up our Linux server; and a sixth to answer specific security questions that no one else could answer, such as troubleshooting authentication issues and more complex Windows servers issues.
--DAVID STROM
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE]
There's Work Ahead
The bottom line is that these are complex products with all sorts of finer points to their operations. They require a team of sharp folks from various areas of your IT infrastructure to deploy properly (see "Assembling Team ...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
VPN," at right). SSL VPNs are quirky, difficult to install and set up, and offer spotty support for users beyond the Windows 2000/XP and IE envelope. Certainly, if you have a very heterogeneous network, or a large group of custom-built corporate applications, you will have a long test and rollout ahead.
Given that reality, there are clear differentiations that put some products ahead of the pack.
Juniper's SA 6000 SP was the clear winner in overall usability, features, and flexibility of operations. It took the least time to get set up and working, despite some complex menus and some oddly placed items.
The F5 FirePass was next, with sophisticated endpoint checking routines and a long list of supported antivirus programs. It has a visual policy editor that anyone who has done any flowcharting will glom onto.
Aventail's EX-2500 is an interesting study in contrasts. It has leading-edge functionality yet is missing basic key ingredients. It was the only product not to offer native RSA SecurID ACE support, yet it had some great debugging tools for setting up LDAP servers.
If there is a feature missing from the Cisco VPN gateway, we would be hard pressed to find it--and that, in a nutshell, is the problem. You can run both IPSec and SSL VPN clients from the same gateway, and set various user and group policies that are so extremely intricate that you dare not touch them once you have them working. The issue is that Cisco's administrative interface is complex and a bear to set up.
Check Point Connectra's biggest issue was the lack of differentiated, departmental-based administrative roles. It also has the weakest support for authentication servers and poorest overall client support. On the other hand, if you already have other Check Point products, such as firewalls and IPSes, you can manage all of this gear from a single console.
Information Security thanks the Stanford University IT department for its help in creating such a rich test environment, and especially its director of networking systems, Mark Miyasaki. Specifically, we thank Paul Murray, Johan van Reijendam, Steve Tingley, Russell Scheil, Ross Wilper, Sean Riordan, Leroy Altman and Jason Craig for all their help with this project.
|
 |
|
