Thursday Nov 23
What’s holding back NAC?
Updated on Saturday, 28 January 2012 07:07

We’ve all been watching some of the pioneering NAC vendors domino down over the past several months. The Lockdown tumble has some questioning the industry again, and as Alan notes, these happenings fuel the fires of NAC’s nay-sayers. (In my opinion, it’s like throwing metal onto open flame… may affect the metal, won’t feed the flame, makes for great steaks).

Chris, an ex-Lockdowner, gives his take on the NAC industry in his recent post-Lockdown blog and I’m in general agreement, but perhaps for different reasons.

I don’t see NAC going away. It definitely has some growing to do, but it will grow and it will be successful. The truth is, NAC has the potential to solve several customer problems and ease a variety of pain points, both for IT and management. If done right (and for the right reasons), it’s both a great technological tool and a business asset.

So, what’s holding back NAC?

Vendors, in a large part, are to blame. Sorry guys, but it’s true. Vendors are causing NAC to be lost in translation, most often because the vendor…  a) doesn’t understand the technology themselves (sales reps),  b) is erroneously pushing their product as a solution to today’s top issue, c) has overestimated the solution and underestimated the project and d) is ultimately trying to make a sale, and so is willing to squish their round peg into your square hole. (okay, no comments on that one).

Vendors will have to start showing they understand when and where their product fits (and when it doesn’t). Until then, I don’t think they’re going to garner enough trust to walk in the door with a solution and close the deal without the customer first exploring (at length) other options and getting other opinions.

Misinformation. Whether it’s due to vendor misinformation or lack of self-education, what I’ve learned is that most organizations have heard of NAC and have a partial understanding of what it does, and really no idea of how. They’ve heard vendor pitches of the wonder-drug cure-all that will solve guest access, or remote access security, endpoint protection, user accounting, etc but they really don’t understand where the technologies came from, what their purposes are, and which pieces of solutions are standard, and which are proprietary.

When I talk about NAC, I find myself constantly apologizing for the industry. We’ve done a great job telling people why they need NAC, but so far we’ve failed horrendously at educating them as to how it’s all supposed to work. Personally, I revamped all my presentations, tabling the technical dives and replacing them with technology primers.

Terminology Twists. The other hardship I see for organizations is the lack of standard terminology. A lot of vendors out there are touting a NAC product- but what does that really mean? It could mean anything- it could mean endpoint integrity or posture checking, it could mean quarantine automation, it could mean a solution for guest provisioning,or  remote access checking. This makes it hard for organizations to parse out the various vendors’ features. Depending on whose Kool-Aid you’re drinking, an ‘enforcer’ could be a software agent, a switch, firewall, or even a computer. 

In order for NAC to grow and find wide adoption, I think we’ll have to see some consistency and consensus in wording and terminology. NAC is a big undertaking, and when entering a commitment like that, organizations need to know exactly what they’re getting to have that warm and fuzzy feeling.

Standard Stalls. The ABC users are, for the most part, seeking standards-based solutions. I think we have a great answer to that, and we’re heading down all the right paths with the IEEE and IETF standards, as well as groups like TNC. But, the truth is, the 802.1X and NAC standards are in constant flux… in a good way… but still in flux. Although we have a great framework in place, some folks are waiting for the dust to settle on Planet NAC before committing.

Once the standards (ie new RADIUS attributes) start to solidify and the changes slow down a bit, I think that will add to the feeling of stability that customers are looking for in a NAC solution.

Migration Migraines. Last, but not least… most organizations that want to migrate to NAC just don’t know where to start, or how to proceed. They need help, either from their vendor, or from an integrator. (That’s where my company fits into the NAC picture). I’m actually working on a detailed migration white paper that will be delivered at a conference later this year.

If we (the industry) want to win the business, it’s up to us to hold our customers’ hands and provide a clear strategic and technical migration plan for them.

# # #