InfoSecPodcast.com

This morning at work I moderated a panel discussion on Network Access Control. The audience was made up of IT Security staff from several research and development organizations. There were representatives from 3 vendors in attendance as well. The audience represented a good cross section of NAC adopters. Some have had it for 2 years, some deploying this year while others had future or no plans to deploy NAC.

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