I was reading a NAC post by Alan Shimel (gee, what a shock), and it brought up one of my pet peeves about NAC. Now I will fully admit that NAC isn’t an area I spend nearly as much time on as data and application security, but I still consider it one of our more fundamental security technologies that’s gotten a bad rap for the wrong reasons, and will eventually be widely deployed.
The last time I talked about NAC in detail I focused on why it came to exist in the first place. Basically, we had no way to control what systems were connecting to our network, or monitor/verify the health of those systems. We, of course, also want to control which users end up on our network, and there’s been growing recognition for many years now that we need to do that lower on the OSI stack to protect ourselves from various kinds of attacks. Here’s how I’ve always seen it:
- We use 802.1x to authenticate which users we want to allow to connect to our network.
- We use NAC to decide which systems we want to allow to connect to our network.
I realize 802.1x is often ‘confused’ with NAC, but it’s a separate technology that happens to complement NAC. Alan puts it well:
- Authentication is where we screwed up. Who said NAC was about authentication? Listening yesterday you would think that 802.1x authentication was a direct result of NAC needing a secure authentication process. Guys lets not put the cart in front of the horse. 802.1x offers a lot of other features and advantages besides NAC authentication. In fact it is the other way around. NAC vendors adopted 802.1x because it offered some distinct advantages. It was widespread in wireless networks. However, JJ is right. It is complex. There are a lot of moving parts. If you have not done everything right to implement 802.1x on your network, don’t bother trying to use it for NAC. But if you had, it does work like a charm. As I have said before it is not for the faint of heart.
Hopefully JJ and Alan won’t take too much umbrage from this post, but when looking at NAC I suggest to keeping your goals in mind, as well as an understanding of NAC’s relationship with 802.1x. The two are not the same thing, and you can implement either without the other.
Reader interactions
7 Replies to “NAC Isn’t About User Authentication”
To address a slightly different tidbit in your post: It’s hard to consider NAC a fundamental security technology. It leverages pieces of fundamentals, but it does so in a complex, fraught-with-pain way.
NAC or 802.11x still wouldn’t make my short life of best things a company should do for their security program. It would make the extended list, like “The Next 10 Things To Do.”
Likewise, it is hard to see something quite this complicated someday widely deployed in our disparate networks. I think some new generation of solutions that I can’t even envision yet will have a better chance.
It’s like Windows trying to tie together lots of simple concepts and tools (Unix) into a bigger platform, but instead of the value being the sum of all the parts, it is something less than the sum of all the parts due to the fragility and gaps it leaves.
So, there are other ways to determine if a computer is a corporate asset or not. You could search for a file, registry key, check domain membership, etc. You could snoop on the network to see of the computer attempted to contact the AD and was successful and you can snoop on Windows logon to determine if the user logged on or not.
The reason I think Khaja brought up identification is because it covers more than just authentication and covers cases where you can’t authenticate the user but want to grant access like guests. A case in point, a policy that says if you are not on a corporate asset and therefore can’t authenticate, then you can only access DHCP, DNS, and the Internet.
From a policy stand point, it may not matter if the computer is a corporate asset or not. If all you care about is whether the host is patched and running some kind of host security, then that is all that is needed.
Ooh this is fun…
ALLEN:
802.1X is *NOT* NAC. 1X is just one way to authenticate users; we have other options but it just so happens that none of them are as secure.
RICH & MIKE:
While I agree you don’t HAVE to have authentication to enable NAC functionality, it really doesn’t make sense not to. Here’s why- If the idea is to enforce certain security or policy postures on an endpoint, you’ll have to have different requirements for (for example) domain users vs guests or contractors. If you can’t tell who’s a domain user vs who’s a guest, then how can you possibly apply the correct policy? You can tell your guests they must have Symantec Endpoint Security version 11, etc.
So without some means of identification (via authentication) we can’t move on to the other pieces of NAC enforcement (if you’re looking to do endpoint integrity).
I’m working on finishing posting my “Redefining NAC Series” document (starting here: http://securityuncorked.com/2009/05/redefining-nac-the-series/). In this document, I’m outlining the four components of NAC and explaining the inter-relationships of the four components and how we can reduce cost and complexity by either omitting or streamlining the various components (on a technical level). Authentication is the first of the four pieces discussed.
-jj
Rich,
I wasn’t suggesting that a user identity is tied to a device irrevocably, but it can be tied to a device when the access request is made and remains tied during the session. The presumption being made is if a device requests access and the credential used to authenticate is a user entity, then the user is tied to that device while authenticated. Tieing a user to a device is not new or specific to NAC—lots of operational and security stuff relies on the same presumption.
Your third option, “We can combine both of them to tie identities and systems together, which is probably the best approach for many orgs.” is what Khaja was talking about. That when the access decision is made, all the information required is used which could include username, group/role, host condition, location, time of day, etc, is used to identify the requester and then select the appropriate access policy.
Whether 802.1X is the right or best way to authenticate users during a NAC process is a technical detail. I think the reason why 802.1X is hotly debated within NAC is because while it offers a good way to authenticate users prior to granting any network access, 802.1X is, as JJ points out, difficult to deploy. The technical difficulties can be worked out, the real problem is that 802.1X is a binary decision and offers little in the way of supporting exceptions like hosts that don’t have a supplicant and hosts that are not in your administrative domain. There are technical solutions to these issues, but the organization has to think them through carefully.
Mike,
Thanks for clearing some of that up. I do disagree with Khaja in that authentication/identification *can* be tied to a device, but doesn’t necessarily need to be. A user’s identity is always independent of a device, but can be combined with other factors as needed (I once wrote all this up in a cool model called Dynamic Authentication”).
Here’s what I’ve been thinking:
With 802.1x (without NAC) we can limit who connects to our network based on who they are.
With NAC (without 802.1x) we can restrict what connects to our network. You don’t necessarily need to know the user, depending on implementation.
We can combine both of them to tie identities and systems together, which is probably the best approach for many orgs.
Or maybe I’m just tilting windmills- since if I were running an org I’d want the combined approach, but I think all the incompatibilities make this discussion worth having.
Khaja Ahmed from Microsoft (he was also with Secure Computing and Valicert) pointed out on that panel that identification/authentication is more than just a user/name password. Identity can encompass authentication as well as host condition so that the system making the access decision can authenticate the entity requesting access and ensure that the host complies with some defined acceptable condition. Once the access requester is identified (authentication status + condition), then an access decision is made. Whether the identification gets done via 802.1X (EAP, actually, 802.1X is just the L2 transport) or some other method really makes little difference. I like that expansion of identification to include host condition because that lets you, the NAC administrator determine what is sufficient to your needs to identify a user.
The identification needs to be performed for NAC so that the right policy can be applied. Often people imply authentication as part of that step, but for NAC, user/device authentication is *optional* and can be achieved via 802.1X, passive authentication snooping, some proprietary method, or in the case of MAC authentication, you simply trust that endpoint offering a MAC address is in fact the endpoint you think it is. So no one will argue that 802.1X is a requirement of NAC, but it’s a pretty useful thing to have. Most NAC products will use 802.1X or something else to authenticate users. Commonly, something else might be AD login, Kerberos, CHAP, Tokens, etc.
Anyway, there was more in that session than just 802.1X authentication, but I think the pre-ponderence on 802.1X happened because it is often tied to NAC and as JJ pointed out, can be extremely difficult to implement.
The point in the session that tickled me is when we were talking about the mess that is NAC standards and the panelists were responding about this and that , a gentleman from Boeing shouted from the back “I am a customer of all of your companies, and I am telling you I want you all to work out a standard that I can implement.” Hah, how do you like them apples?
Ok, I have to disgree with you on this one. I think this is the first time.
NAC is exactly 802.1x.
Actually, 802.1x is to NAC as DLP is to Info-centric security. Its the technology that (partially) makes the system work.
NAC is, after all, Network Access Control. ‘Access’ being the operative word. Maybe Network Authentication Control would be better. 🙂
The rest of everything (“Is AV current?”) is tacked on and really doesn’t have a fancy name. I’m sure that Alan could arrange something. This extra, tacked-on bit, may be very much more exciting and useful than NAC itself but NAC is, by definition, getting users to authenticate to a network before using it.
Maybe the other stuff needs to be given a fancy name like Endpoint-Profile-Checking (EndPC/EPC) and it will be more widely accepted.
This gives me an idea for a blog post…..
Allen (not Alan 🙂