Before the 4h, I posted on the access control-side of NAC. I compared it with web access control and examined some similarities. This week, I want to look at the other side of NAC: admission control.
NAC as Network Admission Control
Treating NAC as admission control is more of a network/threat-centric approach. There are some basic characteristics of NAC as admissions control:
• Health and configuration validation and remediation
• Machine authentication to the network infrastructure
• Assignment of IP address
Health checking is a common NAC function. This is just good house keeping and it is something that every organization, big or small, needs to do. There are a variety of ways to check the health state of a connecting end-point and most are fairly simple to do. The challenge is managing the remediation of a sick end-point. This is where the real skill of NAC vendors (and a lot of time – their partners) comes into play. How do you quarantine? What configuration management and software distribution tools are used to remediate the problems? How do you orchestrate all of these pieces working together? This is non-trivial work and there are a lot of vendors out there doing really great stuff.
The next two items are not truly mandatory functions for admission control, but they are important nonetheless. Some form of machine authentication is lumped in here: RADIUS, 802.1x, EAP. This is one approach to ensure that only organization-owned laptops are on the network. What concerns me is the conflation of me for my laptop. In order to truly understand what is going on inside the network, user and machine identity have to be treated separately. I am not my laptop and my laptop is not I.
Last, getting an IP address is the last aspect of admission. Some NAC vendors integrate with DHCP services to orchestrate all the necessary steps for admission including address assignment. I’m not saying that DHCP services need to be embedded into the same product that does health analysis, but it is the last step to network admission and should be treated with importance.
Will the real NAC please stand up?
In conversations, blog entries, analyst papers, which NAC is being discussed? I feel that both are necessary to have a complete story, but each side has a different heritage and mindset. Using NAC as an abbreviation blurs the distinction between what is required for admission versus access control. We can do better. Anyone up for renaming this market Network Admission and Access Control – NAAC?
I really like the current capabilities and promise of NAC. I do, however, have a problem with the abbreviation, specifically, the “A” in NAC. Which do people mean when they say NAC: “network admission control” or “network access control”? To me, there are big differences between the two.
NAC as Network Access Control
If you have an identity background, when you hear NAC, you think, “Oh, this is web access control for the network.” If that’s the case, then NAC needs to have some features that mirror WAC. For example:
• Identifying the user is key.
• There needs to be a centralized policy store that describes access control.
• There needs to be a fine level of granularity of those policies.
• There needs to be some modicum of single sign-on.
• There’s going to be some form of the proxy versus plug-in fight.
User authentication has always been a part of web access control, and network access control should be no different. WAC vendors have all sorts of mechanisms to authenticate the user either directly or through other authentication providers. NAC vendors do, but, I conjecture, not in the same way. There are two flavors here: explicit and implicit. Explicit NAC authentication involves the end-user in an authentication event. Forcing the user to authenticate to RADIUS is a form of this. Implicit authentication uses authenticated credentials from something higher in the stack (like the operating system) and not involving the end-user in an extra authentication event.
Centralized policy store — yes, they exist. The market has no problem building policy stores. In fact, as I have mentioned before, there are too many policy stores out there today, with little integration and hierarchy to them. Can I use a single policy tool for all of my identity-based access control? Nope, not yet. I have heard from numerous people: “I already use vendor X’s web access control tool. Can I use it to describe policies for network access control?” The funny thing is this existed nearly 10 years ago. DASCOM’s IntraVerse had both a web component (WebSeal, part of IBM Tivoli’s Access Manager for e-business) and a network component (NetSeal, which lived about as long as a drummer for Spinal Tap.) What’s old is what’s new, and I guarantee that in the next couple of years we’ll see a return of this model for a variety of reasons.
Fine-grained policies — can I describe a network access policy down to the object level: file, row, transaction, etc.? Kinda, sorta, maybe. There are vendors that do this, but they are typically application specific. There is a gap between that level of control that various products provide and more general network access control. Part of the issue is that getting a NAC product deep enough into an application to get that level of granularity isn’t easy and requires modifying and/or distrupting the application. Further, as anyone who has ever tried to maintain group permission information knows, the more objects you want to tie to group permissions the harder it gets to work with. (This is why user-provisioning tools have shied away from group management at any deep level.)
WAC products had basic single sign-on, at least for the applications they protected. If NAC is really an offshoot of WAC, you’d expect the same. Does this mean that Imprivata and Passlogix and the like are NAC vendors? I think that’s a bit of a stretch. Will NAC vendors grow PAM modules? Someday, but not any time soon.
Back in the day Netegrity and IBM fought it out over the best architecture for web access control. Was it better to deploy proxy servers to control access or plug-ins to application servers? At the end of the day, the answer was: it depends. Both vendors supported both. Will this architecture difference arise in NAC-land? I wouldn’t be surprised if it did. We already see SSL VPN vendors acting as a form of proxy server. Could we see a rise in plug-ins to applications running on the network to provide extended NAC services? Maybe, but I think we’ll see SPMLv2 adoption before we see NAC plug-ins for applications… either way — don’t hold your breath.
After the 4th, I’ll be back to examine the other “A” in NAC – admission.
That question was asked by a guard at Department of Homeland Security’s headquarters. Bruce DeCell, a retired New York City police officer, presented identification. What he actually presented and was accepted as valid ID is quite amazing. You have to read this Washington Times article to believe it.
Clearly, Mr. DeCell’s name was matched against the list of vetted guests for the day. Other than his name, clearly no other component of his ID was even remotely examined. This isn’t much different than the “check the name game” that the TSA has us go through at airports.
It seems pretty simple to me, if you are going to ask for identification, at the very least you ought to examine the entire piece of identification: not just the name, not just the picture.
Further, if people are checking credentials, they need trustworthy systems to validate those credentials.
At least DHS did one thing well, after (poorly) being authenticated, Mr. DeCell was escorted constantly. You can come in, but I am going to watch every move you make.