Is an SSL VPN by either definition or by circumstance a NAC device?
Both Caymas Systems and Juniper Networks would argue a resounding "yes". The argument here would be that because the most recent iteration of SSL VPN products have been focused on authorizing users, controlling access and using end-point posture assessment, an SSL VPN is a natural fit into any NAC scheme. Just as the intrusion-detection system (IDS) vendors were ideally situated to start selling intrusion-prevention system (IPS) products, SSL VPN vendors are going to have a natural leg up in this market
Caymas, has repositioned itself into the NAC space using the same technology it originally sold as an SSL VPN device. Juniper has also jumped heavily on the NAC bandwagon, repurposing the policy engine from its top-rated SSL VPN product into the Unified Access Controller (UAC) IC-4000 appliance we tested as part of the TCG/TNC framework.
For an objective answer to the questions of an SSL VPN's role in NAC, we approached F5 Networks -- which hasn't yet entered the NAC marketing fray -- and asked if we could assess its FirePass SSL VPN product as if it were in fact a NAC device.
Our first criterion for a good NAC device is a broad range of authentication methods and types. In the case of NAC, this process includes both the back-end authentication server -- and the FirePass supports eight of these -- and the way by which users convey their credentials to the device. For an SSL VPN in general, the latter process is limited when compared with a NAC-enabled environment. A good NAC framework can use various methods, such as an 802.1X process, a captive portal, or even sniffing some other authentication system while SSL VPNs tend to be limited to Web-based client authentication mechanisms.
The FirePass provides both Web-based username/password authentication (roughly equivalent to a captive portal) and a passwordless authentication based on digital certificates. The question then follows: Is there some way for an SSL VPN to do a more integrated authentication, such as with a client or by integrating directly with the Windows logon sequence akin to what is done in NAC? With FirePass (and other full-function SSL VPNs), that only happens when you use the product's network extension tools, which link the SSL VPN user's system at the IP layer to the central site's network, similar to an IPsec VPN, rather than the Web-based parts of the product.
Our second criterion for a solid NAC framework is the ability to factor end point security assessment and environmental information into the access equation. With a very sophisticated end-point security assessment system in place within FirePass, the network manager can build a policy to check end-point security across a variety of platforms. At this point, FirePass is ahead of most NAC vendors, which rarely have cross-platform support, because it can detect and handle endpoints running Mac OS X differently than those running Windows.
End-point security assessment depends on the ability of the SSL VPN portal to push software down into the users' browsers. In the case of the FirePass, this requires an ActiveX-compatible browser. Some NAC vendors, such as Juniper and Cisco, prefer a permanently installed client, rather than relying on the browser. FirePass doesn't support the option of an installed client to do end-point security checking over its Web services portal.