Please find below some news on the progress of the standardization and our planned activities for S1 2025.
IETF
Standardization process
After presenting our project at IETF 121 meeting, we are now aiming for an « AD Sponsored » process. This means that the work will not be done « inside » the IETF but the result (final RFC) will hopefully be sponsored by the Security Area Director for standardization. Given the amount of work already done on the drafts and our deadline constraints, this is probably the best solution. Joining an IETF working group would have given us more visibility but could have called everything into question, especially since the incident detection format is not a common expertise at IETF where members are more specialized in Internet protocols. The step we are entering now is the format and transport definition tuning in real architectures and this cannot really be done in an IETF working group.
IETF Drafts
The last version is V04 published in October. The format draft is still being adjusted via the deployment of a use case architecture in the Safe4Soc project. One of the challenges of the Safe4Soc project is to centralize incidents coming from different SOCs using different proprietary SIEMs an IDMEFv2 SIEM. To do this, we need to translate those SIEM alerts/offence/events into IDMEFv2 alerts. This raises many issues we are currently facing: this attribute does not find its correspondence in IDMEFv2 , is this attribute really the equivalent of this one, etc. Keeping in mind that the mistake would be to add new attributes every-time there is one missing. IDMEFv1 has shown that there is a difficult balance to be found between completeness and simplicity.
Incident Category
Translating commercial SIEM alerts (Splunk, QRadar and RSA Envision) into IDMEFv2 has also highlighted the incompleteness of the current IDMEFv2 category enumeration based on ENISA RSIT. The list of incident categories is one of the most difficult attributes to define (more information here), so we used the existing ENISA classification which seemed very complete. But when testing in a real environment we see that it is incomplete. So we need to improve it or start from a blank page. Thanks to ChatGPT the page is not completely blank because we have some references, but merging everything and keeping it complete AND simple is still difficult … too difficult for ChatGPT at the moment!
IDMEFv2 Software
This year we will start publishing IDMEFv2 code. Most of it is still in development but we already have working and stable primary versions.
IDMEFv2 Validator
A new version of the IDMEFv2 Validator will be available soon with many improvements. This tool has many purposes. It is an IDMEFv2 validator so you can easily check the validity of a generated JSON message but the new version (including examples and exercises) is also an easy way to start manipulating IDMEFv2. Based on examples and using the IETF draft, you can easily « invent » incidents and try to translate them into IDMEFv2. For the creators of the IETF drafts, it is also an easy way to challenge the format.
Concerto SIEM (NEW)
Concerto SIEM is a fully IDMEFv2 compliant SIEM. Prelude OSS was an IDMEFv1 SIEM so focused on cyber incidents. Concerto is a fork of Prelude OSS and has a broader scope including physical and availability incidents. The GUI is very similar to Prelude OSS but the backend has totally being re-written using new technologies (Elasticsearch, Kafka, etc.) Concerto is the corner stone of our work on IDMEFv2.
Suricata Connector
The Suricata connector is the first in a series of IDMEFv2 connectors that we will develop. The purpose of this connector is to translate Suricata alerts into IDMEFv2 and send them to Concerto.
Android IDMEFv2 Alerter
Finally, the Android IDMEFv2 Alert application is a « proof of concept » to test the concept of « heartbeat » in IDMEFv2. The idea, instead of sending incidents, is to send periodic « heartbeats » to inform the SIEM that the asset is fine or that it is experiencing problems. This concept combines the notion of incidents and « health » from network monitoring (e.g. SNMP). Implementing this concept on a smartphone gives us the possibility to add geolocation to the heartbeat indicating the location of the smartphone and possibly its movement. The Android application also demonstrates that the choice of simple and popular technologies like JSON and HTTPs facilitates the integration of the IDMEFv2 code anywhere and in particular in connected objects.
Help needed
2025 must be the year of dissemination so we are always looking for support to help us spread the word about IDMEFv2. Please feel free to talk about it in your security communities by sharing four website address as an entry point and inviting people to subscribe to the IDMEFv2 mailing list.
A standard that is not adopted can’t be a good standard.
See you soon for new IDMEFv2 adventures!
The IDMEFv2 Task Force