In the past, security systems were largely silos. Your IDS didn’t talk to your firewalls or your VPN or your identity management system or your endpoint security. If they did talk, it was only through special, proprietary integrations.

The TCG’s TNC standards for NAC have changed some of that, providing a standard way to integrate endpoint security, identity management (usually), and network enforcement (switches, VPN, etc.). But until now, TNC didn’t have a standard way to
include IDS, firewalls, and lots of other important parts of your security system.

The IF-MAP specification provides exactly that. It defines a standard SOAP-based protocol that network security devices can use to communicate with a shared database called a Metadata Access Point (MAP). Using this protocol and database, the network security devices share information about the users and devices connected to the network: who’s logged into what device, how healthy the device is, whether it’s violating policy on behavior and/or health, etc.

Why is this useful? For several reasons:

• If a user connects their laptop to the network, authenticates, and runs through a NAC health check, and is assigned some privileges based on this, all of that information can be passed on to other network security devices in the network through the MAP.

• Sensors in the network (like Intrusion Detection Systems and Data Leakage Prevention systems) can customize their policies based on the user’s identity, role, and health.

• If a user starts acting up after they pass the NAC health check (sending spam or attacking people), an IDS can post an event to the database and the NAC system can shut them down at the switch port and pop up a message on their screen telling them what’s wrong and how to fix it.

• Device profilers can scan unmanaged endpoints (those that can’t or won’t participate in the NAC process, like a printer) and post information about them in the database so that they can receive an appropriate level of access.

• Interior enforcement devices (like firewalls) now have a standard way to get information from other network security devices on endpoints so that they can grant an appropriate level of access.

To summarize, the new IF-MAP standard extends the TNC architecture, now providing a standard way to integrate a wide variety of network security devices such as IDS, DLP, and interior firewalls with NAC gear and with each other. This allows the TNC architecture to work with “unmanaged endpoints” and integrate behavior monitoring in addition to or instead of endpoint health checking. It also provides a standard way to integrate firewalls and other enforcement devices into a TNC system. There are other uses of IF-MAP but this is all I have room for today. Look for more posts later.

For more details about the IF-MAP specification, see the TCG web page on this topic. If you have questions, let me know.

First, I was glad to see that NAC vendors are converging on IF-TNCCS-SOH as a standard client-server protocol. This addresses several concerns that customers have had about NAC: complexity, compatibility, and cost. Now that everyone is agreeing on one client-server NAC protocol, customers won’t have to worry about whether their NAC system is compatible with their PCs, their non-PC devices, and their contractors’ and customers’ devices. Support for the TNC protocols will just be built into the client operating system. This will reduce complexity and therefore cost by eliminating the need to install a special NAC agent on the device. Of course, the nirvana of universal NAC support is not here yet. Macs, older PCs, and many other devices don’t yet come with NAC support built-in. But the trajectory is clear. In a few years, NAC support will be as ubiquitous as DHCP is now.

Second, I participated in a panel session with Cisco and Microsoft on NAC. This is the third year we have done this panel at RSA. The first year, there was blood everywhere. The second year was a bit more restrained. And this year, I’m happy to say that everyone agreed on the value of the TNC standards. Even Cisco is on board, now that IETF has pick up the TNC specs. I still don’t agree with Cisco about everything. We had a few tiffs on the panel. But we agree on the need for NAC standards and the fact that the TNC standards are those standards. That’s the essential bit.

Finally, NSA (the U.S. National Security Agency) was demonstrating the High Assurance Platform, a multi-level secure workstation built on the TNC and TPM standards. This is really important. For one thing, it shows how open standards are being used to build super-secure systems out of inexpensive, commercial parts. For another, it will provide a big benefit to U.S. warfighters. Today, they must carry three laptops: one for secret materials, a second for top secret, and a third for unclassified. With HAP, a single laptop with a secure hypervisor (based on VMware) runs separate VMs for the separate classifications. This will literally lighten soldiers’ load, allowing them to be more agile or carry more arms and armor. Commercial road warriors and infosec teams may not carry guns but we are at war with cyber criminals. If TNC and TPM are strong enough for the NSA, they must be strong enough for your organization.

I’m happy to see the movement towards unification of standards and appreciate all of the effort you’ve put into NAC standards adoption, both within the TCG and the IETF. However, one TNC standard that is conspicuous in its absence is IF-PEP. Is there an IETF working group that may pull in IF-PEP for the purposes of triggering enforcement actions? Alternatively, or at least in the meantime, do you see any movement within what we’ll call “the industry” on adoption of RFC 3576 within Ethernet switches?

