Joel Snyder’s Blog

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.

I just finished a project where I had to use a lot of different security products and I was struck at how different they are, and how much distance there is between good and merely average products.

Much of the time, people don’t decide to buy the best product; they buy the product that they like the best. Those are two very different things. What this means is that many companies have products that aren’t all that great—but they’re pretty happy with them, because they solve at least some problems, and they know how to use them, or they got a good deal, or their sales rep is really good looking or buys them lunch a lot.

I know I’m not going to change the mind of someone who knows the answer before they even ask the question of “what product should we use,” but I wanted to list four characteristics that, in my experience, really separate the great products from merely good ones.

Great products are self-documenting. It’s a rarity to find good documentation nowadays, which means that security products have to be designed to operate in a documentation-poor environment. Context-sensitive help, while a pain in the butt to build, is now a basic requirement for almost any product, and is always present in great products.

However, self-documenting doesn’t just mean context-sensitive documentation. It also means that the design of the product’s user interface makes it clear what the user is doing, and why, and what the effect will be, all without using product-specific jargon. A single extra sentence of explanation in the management interface can save an hour of searching through documentation to figure out what is really going on.

Great products have good logging and debugging output. (that’s two things, in case you’re keeping count.) I’ve never seen a product that didn’t require some troubleshooting, and the key to good troubleshooting is getting the information you need out of the debugging logs. When the logs are in a single place, and when the controls for searching and managing the logs are well put together, it’s easy to uncover what’s going on. When the logs are in 10 different places, in different formats, or (as I’ve seen recently) can’t even be viewed and have to be sent off to some external SYSLOG server, then debugging can be a nightmare.

There’s an art to writing good logging, and you’ll know a great product when you have to dig through the logs. Recently, in solving a problem I spent over an hour reading thousands of lines of logs that a not-very-great VPN product generated in a transaction that took less than a half-second to complete. It wasn’t logging; it was random debugging output that a half-literate developer had inserted to help fix his buggy code. On the other end of the VPN, though, was a great product that put out just 8 lines of logging, including a very clear pointer to where the problem was.

Great products are instrumented so that you can find out what you need to know. I’m continually astonished at how simple things you might want to know about a product are hard to find out. Questions like what’s the CPU load? How much bandwidth is being consumed? What are my outstanding critical alerts?

Security products especially have gone for the “dashboard” idea, trying to cram all kinds of status information into attractive pie charts that will look good in a demo—while not really helping the administrator answer the simple question “what is happening NOW?”

This is one of the more difficult attributes to see in casual use, because you’re often not sure what you care about until you’ve used a product for a while. But one thing is for sure: if you don’t see any status information, there’s something wrong. Many products err on the side of too much information.

I probably won’t convince you to change your buying or coding habits, but if you keep on the lookout for self-documentation, easy-to-use centralized logging, and meaningful status information, you’ll know whether you’re on the road with a good-enough product, or a truly great product.