Got the NAC
Latest Articles
The Adoption Curve for IF-MAP

The Adoption Curve for IF-MAP

Chris Hoff blogged yesterday about using TCG's standard IF-MAP protocol to connect security functions throughout the cloud. I couldn't agree more! That's exactly what IF-MAP is for: helping security systems share the information they have gathered. That's what I've been saying all along. Chris' idea to extend it to include virtualized security functions is a great one. I wonder if the virtualization folks are listening in.

 

Chris asks which vendors are supporting IF-MAP in their products. I have found that standards adoption follows the classic innovation adoption lifecycle. Innovators are the vendors and customers that have the vision and foresight to see where things must go. They are the first to create and adopt new technology. For IF-MAP, that group includes the folks who developed the IF-MAP spec and demonstrated implementations at Interop Vegas in April: ArcSight, Aruba Networks, Infoblox, Juniper Networks, Lumeta, and nSolutions. Next come Early Adopters, Early Majority, Late Majority, and Laggards. It takes at least a year for each stage: six months to turn prototypes into products and six months for the next generation of adopters to catch on. That's the timescale we've seen for the other TNC standards. So I expect to see Innovator vendors shipping products that implement IF-MAP in the next few months and Innovator customers deploying those products in the months after that.  Then will come Early Adopters and so on.

 

Innovation Adoption Lifecycle

 

IF-MAP provides immediate benefits. False positives and false negatives are greatly reduced since sensors are now identity-aware. Fewer false positives and negatives reduces the cost and increases the benefit of monitoring IDS and SEIM systems. Automated response is another way to reduce costs. Reduced cost with stronger security will definitely draw some attention in today's economic climate! I expect that it will quickly pull this technology across the "chasm" from Early Adopters to Early Majority, who are looking for successful ideas but open to new things. However, we still have a few years before we get to that point.

I have spoken about IF-MAP and coordinated security at several conferences and I have seen tremendous interest among customers and vendors. I'm not at liberty to give out names but some very large vendors and customers are excited about IF-MAP. As soon as IF-MAP products start shipping, I'll announce it on my blog and link to them.

 

As Alan Shimel points out on his blog, the best way to increase the number of products that support IF-MAP is for customers to demand and buy those products. Vendors who are Innovators have the foresight and resources to lead the market. Early Adopter vendors are eager to lead but need to see customer demand before they can add features. Will you provide the customer demand needed to pull the next group of vendors along the adoption curve? If you're interested, start asking vendors about IF-MAP support and examine the first generation of IF-MAP products when they ship.

Message Edited by SteveHanna on 11-21-2008 02:57 PM
Message Edited by SteveHanna on 11-21-2008 03:00 PM
Message Edited by SteveHanna on 11-21-2008 03:01 PM
Message Edited by SteveHanna on 11-21-2008 03:02 PM

Juniper Employee
Today’s NAC Panel at Interop NY

Today’s NAC Panel at Interop NY

Today’s panel on NAC was a blast! Mike Fratto mainly took questions from the audience. When there were slow spots, he asked some tough questions of his own. I prefer this approach to panels. Customers have the most interesting, real-world questions!

 

I was surprised how many of today’s questions focused on standards. The attendees were impatient with the delays in getting NAC standards implemented. I share their impatience. The TNC standards have been around for more than four years. They’ve been implemented by Juniper, Microsoft, and dozens of other vendors. Why don’t other vendors just implement them?

 

Steve Karkula of Nokia was a welcome addition to the usual cast of characters on a NAC panel: Cisco, Microsoft, and TCG. Steve is involved with Nokia’s SourceFire product. He pointed out the value of including behavior monitoring in a NAC system. I couldn’t agree more! These days, NAC is much more than checking the health of devices when they connect to your network. State-of-the-art NAC systems customize access for each user or role and monitor behavior so they can block misbehaving endpoints. Really cool systems link identity and behavior monitoring so that they know what behavior’s appropriate for each user!

 

An interesting followup question was how to monitor behavior when more network traffic is encrypted. The panelists had a variety of answers: doing monitoring on the servers, on the endpoints (only if you trust them!), or at the edge of the data center (if you terminate the encryption there, as is often done with load balancers, SSL offload devices, and such).

 

All in all, it was an interesting panel. I’m sorry if you couldn’t be there. I hope to see you at one of my upcoming talks!

Juniper Employee
Strong demand for NAC standards at Interop NY

Strong demand for NAC standards at Interop NY

I’m in NYC for Interop NY today. I’ll be speaking on a panel about NAC at 10:15 AM with Microsoft, Cisco, and Nokia reps and Mike Fratto as moderator. It should be entertaining and enlightening. At least, I hope it will be! I’ll blog about it this afternoon. If you’re at the show, please come by and say “Hi” or ask a question.

I wanted to point out Mike Fratto’s blog posting about the NAC Day panel. It sounds like a great discussion with customers pushing hard for vendors to support NAC standards. The TNC standards have been out for more than three years now and free for anyone to implement. Most vendors have done so or at least announced plans to do so. Cisco is the only holdout. I’m glad to see customers pushing hard for them to support these standards. I hope these words translate into actions. As they say, “money talks”! The only way to get some vendors’ attention is to put a requirement in your NAC RFP saying “must support the TNC standards”.

Juniper Employee
IF-MAP: Integrating All Network Security

IF-MAP: Integrating All Network Security

The TCG announced a new specification today: IF-MAP. Why should you care? Because this new standard really changes the world of network security.

 

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.

Juniper Employee
NAC Happenings at RSA

NAC Happenings at RSA

Last week, I was at the RSA Conference in San Francisco, a global gathering for information security folks. This event has already been covered by hundreds of bloggers and journalists so I won’t cover the basics. However, I do think it’s useful to highlight a few NAC-related events.

 

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.

Juniper Employee
What about IF-PEP?

What about IF-PEP?


In a comment on my last post, Grant Hartline wrote:

 

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!

 

 

Juniper Employee
IETF Picks Up TNC Standards

IETF Picks Up TNC Standards

I’m happy to say that the IETF NEA Working Group has decided to adopt several of the latest TNC standards as Working Group drafts! Let me answer some frequently asked questions about the process and the drafts. If you have more questions, please post them and I will try to answer them.

 

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.

Juniper Employee
Latest Comments
gotthenac | 11-24-2008
Re: Enforcement Options
By  
gotthenac | 11-17-2008
Re: Decrypting RSA Europe
gotthenac | 11-14-2008
Re: Decrypting RSA Europe
By  BillT