Network Computingwww.networkcomputing.com

Over the past year and a half, the Intrusion Detection Working Group (IDWG) has produced six IDS-related documents, ranging from architecture requirements to protocol specifications. The goal of the IDWG is to create a standards-based method whereby IDS products and components can interoperate.

The two end products of the IDWG are the IDMEF (Intrusion Detection Message Exchange Format) and the IDXP (Intrusion Detection Exchange Protocol), which specify the data format and exchange procedures, respectively. Essentially, they will let your IDS components talk to one another.

IDMEF messages are XML (Extensible Markup Language) documents that describe an intrusion attempt. They encapsulate the alert data that is captured by the sensor and passed to the console. XML is an extensible format and will let vendors specify additional types of data that go beyond what is specified by the IDMEF DTD (Document Type Definition).

IDMEF alert messages are passed from the sensor to the console using IDXP, which is itself built from a new protocol framework called BEEP (Blocks Extensible Exchange Protocol; RFC 3080 on the IETF Standards Track). BEEP allows new connection-orientated application protocols to be developed quickly. Another key feature is that BEEP allows for authentication and confidentiality through the use of "profiles." For example, IDXP bootstraps by first establishing a TLS (Transport Layer Security, the successor to SSL) connection. After that, all communications are encrypted.

The IDWG standards, if adopted, could provide three main advantages:

>> Best-of-breed IDS deployments. For example, being able to use the NIDS sensor best suited to your environment while retaining the enterprise management suite already implemented by your organization.

>> Correlation. As more devices, such as routers, IDS sensors and firewalls, report IDMEF alerts, correlating events among various sources will become easier.

>> Interoperability. Sensors, proxies and consoles from different vendors could be enabled to talk to each other.

Hashing out standards always takes longer than expected, and the work done by the IDWG is no exception; in fact, the specifics have gone through major changes over the past year. For example, the exchange protocol was previously known as IAP and was based on HTTP. The current direction appears to have finally solidified, and the document drafts are close to being submitted to the Internet Engineering Steering Group (IESG) for blessing as official RFC documents. Once this happens, we hope to see some of the major IDS vendors jump on board with implementations, especially those who are involved with the IDWG work.

Silicon Defense, a security research and consulting company, is heavily involved in the IDWG scene. It has implemented a free, open-source library for generating LIBIDMEF messages, as well as a plug-in to enable Snort to output IDMEF XML alerts. The www.silicondefense.com/idwg/ site itself also has loads of background information, including IDWG meeting minutes, PowerPoint presentations and plenty of links to other resources. Also, RFC drafts are available at www.ietf.org/html.charters/idwg-charter.html.