There was good audience participation so I only had to pull out 1 or 2 “canned” questions in the time allotted. I’ve tried to summarize the points and information that we learned from this exercise below. These are in no particular order.

1. No clear definition of NAC
One of the first questions from the audience was about barriers to NAC adoption. One of the vendors replied with the question “what does NAC mean to you?” This person wanted NAC to do machine based authentication with no posture assessment. The next speaker wanted user authentication and posture assessment. A third was looking for post-connect NAC, *cough* IPS *cough*. Yet another wanted machine based authentication followed by user authentication. There was also discussion of machine provisioning on the network based on an HR event. As we have heard before, the definition of NAC is a moving target.

2. Lack of executive buy-in kills
No big revelation here. Without proper senior management participation, understanding and approval almost any initiative will fail. What is interesting is the fact that within this group the challenge of selling NAC to upper management seemed to be more of a barrier to deployment than cost or complexity, the ones usually cited. My guess is that NAC may be an organizational or cultural challenge that is more common in “academic” environments where people may be used to doing what they want with less oversight. That is just a guess on my part. Cost was not mentioned once as an issue.

3. 802.1x is still a long way out for wired deployments
Most security professionals will agree that 802.1x authentication is the preferred enforcement mechanism for NAC. IP’s can be changed, MAC’s can be spoofed but digital certificates pose a formidable challenge to forge. All 3 vendors said that in their experience 90% of wireless NAC deployments use 802.1x. The reason cited was ease of configuration on the client side and general wider acceptance of the protocol. On the wired side that equation was reversed with only 10% deploying 802.1x. Supplicant issues and the prevalence of devices that may not be able to have a supplicant (printers, VOIP phones, etc.) were said to be big issues.

4. Support for non-Windows clients still developing
The majority of the audience organizations have significant numbers of non-Windows clients, specifically Mac’s. We get it. Windows is on 90 something percent of the enterprise desktops. That number is changing. More and more companies are offering choices on the desktop / laptop. The NAC vendors present had different levels of support for non-Windows. Some could do authentication only and some could do posture checking if the NAC device was in-line. Note to NAC vendors: Mac support is not a nice to have any more. Mac will have an ever increasing presence on the desktop. The NAC options should be the same for Windows and non-Windows. I do recognize that Linux is a little more of a challenge due to the variants and much further behind Mac in the desktop OS race.

Some of the other take-aways were:
Make sure you have an accurate inventory of network connected devices
Do not underestimate the increased help desk utilization
Automated remediation is not as common as self-remediation in deployments

Those were the ones worth mentioning. Let me know if any of these jump out at you.

–Chris

Technorati Tags: NAC, Network Access Control

It seems hard enough to get companies to stop using flat networks and segment them with VLAN’s. Now go tell Mr. Network Admin he has to enable 802.1x on his switches (if it is supported), on top of VLANs. Been there and it’s not as easy as it may sound. Alan even mentions this in a different post here. That’s why you see people accepting technologies like Microsoft’s NAP that uses DHCP for NAC, arguably the most insecure and easiest to bypass. It’s relatively cheap and requires minimal (if any) network configuration as compared to an 802.1x solution from StillSecure, Vernier, Lockdown, etc.

Don’t get me wrong. I think that an 802.1x based NAC solution is the most secure solution without question. I’m just pointing out why I think there is a market for products that use what may be less secure methods of implementing NAC.

–Chris

Technorati Tags: NAC, Network Access Control, StillSecure, ARP spoofing, 802.1x