1998 – 2007 : IDMEFv1
During nearly ten years, the Intrusion Detection Working Group worked on the definition of the IDMEF format.
The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing
information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.
Among others, companies like Boeing, Mitre, Nokia, Cisco and MIT participate to the elaboration of the RFC 4765
In 2007, the standardization has not been completely achieved but three experimental RFCs were published :
- RFC 4765 : The Intrusion Detection Message Exchange Format (IDMEF)
- RFC 4766 : Intrusion Detection Message Exchange Requirements
- RFC 4767 : The Intrusion Detection Exchange Protocol (IDXP)
IDMEFv1 has been adopted in open-source probes ( suricata, ossec, samhain, snort, etc.) and in Prelude OSS.
2015 – 2017 SECEF1 : IDMEFv1 promotion
In 2015 the SECEF (SECurity Exchange Format) consortium was created to improve and promote IDMEFv1. The SECEF consortium was composed of people who wrote the RFC 4765 as well as people who implemented IDMEFv1 in Prelude OSS and Prelude SIEM (the former development team)
After two years of analysis and test, the conclusion was that the format needed more than just few modifications. The base was solid but needed to be totally re-thinked.
Although it has proven it’s efficacy, IDMEFv1 has defaults among which:
- Too much exhaustivity and recursivity : IDMEFv1 offers a lot of possibilities for describing alerts in details and a lot of classes. But this exhaustivity can be seen as a weakness. Learning curve is very long as well as tool and library coding.
- Many attributes lack enumeration : enumeration is essential for a smart analysis of events
- IDMEFv1 messages are complex and hard to manipulate, tools (SIEMs and probes) need a specific IDMEFv1 library to do so.
- RFC 4765 focuses on probes and manager communication. The storage or the human notification has not been enough treated and present implementation difficulties.
- RFC 4767 (transport) is based on the BEEP protocol which has never really been deployed.
- IDMEFv1 is very « XML dependent »
2020 – 2023 SECEF2 : IDMEFV2 standardization
2020 SECEF2 : IDMEFV2 new version and standardization goal
In 2020 the SECEF2 (SECurity Exchange Format) consortium was created to create a new version of the format and standardize it.
SECEF2 consortium is an enlargement of the SECEF1 consortium with new industrial members.
The first step of the project was to experiment a new version of IDMEFv2 for protection of combined and complex threat on cyber and physical infrastructures.
This experimentation has been done on real scale in five different prototypes in the H2020 7SHIELD research project
The major results and decisions for IDMEFv2 were:
- favor simplicity over exhaustivity
- work on end-to-end messages, from the sensor to the operator
- enlarge the use of IDMEF to incident not only intrusion
- ability to treat any kind of incident may they be cyber or physical
- JSON will be the preferred format and HTTPs will be the preferred transport
- limited number of classes (less than 10), attributes and depth
- IDMEFv2 draft is also based on some ideas and concepts of the IDEA (Intrusion Detection Extensible Alert) format (which is also based on IDMEFv1)