Tech Road Map: IF-MAP Protocol

Trusted network connect--part of the Trusted Computing Group--published its Interface for Metadata Access Point protocol on April 28 to provide a common framework for sharing event metadata. This means there's finally a way for security and network devices from a variety of vendors to communicate, and thus make better assessments on whether to grant or deny access to everything from PCs to switches.

There's precious little integration among networking products today, and that's particularly problematic with a technology like network access control, where changes to a host's condition may be detected by security products on the host, network devices, event managers, DNS/DHCP servers, applications, or a number of random point products. Aggregating and acting on this data to prevent attacks requires vendors to join partner programs and do pricey custom integration.

These difficulties don't affect only disparate vendors. Companies offering many products--such as Cisco and Symantec--built their portfolios primarily through acquisition and are still working on integration.

How long before adoption of the specification reaches critical mass? That depends: We expect vendors to wait and see whether customers or partners demand support for IF-MAP, as the spec is known. So if you want to integrate your security products, network infrastructure gear, and network services in a meaningful way, tell your vendors to implement the spec.

THE STATE OF THINGS
While originally designed as a way for NAC systems to integrate with security products, IF-MAP is flexible enough to be used as an information resource by any networked device. At Interop 2008, several vendors, including ArcSight, Aruba Networks, and Juniper Networks, used IF-MAP to provide proof of interoperability and integration. We can also envision the spec helping with configuration management databases and related network data repositories, if only as a data source. However, IF-MAP was designed to keep NAC systems aware of state changes, and NAC is where IF-MAP will likely first have a significant impact.

Access decisions within NAC revolve around matching a device state to an access policy. When a host first connects to a network, its state is defined by characteristics like authentication, identity of the user or computer, device health, and location. But while the device is on the network, its state could change--for example, a computer could be infected with a worm, or its antivirus signatures may lapse.

At the center of an IF-MAP-enabled system is the IF-MAP server, which stores state information. As a device changes over time, records are updated. Note that this is not a historical database--state data is only as current as the last update. Other network devices, like a NAC policy decision point, then query the IF-MAP server to determine if a host, say, successfully authenticated and completed a DHCP exchange, before allowing it to communicate on the network.

IF-MAP uses a data model based on associating identifiers logically. For example, an IP address, a MAC address, and a user name are identifiers that, when linked, bind together to classify a host. Metadata is then used to describe these links. The relationship between a user name and an access request might have multiple metadata attached, including the user's role and the user name provided to authenticate.

This data is searchable by IF-MAP clients. Identifiers may be linked, facilitating searches so an IF-MAP client can discover how a particular device authenticated to the network, which user name was entered, and what IP addresses are bound to a given MAC address. This is a huge benefit--today there's no standardized way to, say, ask a Radius server which clients have authenticated, or query a DHCP server as to which leases have been given out.

In addition to running searches, IF-MAP clients can subscribe to data. When the IF-MAP server receives an update or addition to the server, it looks for outstanding subscriptions and sends responses.

The IF-MAP server is a repository; it doesn't correlate, validate, or weed out invalid data. The specification states that IF-MAP should augment other data sources and that it alone isn't a trusted source. The subtle point here is that the information contained in the IF-MAP server is only as valid as the data it's fed--if a device that publishes information to the server is compromised, then the IF-MAP server will retrieve incorrect data. The same could be said of any repository, of course. The goal is to ensure that reporting network and security devices, like switches or intrusion-detection systems, are sufficiently hardened against compromise.

Communication among IF-MAP clients and servers is secured using Transport Layer Security to mutually authenticate clients and servers using either static credentials or digital certificates. IF-MAP messages aren't intended to pass through multiple devices before reaching the IF-MAP server, and IT departments must be aware that an IF-MAP client that publishes state information could add, delete, or modify state data contained within the IF-MAP server, or an IF-MAP client that searches for device data could corrupt the IF-MAP server or read stored information.

At minimum, IF-MAP clients should be able to modify only their own data, and clients that retrieve data should be limited to read-only access and to only the information they need. When IF-MAP servers do come on the market, investigate included server access controls.