What comes to mind when you hear about Network Access Control (NAC)? Visions of the “self-defending network” deftly wiping out viruses and spyware before they can take hold? Or is it visions of multimillion dollar switch upgrades, complaining users, and endless pain?
Though NAC has not yet made it into the big time, reports of its death have been greatly exaggerated. In fact, it is likely that NAC could see a resurgence, fueled by the widespread adoption of Wi-Fi. NAC and Wi-Fi have the potential to become best friends – both with each other and with the IT security manager.
Since the adoption of the high-speed 802.11n standard by the Wi-Fi Alliance, Wi-Fi has been attracting attention in all enterprise industry segments. In part, this has been driven by initiatives underway in IT organizations such as network edge rightsizing, which attempts to cut recurring networking costs by moving as many users to Wi-Fi as possible. When the types of users and applications make Wi-Fi appropriate, the cost savings can be huge.
So what does NAC have to do with Wi-Fi? Simply put, once you have deployed a properly secured Wi-Fi network, you've already done most of the heavy lifting required for NAC. This is why it is such a good fit (and in most cases a better fit) for Wi-Fi versus wired connections and what is fueling its comeback. If you retrofit NAC onto the wired network, for all practical purposes you need to do it all at once – every port, every client, all during the same maintenance window. With Wi-Fi, you have the control to enable one client at a time for NAC, or just turn it on as you enable each client system for Wi-Fi. This makes your initial rollout simpler and more cost efficient.
But it's not just about rollout. Let's walk through all the great security features NAC brings to your Wi-Fi network.
A key consideration is authentication. A properly secured Wi-Fi network will have each client authenticated using 802.1X, as mandated by the WPA (Wi-Fi Protected Access) standard. You can choose to authenticate the device, the user, or both. And here's where the first bit of NAC creeps in – a fundamental premise of NAC is admitting people who should be on your network, and denying access to those who shouldn't. Just by turning on authentication, you've completed the first and most important phase of NAC.
Another function of NAC is to control access based on client posture or health -- for example, the status of anti-virus software and the date of the last A/V scan. Authentication provides an early opportunity for NAC to intervene when a client is non-compliant with IT policies. During authentication, information is being sent from the client to an authentication server already – so why not piggyback a client health report on that authentication request? If the user's device is compliant, the authentication server and NAC policy engine return an “Access Accept” message and the client goes on its way. But if the client is out of compliance, the Wi-Fi infrastructure can be signaled to quarantine the device from the network, either through VLAN segregation or through firewall policy. Once the client device has been brought into compliance – a technique known as remediation – the quarantine condition can be removed and the client allowed onto the network. This entire process can be completed in a few seconds during the authentication phase, without the user noticing that anything happened.
NAC also needs to know who the user is to be most effective. Is the user the big boss who should never be denied access, or the IT manager who should be allowed to have non-compliant operating system patches? Authentication, tied to an enterprise directory service like Active Directory or LDAP, can provide this information by looking at group membership of each individual user. Different NAC policies can be applied depending on group membership or user identity, so that instead of creating a NAC exception for that printer on the third floor, you simply tell the NAC policy engine that members of the “printers” group don't need to comply with anti-virus software requirements. Again, this is all accomplished during the few seconds when authentication is taking place.
Another thing to realize about NAC is its flexibility to adapt to your network needs. For example, let's say you need to make NAC optional because you have a huge population of Linux users, and you can't find client software for these systems that is compatible with your NAC architecture. And what about companies that have a number of employees with iPhones and other handheld devices, which run a full computer operating system but don't support enterprise security tools like anti-virus software? This is an extremely common situation in higher education, where there is no central IT control over client computing devices.
Looking at the example of anti-virus specifically, one option is to purchase an inline anti-virus appliance and install it in the network, letting it filter all network traffic to find and eliminate viruses. But this is less than optimal, as you'd need one of these appliances behind every single closet switch in the organization. Plus, an inline appliance filters everything, even from clients who have already passed NAC compliance checks because they run their own anti-virus software.
This is where Wi-Fi and NAC again provide us with an advantage. Even though Wi-Fi access points are distributed far and wide throughout your buildings, modern enterprise Wi-Fi systems typically transport all network traffic back to a central controller – this is the so-called Thin AP model. The Wi-Fi controller is typically located in a datacenter or other central location, and it's easy at that point to add inline appliances. What's more, if the Wi-Fi controller is smart enough to understand user identity and NAC posture, it can selectively send traffic to security appliances only from non-compliant devices. Clients that pass NAC posture checks can be given unfiltered access to the network, while clients that cannot validate their posture will have security services provided by the network – all unobtrusively, without the end user seeing any difference.
These ideas about Wi-Fi + NAC are starting to catch on in the industry. Many IT managers have expressed keen interest in implementing some form of network authentication, and Wi-Fi provides them a path forward that is much less expensive than retrofitting authentication onto a wired network. Do nothing more than implement authentication and you've already taken a huge step towards improving network security. The next step – posture or health checking – is less popular today, but much of this results from confusion over the many competing NAC architectures that are available. The Trusted Computing Group (TCG) is trying to address this problem through its Trusted Network Connect (TNC) working group, which specifies standardized interfaces through which NAC components talk to each other. Many NAC architectures, including Microsoft's Network Access Protection (NAP), are fully compatible with TCG-TNC, making the decision to implement NAC much less risky than it used to be.
Time will tell if NAC's comeback will happen, but certain facts are undeniable: Network security is still an issue. Compliance requirements are increasing. The expense and negative publicity associated with a security breach still hurt business. NAC provides an avenue to address all these concerns, and it is far easier – and more secure – to implement NAC with Wi-Fi than it is to implement NAC on a wired network. As more and more enterprise organizations embrace Wi-Fi, it seems probable that we'll soon see NAC and Wi-Fi become “best friends forever.”
Though NAC has not yet made it into the big time, reports of its death have been greatly exaggerated. In fact, it is likely that NAC could see a resurgence, fueled by the widespread adoption of Wi-Fi. NAC and Wi-Fi have the potential to become best friends – both with each other and with the IT security manager.
Since the adoption of the high-speed 802.11n standard by the Wi-Fi Alliance, Wi-Fi has been attracting attention in all enterprise industry segments. In part, this has been driven by initiatives underway in IT organizations such as network edge rightsizing, which attempts to cut recurring networking costs by moving as many users to Wi-Fi as possible. When the types of users and applications make Wi-Fi appropriate, the cost savings can be huge.
So what does NAC have to do with Wi-Fi? Simply put, once you have deployed a properly secured Wi-Fi network, you've already done most of the heavy lifting required for NAC. This is why it is such a good fit (and in most cases a better fit) for Wi-Fi versus wired connections and what is fueling its comeback. If you retrofit NAC onto the wired network, for all practical purposes you need to do it all at once – every port, every client, all during the same maintenance window. With Wi-Fi, you have the control to enable one client at a time for NAC, or just turn it on as you enable each client system for Wi-Fi. This makes your initial rollout simpler and more cost efficient.
But it's not just about rollout. Let's walk through all the great security features NAC brings to your Wi-Fi network.
A key consideration is authentication. A properly secured Wi-Fi network will have each client authenticated using 802.1X, as mandated by the WPA (Wi-Fi Protected Access) standard. You can choose to authenticate the device, the user, or both. And here's where the first bit of NAC creeps in – a fundamental premise of NAC is admitting people who should be on your network, and denying access to those who shouldn't. Just by turning on authentication, you've completed the first and most important phase of NAC.
Another function of NAC is to control access based on client posture or health -- for example, the status of anti-virus software and the date of the last A/V scan. Authentication provides an early opportunity for NAC to intervene when a client is non-compliant with IT policies. During authentication, information is being sent from the client to an authentication server already – so why not piggyback a client health report on that authentication request? If the user's device is compliant, the authentication server and NAC policy engine return an “Access Accept” message and the client goes on its way. But if the client is out of compliance, the Wi-Fi infrastructure can be signaled to quarantine the device from the network, either through VLAN segregation or through firewall policy. Once the client device has been brought into compliance – a technique known as remediation – the quarantine condition can be removed and the client allowed onto the network. This entire process can be completed in a few seconds during the authentication phase, without the user noticing that anything happened.
NAC also needs to know who the user is to be most effective. Is the user the big boss who should never be denied access, or the IT manager who should be allowed to have non-compliant operating system patches? Authentication, tied to an enterprise directory service like Active Directory or LDAP, can provide this information by looking at group membership of each individual user. Different NAC policies can be applied depending on group membership or user identity, so that instead of creating a NAC exception for that printer on the third floor, you simply tell the NAC policy engine that members of the “printers” group don't need to comply with anti-virus software requirements. Again, this is all accomplished during the few seconds when authentication is taking place.
Another thing to realize about NAC is its flexibility to adapt to your network needs. For example, let's say you need to make NAC optional because you have a huge population of Linux users, and you can't find client software for these systems that is compatible with your NAC architecture. And what about companies that have a number of employees with iPhones and other handheld devices, which run a full computer operating system but don't support enterprise security tools like anti-virus software? This is an extremely common situation in higher education, where there is no central IT control over client computing devices.
Looking at the example of anti-virus specifically, one option is to purchase an inline anti-virus appliance and install it in the network, letting it filter all network traffic to find and eliminate viruses. But this is less than optimal, as you'd need one of these appliances behind every single closet switch in the organization. Plus, an inline appliance filters everything, even from clients who have already passed NAC compliance checks because they run their own anti-virus software.
This is where Wi-Fi and NAC again provide us with an advantage. Even though Wi-Fi access points are distributed far and wide throughout your buildings, modern enterprise Wi-Fi systems typically transport all network traffic back to a central controller – this is the so-called Thin AP model. The Wi-Fi controller is typically located in a datacenter or other central location, and it's easy at that point to add inline appliances. What's more, if the Wi-Fi controller is smart enough to understand user identity and NAC posture, it can selectively send traffic to security appliances only from non-compliant devices. Clients that pass NAC posture checks can be given unfiltered access to the network, while clients that cannot validate their posture will have security services provided by the network – all unobtrusively, without the end user seeing any difference.
These ideas about Wi-Fi + NAC are starting to catch on in the industry. Many IT managers have expressed keen interest in implementing some form of network authentication, and Wi-Fi provides them a path forward that is much less expensive than retrofitting authentication onto a wired network. Do nothing more than implement authentication and you've already taken a huge step towards improving network security. The next step – posture or health checking – is less popular today, but much of this results from confusion over the many competing NAC architectures that are available. The Trusted Computing Group (TCG) is trying to address this problem through its Trusted Network Connect (TNC) working group, which specifies standardized interfaces through which NAC components talk to each other. Many NAC architectures, including Microsoft's Network Access Protection (NAP), are fully compatible with TCG-TNC, making the decision to implement NAC much less risky than it used to be.
Time will tell if NAC's comeback will happen, but certain facts are undeniable: Network security is still an issue. Compliance requirements are increasing. The expense and negative publicity associated with a security breach still hurt business. NAC provides an avenue to address all these concerns, and it is far easier – and more secure – to implement NAC with Wi-Fi than it is to implement NAC on a wired network. As more and more enterprise organizations embrace Wi-Fi, it seems probable that we'll soon see NAC and Wi-Fi become “best friends forever.”
