In a single-sentence: NAC is user-focused network-based access control.
The implications of that statement are fairly significant. Let’s break it apart and we’ll have a definition of NAC.
Start with “user-focused.” This term differentiates NAC from many other forms of access control, such as you might find in a typical firewall. While a firewall provides access control, most firewalls are designed to be destination focused: it’s not who you are, but what you want to get to that is most important. And when “who you are” is used in a firewall, it’s generally just a question of your IP address. NAC is different, because NAC is focused on the end user.
At a minimum, “user-focused” implies that users are authenticated and authorized. In other words, the policy expressed in the access control part of NAC (the user’s authorization) is based on who the user is, as determined by some authentication mechanism. I’m not going to say what kind of authentication is required here, because all of that depends on the enterprise’s requirements. Obviously, true user authentication (using username/password or some more secure method, such as digital certificates or tokens) is desirable, but a full-fledged NAC solution might include other authentication methods, including captive portals, MAC-based authentication, port-based authentication, and third-party authentication (such as a passed-in SAML assertion). However, I am going to say that a solution that has no authentication is not NAC. A network manager may choose not to use authentication, or even weak authentication (such as MAC addresses), but you have to offer that option to be in the game.
A second part of the term “user-focused” commonly found in NAC is the ability to include the user’s platform, along with the user’s identity, in the access control policy. Every NAC vendor has their own terminology here, but the general idea is that some assessment is made of the security posture of the user’s access device. The term we see a lot is “end-point security assessment,” although “system health check” also pops up a lot. I’m not fixated on terms, just functionality. The most common approach is to run some software on the user’s device which reports the security status of the device, such as whether virus software is up to date and enabled. However, other approaches, including external scans, are also fairly common. The choice of whether or not to use end-point security assessment is up to the network manager, but you have to include some aspects of it as an option.
NAC vendors have come up with a dizzying set of terms to differentiate their approaches to end-point posture assessment, trying to fit them into time-of-assessment (before authentication, during authentication, after authentication) and into continuity-of-assessment (once, or continuously) spectrums. While these differentiate products, I don’t believe that any one approach is required. Again, this is a place where an enterprise’s own policy and goals for NAC deployment will help to determine which end-point posture assessment strategy (if any) is right for them.
End-point posture assessment is actually just one piece of a larger part of user-focused access control I call “environmental” information. This includes posture assessment, but also other information which the NAC solution gathers from the environment, such as the access method (wireless, wired, VPN, for example) or the time of day or day of week.
“Network-based” means that this is something in the network itself. This seems obvious, but I have seen some vendors with client-enforced access controls calling those “NAC” solutions and I want to head that off right away. The enforcement must be in the network, somewhere. It could be at the point of entry (switch or VPN device) or it could be deeper, but it has to be within the network, not the client or the end host.
Again, I don’t want to say that these are “bad” technologies; I’m just saying that those are not NAC solutions. If you put the access control on the end system (either end), that’s a HAC (host-based access control), not a NAC. No jokes about hack, either, OK?
Finally “access control” means that you are controlling access by the end system, as always subject to the policy of the network manager. I don’t want to say that any particular degree of granularity is required to call yourself a NAC solution. I see four common scenarios: go/no-go access, VLAN-based access controls, simple packet filters, and stateful firewall. That doesn’t mean that you can’t have something in-between (although I’d be a bit hard-pressed to understand what that might be).
Note, however, that this does require user-focused access control. You can’t have NAC that doesn’t somehow apply policy based on who the user is. For example, I can easily imagine an IPS vendor re-titling their product a “NAC” product because it detects misbehavior and stops further traffic into the network. I am unwilling to call that a NAC product; we need to have user-focused access control.
This is not to say that you can’t throw an IPS into a NAC solution, and I can imagine many different ways in which this might be a useful piece of the big picture. However, to be a NAC solution, you must be applying access control based on who the user is (and not simply what traffic they are sending) to fit into this niche. There’s plenty of room for products with this loose definition, but we have to cut it off somewhere.