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.