IDMEF Format¶
References¶
Intrusion Detection Message Exchange Format is described in IETF RFC 4765 : http://tools.ietf.org/html/rfc4765
It is an open standard but RFC 4765 is experimental since the "[IDWG] working group concluded before this work was approved as a standards-track protocol" and "this RFC is not a candidate for any level of Internet Standard."
The requirements are described in RFC 4766 : http://www.ietf.org/rfc/rfc4766.txt
The recommended transport protocol (IDXP) is documented in RFC 4767 : https://tools.ietf.org/html/rfc4767
The format is well documented in the RFC 4765 which provides examples and a precise description of each field. However, the document is a bit lengthy and the user that wants to create a simple alert with few fields has to read a lot of information before being able to populate an IDMEF alert. Moreover, the textual nature of RFCs is not well suited to describe the UML classes of IDMEF.
The semantic of each field is well described however IDMEF is quite complex and the mapping strategy is sometimes not clear. For example, how to map information taken from the log of a given application? Should the application be considered as an Analyzer or a Target?
Transport and encoding¶
The RFC 4765 does not impose any transport and encoding to implement the IDMEF data model. However, an XML implementation is provided using a DTD. The working group also proposed a dedicated transport protocol (IDXP). To the best of our knowledge, this protocol has not been used by any existing implementation.
Format expressive power¶
The format is very expressive and can embed information about sensors, one or multiple attack sources and targets, the attack itself, time, services, files, processes and users. Each node (sensor, source and target) can be described by its name and addresses.
Format structure¶
IDMEF is a well-structured object-oriented format. It consists of 33 classes containing 108 fields. IDMEF often use aggregation : some fields of a given class are instances of other classes. Inheritance is only used to describe different types of alerts and different types of services. A lot of class attributes are implemented as lists representing aggregations that have a multiplicity greater than on. For example, an attack can have multiple sources of targets. Some of these fields are used in conjunction with a category field. This last field can be used to attach different types of attributes using two fields, for example different types of addresses, user IDs, or host names. This pattern is quite specific to IDMEF. Some dictionaries are associated to these category fields. They could be used to extend the format.
Format extensibility¶
Format extensibility is natively handled in IDMEF thanks to a dedicated class, AdditionnalData, which is an attribute of alert messages. Moreover, it is possible to extend the format in a non standard way by using inheritance or by extending existing dictionaries.
General remarks¶
You can find advice on how to use IDMEF here.
Existing implementations¶
IDMEF UML diagrams¶
Zooms with explanations¶
AlertWhole Diagram¶
