No Comments
Written by jj on March 8, 2010 – 5:40 pm
Universal NAC Feature Model document:
A guide to model and compare NAC solutions
Author: Jennifer Jabbusch
White paper, feature and mechanical evaluation and comparison of Network Access Control technologies
24 pages, PDF format
2010-03-03 RSA Edition, first release
Copyright Carolina Advanced Digital, Inc., see contact page to request republishing rights
Document Summary
All NAC products are not created equal and there is not a one-NAC-fits-all solution. The Universal NAC Feature Model was developed for internal use at Carolina Advanced Digital and is invaluable in informing and guiding discussions with clients evaluating NAC solutions. Initially intended for private use, the value to the larger industry has led to the development of this material in guidebook form.
One of the leading challenges in discussing NAC is the terminology. Instead of referring to vendor terms or the random acronyms and naming convention used in the NAC frameworks, this guides uses plain English to describe the four feature components of network access control systems and the specific mechanics used to implement the technologies.
This Universal NAC Feature Model is a guide for organizations to model network access control (NAC) features from a variety of products and vendors. It aids in the comparison and analysis of available features and provides a common language to identify and describe required methods and execution of technology. This allows for useful comparisons across vendors who offer the same features, but with drastically different methods.
This document breaks down all the components and mechanics employed by various vendors, explains each piece in detail, and provides commentary on factors to consider while investigating NAC products. The tables and explanations in this guide can be used to map key concepts to their vendor- specific counterparts and map a desired feature to the mechanics that support it.
To all readers, I hope you enjoy the information in this guide and find the layout and explanations useful. As far as I know this is the first document of its kind, outlining the full depth and breadth of NAC features, functions and mechanics from all vendors, in a single guide. I expect it to serve as a foundation for discussions in the industry and in dialogue between consumers and vendors.
This document provides:
- A uniform terminology and descriptions of features and technical mechanics to compare all NAC products currently available.
- A hierarchical view of NAC features and mechanics in a simple one-page table.
- An explanation of the technical mechanics of NAC and commentary on considerations as you investigate NAC solutions.
- A foundation that will grow and be updated as technologies and products change in the market.
Related documents: Catching the Unicorn: a technical exploration of why NAC is failing
# # #
1 Comment
Written by jj on March 5, 2010 – 8:36 pm
I’m not going to recount what was said during the session; RSA’s Peer 2 Peer sessions are gracefully excused from the promiscuous ears of the media. I do, however, want to share a few thoughts, revelations and take aways I have from the session.
Were you in the session? Before I launch into my opinions, I’m most interested in hearing from anyone that was in the Peer 2 Peer. As the facilitator, I get a different kind of value from these peer sessions. The real question is: did you? Feel free to post comments (anonymous is fine) or email me directly using the contact form.
First, NAC is not dead. Wednesday’s full room was proof of that; I think we had only a couple of seats open of the 25 maximum available. I will share with you that these P2P attendees were a little disappointed that the industry events were not giving NAC the attention they did just a couple of years ago. Everyone understands why, but their comments resonated with me. They feel abandoned by the vendors and the industry; left to fend for themselves and work out the many major kinks of a security technology that’s not as ready for prime time as we’d hoped. We lamented over the decrease in industry’s willingness to help us in our efforts and the obvious lack of NAC sessions on the schedules of major conferences, such as RSA and the upcoming INTEROP.
Second, people do want NAC. The interest seems to be completely in line with my personal observations that port security and authentication are still highest on the list of requested features, with a strong desire for endpoint integrity sliding in as a solid second or third. These are the features being touted by the primary remaining vendors in the NAC and endpoint security space and there IS a demand for them.
Third, the consumers are happy to compromise. Instead of selecting from a menu of over-zealous vendors pitching their fix-all solutions, the consumers want more reasonable expectations, more manageable deployments and a sustainable maintenance plan - and they don’t mind giving up a few features to reach those goals. The stories I heard were ones of heartache, headache and hopelessness, riveted with frustrations, mostly stemming from the use of the wrong technology in the wrong environment. Although there were vendor-specific tribulations mentioned by the group, I steered clear of that part of the discussion, realizing that the failure wasn’t in the product as much as it was in the processes created by poorly made technical decisions. Unfortunately, these people are at the mercy of the vendor to help them with the process and many times the vendor’s sales force (and even at times, the engineering team) doesn’t understand enough about the environment and their own product to make recommendations for a successful rollout.
As promised, I did distribute the Universal NAC Feature Model document to the group (well, until I ran out of printed copies). I’ll make that document available here as well this weekend. Now available.
With the confinement of a short 50-minute, session, we certainly couldn’t solve the evils of the NAC world, but it got everyone talking and it got me thinking - again. We can do this. We just need to make it affordable, efficacious and reasonable to integrate. It is possible, and the session reinforced my support for the groups working to create frameworks and standards that will help these consumers of the technology (and all others) find the right product for them and integrate it in a much less painful way.
# # #
