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.
# # #
JJ – thanks for the link and interesting thoughts. Chris got a lot of response on his Lockdown posting which got quoted in Network World this morning.
Personally, we think few vendors sat down and designed a ‘NAC’ product from scratch, and nobody has designed a compelling SME offering. Certainly talking to dozens of SME customers, the business problems exist but the ‘NAC’ buzzword doesn’t hold a lot of meaning for them.
Many of the solutions on the market today started off as large enterprise security offerings and got branded NAC when that market was thought to be hot a few years ago. Likewise, building a compelling SME product from a large enterprise technology is rarely feasible.
You don’t revolutionize the networking market or solve a customers problems by taking your existing product and trying to call it something else.
Stop by and say hello at RSA!
Todd
Hi Mike,
Thanks for stoppin’ by!
Thanks for the note- and I do agree. What I see though is pieces of standards in the NAC puzzle that are still settling in.
Just last year, the parties were still fighting over whose EAP method would be standard… for a standard that began in 2001, that’s still pretty recent flux.
And now, they (vendors) are still integrating the new features like the real-time posture checking and the newer RADIUS attribs into the product.
While I do get to talk to them pretty regularly and see what they’re doing, or planning to do, I gauge what’s really going on by how often I have to update my lab equipment…
And I tell ya- over the past couple of months, by the time I get it loaded up and set in demo mode, a new revision is out. Finally I decided to just WAIT for a few weeks. If I’m doing that, chances are some customers will be too! LOL
-jj
JJ, I like reading your blog. Keep ’em coming.
The NAC standards aren’t in flux. The TNC standards are pretty much done and implementable, though few vendors are implementing. Maybe we will start to see more vendors developing to the API’s. Microsoft’s NAP and Cisco’s NAC are both chugging along. 802.1X is baked.
The IETF NEA is only a nod to involve Cisco into the NAC standards process. In fact, the *only* documents submitted so far are the TNC standards. Talking to Steve Hanna, he expects any changes to the NEA proposals will be reflected in the TNC docs, so the trouble is just in keeping the two sets of standards in parity.
What is in flux is adoption of standards for different parts of the NAC system, which are host assessment, policy server, and enforcement (there may be others, but these three are the basics). I don’t know how many vendors are actually supporting or developing for TNC outside of Juniper, but from the vendorsI have talked to, there isn’t much uptake, yet. The common response is "when there is demand, we will follow."
Support for NAP is a no brainer for those vendor that perform host assessment and with submission and acceptabce of Microsofts Statements of Health to the TNC, ought to drive more support. Support for Cisco NAC is good for all Cisco shops, but that just means more lock-in to Cisco gear.
The standards are there and being developed. The "market" has to decide what it wants.
Mike
Hi Rob- You’re correct in some aspects, but I have to disagree/clarify on a couple of points…
First, certainly the first steps in a network security solution would include wiriting the policies that dictate the purpose and mechanisms of the solution. Without that, you don’t have a solution -you have a bunch of IT guys throwing policies on a box. It’s the first thing out of our mouth at a meeting or presentation and I couldn’t agree with you more on this.
Secondly, you’re right- NAC doesn’t really offer a solution for file-level access rights, but- it’s not supposed to. That again points to the issues of our industry and our lack of educating our customers as to what we’re REALLY offering, how and why.
Lastly, I have to disagree with you on your assessment of endpoint solutions… several NAC vendors have a very strong story in managing user-access, including per-user ACLs, and offering aditional per-user services such as QoS as well as detailed accountint for this access.
NAC does solve a lot of issues, but perhaps not the ones the customers THINK it’s going to solve.
-jj
Your comments are probably accurate for the NAC space.
NAC may solve a few customer problems, but they are the wrong problems. What is the business case? Where is the value? IS it comprehensive? I think customers do not see it and that is why they are slow to buy.
Network security, no matter how granular it gets, will not prevent information-centric security. Proper imformation-centric security
Where does NAC provide an answer to the core IT security question of "which users have access at the data file level and what are they are they doing with that data" ?
Since any endpoint solution is only the most basic of proxies for user access to the infrastructure, I would say a few other NAC vensors are probably heading towards the same fate as Lockdown.