Joel Snyder’s Blog

TechTarget asked me to record a podcast for them (why is this called a podcast and not just an audio webcast? Or an audiocast? Like I expect you guys to download this to your iPod so you can listen to it on shuffle between “Baby, hit me one more time” and “FURB?”)

Anyway, here’s the abstract:

After the endpoint security assessment is over and it’s time to go talk to vendors, how can you tell between a song and a dance, and what you can truly expect out of a product?
Listen to Opus One’s Joel Snyder outline the essential questions to ask prospective vendors when assembling an endpoint security product RFP. Specific points of emphasis include basic product functions, guest users and network management infrastructure integration.

And here’s the link. You will probably have to tell them the name of your first-born child to listen to it. Sorry.

Network access control brings together four components: authentication, enforcement, endpoint security and management. While every network manager may select a different mix of these four, the “killer app” part of NAC is definitely endpoint security assessment. We’ve had enforcement and authentication for a while, and people haven’t been very excited about them. But add in endpoint security, and suddenly the pain of implementing NAC is nowhere as bad as the pain of having some Trojan horse botnet use your network to promote fake Rolexes and generic sex pills.

Endpoint security and NAC require taking a lifecycle view of network and client security. It’s not enough to say, “We check your PC and if it’s OK, you get on the network.” Instead, any endpoint security strategy has to be focused on keeping people on the network, not keeping them off. That means building a lifecycle approach, starting with assessment and monitoring, then remediation (if necessary), followed by enforcement integration, all wrapped up within a global policy definition and management structure.

Endpoint security usually begins with posture assessment, and this is the easiest to understand and build into your lifecycle. There are many product choices here, such as installed clients, downloadable bits of software, assessment strategies based on external scanners and vulnerability analyzers. No matter the choice, the goal is to figure out whether someone who wants to connect to the network should be allowed to do so.

Some NAC vendors mistake policy compliance (e.g., does this system have a virus scanner installed?) for safe computing (e.g., is this system infected with a virus?). Don’t let their naïve views of things confuse you. Instead, focus on the lifecycle and realize that even if a machine is found to be acting badly, there are additional tools to help. This is where monitoring, the second part of the endpoint security lifecycle, comes in.

One obvious kind of monitoring can be done on the client itself, assuming an application is running there that can watch the status of the system. Some vendors call that “continuous enforcement;” others use the unwieldy “post-admission NAC” term. No matter how it’s labeled, this part of the lifecycle acknowledges that just because someone smelled nice when they connected doesn’t mean that they’ll always be so sweet.

One problem with software running on or near the network client is that it can lie, or be lied to. A dispassionate third party helps here. Solid NAC strategies have definite feedback loops based on the ability to monitor what is actually happening on the network. You might start with existing IDS sensors and their alerts, or flow data from routers or firewalls. You’ll also find folks with vulnerability analyzers or endpoint discovery tools ready to hook into a good NAC framework to provide further information on the health of a system after it’s been connected.

Any time an endpoint security strategy can result in the prohibition of network access, remediation becomes a mandatory part of the lifecycle. This is one part of NAC where it pays to splurge. You might get away with simply dumping clients onto a VLAN where patches and antivirus updates can be downloaded and applied — at least until someone important is kept from doing their job. But for best success, carefully investigate one of the many commercial tools that can help catch the user’s attention, alert them to what is going on and walk them through whatever it takes to get them onto the network. This is one area of NAC, unfortunately, where an open source approach doesn’t offer the tools that are required.

Remediation strategies should not be based on auto-remediation, whenever possible. Auto-remediation means that the client should automatically update itself and change configurations to bring itself into compliance, as determined by the NAC policy. Auto-remediation is generally possibly only when systems are centrally managed by enterprise IT.

Enforcement integration is always part of an endpoint security strategy. It might be interesting to know that Stacie’s laptop has the wrong version of the antivirus scanner, but it’s a lot more useful to push that information back into the NAC infrastructure so that it can enforce policy. While early endpoint security tools focused more on reporting, the integration between network access control devices and endpoint security detection is a hallmark of modern products. Another key part of the lifecycle is feeding the status of endpoint security into the NAC enforcement mechanism. As the user’s system moves from suspect, to scanned, to remediation, to compliant, NAC enforcement needs to keep up.

Finally, all these pieces need to be wrapped up nicely into a single policy management system. NAC may be bringing together many different components from all over the network, but if there’s no consistent and overarching policy management system, the result will be chaos. This is harder than it seems, not just because of the technical challenges, but also due to organizational barriers. With a proper NAC and endpoint security strategy in place, people ranging from desktop system managers to infrastructure designers to firewall managers are all going to have to sit down and agree to share information and, in some cases, cede a certain amount of control to another group.

Once you’ve created an endpoint security lifecycle, and integrated it into your NAC architecture, you’re one step closer to a successful NAC deployment.

Network Access Control, NAC, is a simple idea. Authenticate every user connecting to the network, then enforce an access control policy based on who they are and other environmental information, such as end point security checks and wired versus wireless access method. After writing a big architectural overview of Network Access Control (NAC) for Network World (see http://www.networkworld.com/research/2006/040306-nac-overview.html ) and testing NAC solutions at Interop in Las Vegas last month (see http://www.networkworld.com/research/2006/050106-ilabs-nac.html ), I’ve been exposed to the good and bad parts of NAC.

I’m personally very enthusiastic about NAC. But I’d like to devote some time to the devil’s advocate view of NAC. Because it’s very true that the NAC idea has five major failings, and we might as well discuss them.

1. End Point Security checks only work when you need them the least. When you need them the most, they leave you high and dry. If your NAC strategy is based on checking end point security posture, that works great for managed laptops and desktops, but our testing has shown not so well for people coming into the organization—the folks you have the greatest security concerns about. If you’re doing NAC to check that strangers have virus scanners loaded, you’re doing it for the wrong reason.

2. Generals are always preparing to fight the last war—not the next one. NAC is the same way. A lot of the rhetoric proposing NAC is reactionary—worrying about last week’s threats. That’s useful, but have you noticed that we haven’t had a huge, network-wide virus meltdown in a couple of years? That’s because we’re actually getting better at preventing these kinds of things. Sure, it’ll happen again, but the frequency and severity is dropping. Which brings us to …

3. The ROI on NAC is a big unknown. NAC is a lot of work. A lot. Even if your network infrastructure is ready for whichever NAC approach you want, getting NAC into place is not going to be cheap or easy. Is it worth it? You should probably calculate that before going down that path. There are lots of other ways to spend your security dollar. Maybe some will have a better ROI.

4. Too much information is sometimes just too much. One of the benefits of NAC is that it gives you the opportunity to set a policy for every single user. The problem is that organizations who are paralyzed by the concept of policy definition or who don’t know what is going on with their networks are not suddenly going to be able to come up with per-user or per-group network access control rules. You can use NAC in its most primitive “on if you authenticate, off if you don’t” mode, but if that’s all you want—save yourself a lot of bother and try a simpler solution.

5. You can only control what you see. If your NAC solution lets people get to officially permitted servers—and then the servers become jumping-off points to cruise the network, your policy just got a planet-sized hole punched in it. NAC is fancy, complex, and expensive, but just a component in the bigger picture of defense in depth.

Don’t let these points keep you from looking at NAC. But when you do look at NAC, keep your eyes and your mind open.

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.