Let me answer some of Grant’s questions here. First, bit of background. IF-PEP is the TNC’s standard way for a Policy Decision Point (PDP) to send instructions to a Policy Enforcement Point (PEP). Those instructions might be “put this user on a quarantine VLAN”, for example. The TNC standard for IF-PEP is currently IF-PEP for RADIUS 1.1.

To answer Grant’s first question, there is in fact an IETF WG that works on this protocol. It’s the RADEXT (RADIUS Extensions) Working Group. If you look at IF-PEP for RADIUS, you’ll see that it cites a bunch of IETF RFCs. In fact, most of the TCG spec is just “use IETF RFC 3580 in this way” and things like that. So the IETF is already on board with IF-PEP for RADIUS. That’s one reason why TNC is so compatible with existing networking gear. RADIUS has been around for more than ten years. All enterprise grade switches and wireless access points support it, also many VPN gateways and things like that. There was no reason for TNC to reinvent the wheel. Reusing the existing IETF protocols provided maximum compatibility.

Grant’s second question is whether there’s any movement on adoption of RFC 3576 in Ethernet switches. For those who aren’t totally up on their RFC numbers, RFC 3576 describes how a PDP can send real-time updates to previous enforcement instructions to a PEP. For example, “please move that user out of the quarantine VLAN onto the production VLAN”.

RFC 3576 is about five years old and it has not been widely implemented by switch vendors to date. This is a shame because it makes it hard for a PDP to move users around as conditions change (change in user privileges or endpoint health, change in policy, etc.). The usual ways to handle this are to use another way to send the updates (SNMP or CLI), have the PDP ask the endpoint to request reauthentication from the switch, or configure the switches with a short reauthentication timeout. None of these are ideal. The first is proprietary and unreliable. The second depends on the endpoint to behave nicely. And the third is inefficient. Implementing RFC 3576 (also known as CoA for Change of Authorization) is clearly the way to go.

I have heard that a lot of switch vendors are moving now to implement RFC 3576. I want to provide a more complete answer for Grant so I’m going to do some research on this. I’ll submit another blog posting in a week or so with more information. If anyone has info on this topic, please post it as a comment. Links to data sheets would be ideal.

Thanks!

Q. Does this mean that these TNC standards are now IETF RFCs?

A. No, there’s still a long path to follow before they can be published as RFCs (the IETF’s term for their officially published documents). But it does mean that the NEA WG is working to develop RFCs based on them.

Q. Where can I get a copy of these specs?

A. In the cryptic manner of standards groups, there are two versions of each spec: the IETF version and the TCG version. The IETF specs are PA-TNC and PB-TNC. The TCG specs are IF-M 1.0 and IF-TNCCS 2.0. The only difference is the formatting and terminology!

Q. What if the NEA WG wants to change these specs before they become RFCs?

A. That’s OK. Everyone expects that. All standards go through changes and revisions, like HTTP 1.0 and 1.1. The protocols and products are designed to support such changes with a smooth and gradual transition. It’s worth it to get everyone on board.

Q. I have another question!

A. Ask it below in a comment and I’ll answer it.

February 18 was the deadline for submitting proposals. That evening, I logged in from my vacation in the Florida Keys and found… one proposal from the Trusted Computing Group (TCG). The TCG proposed a slightly modified version of the IF-TNCCS and IF-M protocols that are part of the TNC architecture.

After seeing this, I breathed a sigh of relief. I had been worried that we might end up with competing NAC standards (like HD DVD and Blu-Ray), resulting in confusion and delay. We seem to have dodged that bullet. Since the only proposal was the TCG proposal and the TCG indicated that it is willing to work with the IETF to resolve any problems and arrive at a single common standard, all signs point to the development of a single unified standard supported by TCG and IETF. Maybe Cisco will even support the standard, since they were the only major vendor holding back from supporting the TNC standards.

A bit of disclosure is probably in order here. I am co-chair of both the TCG TNC Work Group and the IETF NEA Working Group and also a co-editor on one of the TCG proposals to the IETF. Wouldn’t you think that would put me in the know and keep me from worrying about the outcome? Nope. I spent February 18 worrying, like Bill Belichick of the Patriots on Super Bowl Sunday! Would someone else make a proposal? Who? Even now, nothing is completely certain. Standards are a complicated and delicate process of building consensus. It looks like we’re headed toward consensus on these specifications but it won’t be completely certainly until years later.

