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
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.
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
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
The TCG announced a new specification today: IF-MAP. Why should you
care? Because this new standard really changes the world of network
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
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.
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
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
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.
I’m sure you’ve been perched on the edge of your seat, waiting to
see what would happen in the next episode of the riveting drama of NAC
standards. In our last episode, the IETF NEA Working Group had issued a
call for client-server NAC protocols to be considered for
standardization. Who would answer this call? We were all waiting to see…
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.