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.
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.
This week, I’m blogging from RSA Europe in London. The conference is dedicated to Alan Turing, the great British cryptographer and early computer scientist. The folks at Bletchley Park teamed with a local hobbyist to bring an Enigma machine and other cryptographic machines to the conference. I had a great time playing with the Enigma.
Attendance at the show was down a bit from last year, probably due to the poor economy. Still, there was a good crowd for my talk on “NAC 2.0″ this morning. I explained how NAC systems are starting to integrate with other network security systems like IDS and DLP. This trend is really starting to accelerate now that IF-MAP has been released, providing a standard way for these integrations to happen.
One more note. The Bletchley Park folks are appealing for donations to help save their historic site, an important part of cryptography and information security. If you’d like to donate, visit their site at http://www.bletchleypark.org.uk or stop by and see the machines for yourself. If you can’t make it to England, go to the U.S. National Cryptologic Museum in Maryland. They have a similarly amazing collection of spy gear albeit in a less historic setting.
The IETF’s NEA Working Group is (among other things) standardizing a set of “PA-TNC attributes” for use during NAC health checks. These standard attributes will be implemented in many network endpoints (laptops, desktops, printers, etc.) so that a NAC server can query an endpoint and obtain information about its health in a standard way. The tricky part is deciding which attributes are important enough to be in the first standard and which attributes can be left to future standards or vendor extensions.
I bet you have some ideas on this topic. Review the current draft list of attributes (below) and post your comments. I’ll bring them back to the NEA WG. Thanks!
A standard set of components are defined and then a standard set of attributes that describe aspects of those components. This avoids the need to define separate attributes for “OS Version”, “AV Version”, etc. Of course, some devices won’t implement all these components and attributes. No Anti-Virus on my printer (yet!).
Components: Operating system, Anti-Virus, Anti-Spyware, Anti-Malware, Host Firewall, Host Intrusion Detection and/or Prevention System, Host VPN
Attributes: Product Information (vendor, name), Numeric Version, String Version, Operational Status (operational?, problems detected?, last time run), Port Filter List (for Host Firewall), Installed Packages (name, version)
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!
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”.
Last week, I spoke about the TNC standards at Interop Tokyo. Then I went back to the TCG booth and talked with Japanese government and enterprise customers, researchers, manufacturers, and reporters about TCG technology. There’s an amazing amount of support for TCG technologies in Japan! On the flight home, I reflected on how far we’ve come in the last few years and what lessons we can draw from this growing wave of support for TCG standards.
A few years ago, TCG technologies like TPM and TNC were only concepts being discussed by a few people. How could we have trustworthy devices and networks? Now these technologies are globally accepted and widely used. Millions of people have a TPM in their laptop and a TNC client in their operating system. Organizations such as the U.S. Department of Defense require a TPM in every PC. How did this come about? Open standards unleashed the awesome power of human innovation and communities.
Open standards are not enough. There are many thousands of standards, most of which are unsuccessful. Successful standards solve a specific set of problems but allow extensions to encourage innovation and meet special needs. That’s what the TPM and TNC standards have done. And that’s why these standards have flourished. Vendors and customers see value in implementing the basic standards and opportunity in the many ways they can extend these standards. Eventually, communities of interest grow up. The TCG just announced the Japan Regional Forum, a place for Japanese discussion and promotion of TCG standards. This demonstrates the power of open standards.
Think about TCP/IP or WiFi. Having a single set of common standards has enabled a huge amount of innovation with products like the iPhone or iKan. That’s what TPM and TNC do: create an open platform for innovation and adaptation. Once that platform is established, then it’s just a matter of getting everyone on board and letting the innovation begin. The value of a standard is proportional to the square of the number of implementers. That exponential power is really starting to take off for TPM and TNC and other TCG technologies!
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.
Steve Hanna is co-chair of both the Trusted Network Connect Work Group in the Trusted Computing Group and the Network Endpoint Assessment Working Group in the Internet Engineering Task Force.
Steve is active in other networking and security standards groups, such as the Open Group and OASIS. He's also the author of several IETF RFCs and published papers, an inventor or co-inventor on 30 issued U.S. patents, and a regular speaker at industry events such as Interop and the RSA Conference.
He holds an A.B. in Computer Science from Harvard University. For more information on Steve, check out Network World’s profile (by Tim Greene)
- JNetTawnee on: Decrypting RSA Europe
- on: Today’s NAC Panel at Interop NY
- on: New Audio Podcast on my Trip to India
- Biilo on: Summertime…
- Ken Y-N on: New Video Podcast Posted
- Tarek Amr on: IF-MAP: Integrating All Network Security
- Tarek Amr on: IETF Picks Up TNC Standards
- on: IETF NEA
- Steve Hanna (SteveHanna) on: Trusted Network Connect (TNC)
- on: Enforcement Options