The NEA Working Group (pronounced “nee-ah” by those in the group) recently approved a NEA requirements document. Now the Working Group is soliciting proposed protocols that meet those requirements. The proposals are due by February 18, 2008. It will certainly be interesting to see who submits proposals and what happens with them. Will Cisco submit a proposal? TCG? Someone else? Tune into my blog on February 19 and I’ll give you the answers!

What does this mean concretely? When you buy products that support the TNC standards, you can use a NAC server from one vendor with an enforcement device from another vendor. A NAC client from one vendor can be health checked by a NAC server from another vendor. And you can add assessment and evaluation components from other vendors, plugging those into the NAC client and NAC server.

Sure, that’s cool. But what are the specific customer benefits? First, you avoid vendor lock-in. Proprietary NAC architectures are designed to lock you into one vendor’s products. That way lies madness: single-vendor contracts, high prices, etc. Second, with the TNC standards you can reuse the technology you already have: switches, wireless access points, client security software, etc. There’s no better way to improve ROI than to reuse something you already bought! Finally, you get better security. Open standards go through a rigorous review process that has given us the strongest security available today: AES, TLS, IPsec, etc.

How did TNC come to be? It was developed by the Trusted Computing Group, a consortium of about 175 vendors and customers. The TNC standards were published in 2005 and 2006. Since that time, dozens of products that support the TNC standards have shipped. Hundreds of customers have deployed them. TNC adoption is accelerating, especially since Microsoft announced that TNC support is included in Windows Vista and will be included in Windows XP Service Pack 3. The TNC standards have become the de facto standard for NAC interoperability.

Want to learn more? Check out the presentations, podcasts, and specifications on the TNC web site.

Because of NAC’s multi-vendor nature, everyone now agrees that we need NAC standards. Every endpoint should implement a standard NAC protocol so that its health can be checked as necessary, in accordance with local policies and regulations.

However, the world of NAC standards is complex and evolving. In my next few posts, I’ll give you a guided tour of the world of NAC standards.

How do I know so much about this? NAC standards is my job. I work on this full time. I’m co-chair of both the NAC standards committees: TCG TNC and IETF NEA. So I know what’s up in this area and I’m glad to explain it.

• Endpoint - With endpoint enforcement, the device that’s requesting network access does the enforcement. Isn’t that sort of like having the fox guard the henhouse? Yes and no. Certainly, if a machine is infected or malicious, it won’t prevent itself from doing bad things. But some customers are only concerned with keeping the healthy machines healthy. They consider infected machines a lost cause. Even if this is a bit too loosey-goosey for you, endpoint enforcement can play an important role in NAC. That is self-protection. If a machine is found to be vulnerable (maybe down-rev on its patches), it should put up its shields until it can be repaired. So endpoint enforcement can play an important role in any NAC system.
• Network Edge - Probably the most common place to do NAC enforcement is at the network edge. Some systems use 802.1X, others use SNMP or CLI to control switches. VPN gateway enforcement also falls into this category. Whatever the technology, the idea is to enforce access controls at the edge of the network. This is great for security. Infected machines and unauthorized users can be completely blocked from the network or restricted to a quarantine area. The main down side is that this requires lots of enforcement points which can be expensive (but may not be, if you can use your current switches and wireless Access Points).
• Peer - With peer enforcement, the endpoints on the network monitor each other. If they believe that one is acting up, they attack it with poisoned ARPs and other denial of service techniques. This approach has declined in popularity recently. I’m not surprised. To me, it sounds like you’re saving money by laying off the security guards and arming the employees!
• Network Core - Doing enforcement at the core of the network can reduce costs but it also reduces security. An infected device or malicious user can attack other systems on the edge of the network. Only when they try to cross the network core will they be stopped.
• Data Center / Server - If you can’t afford edge enforcement, data center enforcement may be your best choice. You can roll out NAC gradually by placing enforcement points in front of your most critical resources and then adding more enforcement points over time. If you’re into deperimeterization, you’ll love this approach.
• Blended - Many vendors and customers combine several enforcement options. This can give you the best of all: the strong security of edge enforcement, the necessary self-protection of endpoint enforcement, etc.
• No enforcement - A surprising number of customers are deploying NAC with no enforcement. They gain insight into who’s accessing what from what devices and how healthy those devices are. Actually, I recommend no enforcement as the first step in any NAC deployment. Learn what’s happening on your network. Then warn people who are out of compliance. Once your compliance rate is high, then you can turn on enforcement without risking a nightmare.

What do you think of these different enforcement approaches? What’s working for you (or not)? Add a comment and let me know.