10.1. NAC-Like Functionality in Non-NAC Technologies
With LAN-based NAC/NAP solutions, the assessment of devices occurs as they attempt to gain access to the LAN — and sometimes at intervals after that. When machines come onto the LAN, they do so by physically coming back to the office or using a VPN to connect. Many VPN appliances have the capability to check the security posture of devices as they VPN back into the corporate network. If the security posture is deficient, access can be prohibited or limited. Clearly, this is performing a component of NAC/NAP functionality.
This type of functionality exists in the two primary types of VPN appliances:
For some companies, implementing a full-blown NAC/NAP solution isn't in their immediate futures. At the same time, they may recognize that mobile systems pose a serious threat to their LAN and would like to take advantage of a technology to assist with this problem. This is a perfect example of where using existing technologies such as VPN devices can help add NAC-like functionality.
10.1.1. NAC Functionality in IPSec VPN
When mobile systems attempt to create a VPN back to the corporate network with their IPSec VPN clients, there are security advantages to assessing those clients before full access is allowed. While many IPSec VPN devices can perform this functionality, let's focus on Nortel's VPN solution.
A while back, Nortel introduced its Tunnel Guard functionality to its VPN devices. Tunnel Guard is an application related to the IPSec VPN client that checks if the required security components are installed and active on a remote user's machine. This check takes place as the user attempts to connect to the VPN device. Figure 10-1 illustrates the topology.
What elements Tunnel Guard should look for when the user connects is defined via the Software Requirement Set (SRS) rules. If the device passes these rules, then it is provided access to the network as defined in its Group Policy; it is unrestricted. If it fails, then its access can be limited, or the VPN tunnel can be torn down. Tunnel Guard allows for many different security elements to be analyzed on a system attempting access, including the following:
Figure 10-1. Nortel VPN Tunnel Guard topology
Executables
.dll files
Configuration files
Tunnel Guard also allows for integration with predefined software checks from OPSWAT and other third-party vendors. OPSWAT offers an Endpoint Security Integration SDK as a uniform API to monitor, assess, control, and enforce features of antivirus, antispyware, firewall, antiphishing, and other endpoint security applications. This allows for easy integration between Tunnel Guard and security products from many different vendors
10.1.2. NAC Functionality in SSL VPN
Just as Nortel's Tunnel Guard can provide NAC-like functionality for IPSec VPN clients, SSL VPN devices can perform the same functionality. In fact, many VPN devices can act as both IPSec and SSL VPN devices. In doing so, the analysis and restriction functionality can be very similar.
With SSL VPN, there can be a substantial differentiator between how it functions with an endpoint and how an IPSec VPN client can function. The difference is whether or not an actual client is installed on the endpoint. With IPSec VPN, it's rather straightforward. If you want to connect to an IPSec VPN, you install the IPSec VPN client from the appropriate VPN vendor. This would be actual software that runs on the machine and facilitates the VPN connection. With SSL VPN, there isn't necessarily a client that an end user would install. Sometimes, the Internet browser (such as Internet Explorer) acts as the VPN client. Why does this difference matter?
The difference matters because a good assessment of an endpoint trying to establish a connection to the LAN would require a client to be installed. This has been discussed many times in this book. You can scan a system to see if its security posture is up to snuff, but that won't provide nearly the amount of detail that a client would. So, if a client isn't installed with SSL VPN, how can client-based assessment take place? The answer is simple: download a Java or ActiveX-based applet that acts as the client.
One of the most mature SSL VPN devices is from Juniper. Originally, it was offered by Neoteris, which was bought by NetScreen, which was bought by Juniper. I have personally worked with this device from the time it was Neoteris, and its HostChecker functionality is quite robust. Figure 10-2 shows a screenshot of a HostChecker configuration.
Figure 10-2. HostChecker configuration screen
As you might expect, HostChecker can assess the security posture of a device and prohibit or limit access based upon that posture. A point to understand regarding this limiting is that users can connect via SSL via a number of different ways, including the following:
Browser-based Access — The user is able to access various network resources solely through the browser.
Secure Application Manager — This allows for specific applications to be run natively on an endpoint (such as the full Lotus Notes e-mail client), although connectivity to the corporate network is application-specific. (The Lotus Notes traffic is sent to and from the corporate network, though the endpoint isn't actually on the network.)
Network Connect — The endpoint actually has Layer 3 connectivity to the corporate network and is a node on that network, in a way that is very similar to IPSec VPN.
With these various ways to connect via SSL, administrators have great flexibility on just how users can connect. This flexibility can be carried over to their security posture. If a machine's security posture is perfect, then users can be allowed unrestricted Network Connect access. If it is deficient, then only browser-based access could be allowed. This allows for robust control and restriction based upon the security posture of the devices.