using edge switches for network access authentication. In this final part in the series, we discuss integrating edge switches with network access control (NAC).
Authenticated access ensures that a user has to provide credentials to get access to the corporate LAN. But that doesn't guarantee that the user's computer will behave well on the network once it is there. It doesn't ensure that the computer is not hideously compromised, owned by some botnet or riddled with malware.
So, authentication controls are supplemented in some places by fuller-featured health checks, usually referred to as network access control (NAC). NAC systems go beyond verifying that users or machines are known, to signing off on the system's initial good health. NAC checks, among other things, to be sure that there is an antivirus program running, that the system has passed a scan and that its operating system has been brought up to date. The more current systems incorporate ongoing behavioral analysis, which watches what a system does once on the Net and takes remedial action if it goes astray.
LAN edge switch security functions and NAC
Defense-in-depth requires that networking teams use edge switches as part of the security infrastructure. ACLs, VLANs and authentication form the base of edge security; NAC sits atop this base to further mitigate risks. It is usually driven by intelligence in the data center or network core, such as policies defined and propagated from a central management point or directories of users that are allowed to use the network.
However, some vendors, such as ConSentry, Napera and Fortinet, put all the intelligence as well as the enforcement in edge devices, making deployment in theory simpler, especially in smaller networks. But NAC requires at least the participation of edge switches if it is really going to protect the network. Authentication for edge access is the first and most important hurdle that systems must clear in most NAC installations. Beyond that, failure to pass tests requires use of edge device VLANs or port-disablement as controls on "bad" systems.
Whether NAC is edge-driven or simply edge-enforced, initial health checks require a tamper-resistant agent on the endpoint that can verify that some software is running (e.g., an antivirus) and other software is not (e.g., various kinds of spyware). In the Windows world, several NAC solutions use Microsoft's Network Access Protection client for health checks. Others supply their own agent.
Implementing health checks at the LAN edge
The specifics of implementing health checks vary dramatically from system to system (more than ACLs or even authentication configurations). In spirit, they resemble ACLs:
Vlan-hosts fail antivirus-check isolate
Vlan-guests fail antivirus-check allow remediate-vlan
Wlan fail OS-check allow remediate-vlan
Adding health checks can bring down the incidence of compromised machines being used on the LAN. ACLs and VLANs can protect edge devices from one another and can limit the range of attacks possible against data center targets, but they can't see that more subtle attacks are under way. Adding behavioral analysis can make even subtle attacks visible if they entail doing anything over the network that a user wouldn't normally do.
So, on networks with significant numbers of transient users (as in a company making extensive use of contractors, or in a university) or where IT control of desktops is minimal, NAC may be an excellent precaution. NAC will be most useful on wireless LANs and other segments with temporary users or lots of laptops that leave the LAN regularly. In a smaller organization with a more static user population, it is nearly always overkill. Before undertaking a NAC deployment involving added gear, all organizations should exploit whatever edge switch security they have available; and if they are Windows users, they should look at NAP.
About the author: John Burke is a principal research analyst with Nemertes Research, where he focuses on software-oriented architectures and management. As an analyst, John draws on his experiences as a practitioner and director of IT to better understand the needs of IT executives and the challenges facing vendors trying to sell to them. A frequent speaker, his career began at The Johns Hopkins University, where he supported the engineering faculty in its use of computers in research and teaching. He moved on to systems and network administration at The College of St. Catherine, in St. Paul, MN, and then to directing staff in voice, data, desktop and systems management at the University of St. Thomas, also in St. Paul.
This was first published in March 2010