IDMEF Frequently Asked Questions

IDMEF V2 FAQ

You will find on this pages answers to questions we’ve been regularly asked. If you have other question don’t hesitate to post it in the SECEF mailing list.

  • What does IDMEF stands for ?
  • What are the main differences between IDMEFv1 and IDMEFv2 ?

What does IDMEF stands for ?

IDMEF v1 stands for Intrusion Detection Message Exchange Format. We are thinking of enlarging this definition by changing Intrusion by Incident. So IDMEF v2 will stands for Incident Detection Message Exchange Format.

What are the main differences between IDMEFv1 and IDMEFv2 ?

Here is a list of the main differences :

  • V2 is designed for Incident detection (larger than Intrusion)
  • V2 deals with Cyber AND physical incident
  • V2 preferred format for V2 is JSON (XML stays possible)
  • V2 preferred transport protocol is HTTPs
  • V2 focuses on 5 main classes : Alert, Agent, Source, Target, Vector, Attach

IDMEF V1 FAQ

You will find on this pages answers to questions we’ve been regularly asked. If you have other question don’t hesitate to post it in the SECEF mailing list.

What does IDMEF stands for ?

Intrusion Detection Message Exchange Format

What is IDMEF ?

IDMEF is a set of attribut to describe a possible intrusion (or intrusion attempt) in an IT system. With the IDMEF format, one can describe IDMEF “Alert” and IDMEF “Hearbeat”.

What is an IDMEF Alert ?

An IDMEF alert is a an event on your IT that you consider as “noticable” or “interesting” and that you want to monitor in concordance with your “security monitoring stategy”.

For example, you might consider that an event indicating that someone trying to authenticate with a wrong password is an alert.

An alert is NOT a breach or an incident. An alert is an event that should be taken in consideration, analysed or correlated with other alerts to check if it is a possible breach or incident.

What kind of information is stored in an IDMEF alert ?

A failed authentication could be described by those attributs :

  • Information about the analyser who raised the alert : IP,
  • Information about the target : IP, process, user … of the device/application where the authentication occured
  • Information about the alert source : IP, process, user of the device/application from where the authentication occured
  • Information about the impact of the event

What is the difference between IDMEF and syslog ?

Syslog is a generic format (and protocol) to store information about any IT event. Syslog format is very basic (time, facility, severity and short unstructured message) limited in size.

IDMEF is a specific format (and protocole) to store information about IT alerts. IDMEF is very structured and very expressive

An IDMEF alert contains some informations find in a syslog message completed with many other contextual information.

Some devices/application are able to generate IDMEF alerts, some others generate generic syslog that can be transformed in IDMEF alerts.

Does using IDMEF means using only application/devices IDMEF compatible ?

No, IDMEF alerts can be generated from a lot of different format (syslog, json, etc.) so you can use IDMEF in an heterogenous environment mixing IDMEF and not (yet) IDMEF compatible devices/applications.

Why should I use IDMEF natively if I can transform syslog message in IDMEF ?

When security tools implement IDMEF natively it gives the possibility to store more acurate information in the IDMEF Alert object. When you transform a syslog message in IDMEF alert, usualy there are less informations available (less attributs)

Are there alternatives to IDMEF ?

Many SIEM solutions propose an alert format based on extension of syslog. This is the case for ArcSight with CEF (Common Event Format) or Qradar with LEEF (Log Event Extended Format). Those format are usualy an extension of the syslog format using key = value syntax (no structuration)

Why not use IDMEF alternatives ?

Many reasons :

  • Alertnatives are propriatory format used only in the corresponding tool
  • Those format based on syslog are not well suited for alerts
  • A study has shown a very large difference between IDMEF and those alternatives.

During the first stage of the SECEF project we have been comparing the major alternatives to IDMEF. Here is a summary table comparing IDMEF with CEF (ArcSight) and LEEF (QRadar)

Format IDMEF CEF LEEF
Number of fields 259 84 49
Pertinent fields not in IDMEF 0 15 11
Total cover 100 % 25% 8%

You can find the detailed comparison here: Format Comparison

Alternatives are less exhaustive and propose no structuring. It results in lower context, lower correlation possibilities, lower automatization possibilities and so on.

The IDMEF is to complicated !

The IDMEF format is very exhaustive compare to propriatory alternative format. Thus it is more powerfull but also more complex. This is one point that needs to be improved in IDMEFv2. EIther simplifying the format or improving the documentation and probably a little bit of all.

What is an RFC?

RFC stands for Request For Comments. RFCs define the major standards of Internet: SMTP, HTTP, NTP, DNS, LDAP, IMAP, etc.

RFCs validation is managed by the IETF (Internet Engineering Task Force).

Who defined IDMEF v1?

IDMEF v1 has been defined by the IDWG (Intrusion Detection Work Group) at IETF between 2000 and 2007. This working group was composed of contributors from various field. The RFC 4765 lists on page XX the major contributors: IBM, Cisco, Boeing, MIT, Nokia, MITRE, Prelude project, etc.

Who is using IDMEF?

On the manager side (SIEM), IDMEF is used in Prelude SIEM, both commercial and open-source edition; it wss also partially implemented in LogLogic/Tibco SIEM.

On the agent side, IDMEF is implemented in lots of open-source tools: Snort, Suricata, Ossec, Samhain, Kismit, Armadito, etc … and also some commercial tools : StamusNetwork, 6Cure, etc.

Is Prelude the only SIEM implementing IDMEF?

Yes. But ArcSight is the only SIEM implementing CEF, QRadar is the only SIEM implementing LEEF, etc. Today, each SIEM is implementing it is own format, IDMEF is the only open standard format.

Why is not IDMEF more implemented?

Today, SIEM tools use internal proprietary format to describe alerts. Most of those formats are inspired of Log Management tools and based on syslog with simple (but limited) key=value formats. The effort of standardization has not been done yet and it’s one of the purpose of the SECEF project.

Give me a (simple) example of IDMEF exhaustivy power ?

XXXXXXXXXX

 

Give me an (simple) example of IDMEF structure power?

All alerts have “Source IP”. In IDMEF the source IP is a table where you can define multiple addresses. This is very interesting in case of DoS attacks for example or “Many to one” scan. Most of the alternative formats have only a single attribute to describe source IP so it is not possible to have a list. Same problem for target IP.

Why is it important to use a standard?

SIEM market is comparable to messaging market in late 90s. Editors trying to impose their own format to the users and thus, impossibility to interoperate between SIEMs. This is becoming a real problem as it prevents interoperability between tools thus collaboration. Even more serious, the same SIEM tool implemented by different team will produce different security result also using the same taxonomy.

A standard is important for collaboration and interoperability but also for conformity.

What is the difference between IDMEF and IODEF?

IODEF (Incident Object Definition Exchange Format) is a format to define an Incident and share it between security teams. It’s a “human” format.

IDMEF is a format to exchange alerts between security tools and security manager (SIEM). It’s a “technical” format, even if at the end it is read by a human operator.

IDMEF and IODEF are complementary. An incident can be described by joining IDMEF object in the IODEF message.

What is the difference between IETF IDMEF and the OASIS CTI (STIX/TAXII/CYBOX)?

The OASIS CTI is used to share CTI information. IDMEF information can lead/help to create CTI IOC but it’s not systematic. Those format are also complementary.