I gave a presentation at the MIS Training Institute IT Security World 2007 conference in San Francisco, and I when finally got done (I went a bit long) and a few people were left, I asked if there were any final questions. One of the attendees asked, "Is NAC ready for deployment?" A simple enough question, and I hemmed and hawed trying to sort through all the special-use cases, exceptions, and whatever accounts for accumulated conventional wisdom.

"No, unless you have a clear-cut need that NAC will solve," I finally replied. Thing is, the NAC market space is still quite young and the products are evolving pretty quickly. In some cases, the product features are oversold. In other cases, the features are just missing. Deploying NAC now is still very much in the early-adopter phase and lessons are being learned by adopters and vendors. The system engineers who have come to the lab describe similar issues at sites they have visited, like undefined policies, poorly thought through policies, very heterogeneous networks, and misconceptions about the features and functions of NAC to name a few. One point is clear: NAC vendors are adding features to their products to meet existing customer or to complete a sale, which makes for a very confusing market to even find out what is available much less make a purchase decision. What happens if a vendor makes a product change that goes in a direction counter to your needs?

A successful NAC deployment will take work and time. You will need to run a pilot project not only to get experience with the products, but also to figure out how to write access control criteria and policies. What is your organizational policy when a guest needs to access your network and can’t change his computer configuration to meet your local corporate policy? Depending on your NAC product, you could have one or more actions available to you. You need to figure out what happens ahead of time. Without best practices built up over time, making the right decision is difficult. Restrict access too much, and productivity suffers or users find workarounds. Don’t restrict access enough and access control becomes pointless.

• How is guest access assigned and what access do guests receive?
• What happens when a guest needs access outside the defined guest policy?
• Are you concerned with malicious attackers breaking into your network, rogue employees, or casual users? (The “strength” of the product will play a role here.)
• Are any desktop security products like antivirus, firewall, or anti-spam acceptable or only certain products? If the latter, which products and, equally important, why?
• How many and what kind of changes to your network infrastructure are you willing to make?
• Does your NAC product need to integrate with existing services like centralized logging, help desk, and network management and how important are each?
• If you have remote offices, will they also have NAC products deployed? How will unsupported client devices like PDAs and laptops be supported, if at all?
• Do you want to control access to network resources or just access to the network in general?

When you answer questions like these and more that you develop during research and piloting products, you will begin get a better feel for what you need and what is available.