IDMEFv2 : Incident Detection Message Exchange Format V2
IDMEFV2 (Incident Detection Message Exchange Format) est une initiative de standardisation d'un format d’alerte auprès de l'IETF pour la détection d'incident. Deux premiers drafts du format et du transport sont en cours d'évolution à l'IETF depuis mai 2023[1],[2]. C'est une évolution du standard IETF IDMEFv1 (Intrusion Detection Message Exchange Format RFC 4765[3]) défini en 2007 dont il reprend le principe (définition d'un format standard d'alerte) en l'élargissant à tous les types d'alertes, qu'elles soient cybers ou physiques tout en actualisant le format et sa technologie[4]. “Intrusion Detection” est donc remplacé par “Incident Detection” qui couvre un périmètre beaucoup plus large.
La genèse du format
[modifier | modifier le code]La première version du format IDMEFv2 a été créée en 2021 dans le cadre d'un partenariat entre un projet de recherche français (FUI 25 SECEF : Security Exchange Format) financé par la BPI et l’IDF visant à améliorer le format IDMEFv1 et un projet H2020 européen 7SHIELD travaillant sur la protection des infrastructures cyber et physique contre les attaques complexes et hybrides[5]. Le format IDMEFv1 (Intrusion Detection) initialement restreint à la détection d'intrusion cyber s'est ouvert à tous les incidents (Incident Detection), à cette occasion.
Dans le cadre du projet 7Shield le format a été utilisé sur 5 segments sols pilotes en Europe (Belgique, Finlande, Grèce, Italie et Espagne) reliant ainsi plus d’une trentaine de composants techniques développés par les différents partenaires.
Le premier draft du format a été publié à l’IETF en avril 2023 par Télécom SudParis[6].
Depuis le 1er janvier 2024, Télécom SudParis pilote un nouveau projet de recherche Digital Europe (SAFE4SOC : Security Alert Exchange Format for SOC) visant à étendre l'utilisation du format à l'échange d'information de détection entre SOC (Security Operation Center) au sein de la Communauté Européenne[7]. Le projet a pour objectif d'adapter le format IDMEFv2 à ce type d'échanges ainsi que de finaliser ses spécifications et obtenir la standardisation IETF.
La communauté IDMEFv2
[modifier | modifier le code]La définition et l'amélioration du format sont aujourd'hui ouvertes à toute la communauté technique et scientifique au travers d'un site Web et une liste de diffusion dans laquelle sont discutés les évolutions et les choix du format[8].
La communauté travaille actuellement à la standardisation du format auprès de l’IETF.
La justification de la convergence cyber et physique
[modifier | modifier le code]Historiquement, la détection d'incident se compartimente en trois principaux segments d'outillage. La gestion de la performance et de la disponibilité autour des NMS (Network Management Systems) et autres outils d'observabilité, qui concentrent, analysent et notifient les incidents de performance et disponibilité. La gestion de la sécurité informatique autour des SIEMs (Security Information & Event Management) qui concentrent, analysent et notifient les incidents de cybersécurité. La gestion de la sécurité physique autour des PSIM (Physical Security Information Management) qui concentrent, analysent et notifient les incidents de sécurité physique. Chaque domaine propose ses outils et ses formats.
Cette compartimentation, justifiée historiquement, présente aujourd’hui de nombreux inconvénients parmi lesquels la multiplication des outils, des compétences et des équipes. Il est également difficile voire impossible de détecter des incidents complexes, en cascade ou des attaques combinées. Et il est impossible d'effectuer des corrélations croisées ou des traitements IA multi-domaines.
Enfin, à l'heure de l'explosion de l'internet des objets, la séparation entre le monde cyber et le monde physique devient de plus en plus difficile à définir et il est urgent de pouvoir fusionner la supervision des deux mondes digital et physique.
IDMEFv2 propose donc un format d'alerte universelle permettant la convergence de ces multiples domaines dans un système de détection d’incident unifié.
L’objectif du format IDMEFv2
[modifier | modifier le code]IDMEFv2 offre la possibilité de décrire des incidents (ou des événements suspicieux) de type cyber (authentification échouée, tentative d'intrusion, détection d'un virus, scan illégitime d'un port...), physique (détection de mouvement, alarme incendie, intrusion physique, approche d'un drone...), disponibilité (non réponse d'un serveur ou d'une caméra, température ou taux de CPU dépassant un seuil...) et enfin les risques: enfin le format permet de décrire de potentiel risques humains ou naturels en particulier liés au climat (et à son dérèglement).
Les classes IDMEFv2
[modifier | modifier le code]La version V03 du Draft IDMEFV2 propose sept classes.
Classe | Description |
---|---|
Source | une adresse IP, un individu... |
Target | un serveur cyber ou physique, un bâtiment, une zone, une personne... |
Vector | le vecteur d'attaque, le mode opératoire, un virus, un drone... |
Sensor | une sonde, une caméra, un capteur de mouvement / de température... |
Analyzer | l'outil qui analyse les données captées par le détecteur (analyseur et détecteur peuvent être une même instance), |
Alert | L'alerte en elle-même générée par l'analyseur |
Attachment | Pour joindre un élément à une classe: un fichier, une image, un son... |
Les spécificités du format
[modifier | modifier le code]La définition du format IDMEFv2 repose sur quatre principes majeurs. L'universalité avec un même format pour tous les incidents avec 5 "dimensions" pour chaque alerte: la triple dimension spatiale, la dimension cyber (adresse IP) et la dimension temporelle. Une classification très large basée sur les travaux de l'ENISA RIST (Reference Security Incident Taxonomy) work group[9] et du “Center for Research on the Epidemiology of Disasters” (CRED)[10] pour les dangers. Des concepts simples avec un nombre limité de classes de haut niveau et d'attributs (avec des possibilités simples d'extensions), un format limité à la détection d'incident uniquement (avant l’étape d'analyse) et l’utilisation de technologies populaires avec JSON sur HTTPs. Et un format de détection de “bout en bout”: IDMEFv2 transporte des attributs techniques pour la chaine de détection (détection, corrélation, agrégation, AI...) ainsi que des attributs plus parlant pour l'affichage des alertes dans un "dashboard" de supervision à destination des opérateurs.
Exemples JSON d’alertes IDMEFv2
[modifier | modifier le code]Incident cyber
[modifier | modifier le code]Un SIEM a détecté une potentiel attaque bruteforce sur le compte root sur les serveurs 192.0.2.2 et 2001:db8::/32:
{
"Version": "2.D.V0X",
"ID": "819df7bc-35ef-40d8-bbee-1901117370b2",
"Description": "Potential bruteforce attack on root user account",
"Priority": "Medium",
"CreateTime": "2021-05-10T16:55:29.196408+00:00",
"StartTime": "2021-05-10T16:55:29+00:00",
"Category": [
"Attempt.Login"
],
"Analyzer": {
"Name": "SIEM",
"Hostname": "siem.acme.com",
"Type": "Cyber",
"Model": "Concerto SIEM 5.2",
"Category": [
"SIEM",
"LOG"
],
"Data": [
"Log"
],
"Method": [
"Monitor",
"Signature"
],
"IP": "192.0.2.1"
},
"Sensor": [
{
"IP": "192.0.2.5",
"Name": "syslog",
"Hostname": "www.acme.com",
"Model": "rsyslog 8.2110",
"Location": "Server room A1, rack 10"
}
],
"Target": [
{
"IP": "192.0.2.2",
"Hostname": "www.acme.com",
"Location": "Server room A1, rack 10",
"User": "root"
},
{
"IP": "2001:db8::/32",
"Hostname": "www.acme.com",
"Location": "Server room A1, rack 10",
"User": "root"
}
]
}
Incident physique
[modifier | modifier le code]Un homme recherché par le FBI a été identifié dans le bâtiment à proximité des salles serveurs. La fiche du FBI ainsi qu'une photo prise par la caméra sont attachées à l'alerte.
{
"Version": "2.D.V0X",
"ID": "819df7bc-35ef-40d8-bbee-1901117370b1",
"Description": "Potential intruder detected",
"Priority": "Low",
"Status": "Incident",
"Cause": "Malicious",
"CreateTime": "2021-05-10T16:52:13.075994+00:00",
"StartTime": "2021-05-10T16:52:13+00:00",
"Category": [
"Intrusion.Burglary"
],
"Analyzer": {
"Name": "BigBrother",
"Hostname": "bb.acme.com",
"Type": "Physical",
"Model": "Big Brother v42",
"Category": [
"HAR",
"FRC"
],
"Data": [
"Images"
],
"Method": [
"Movement",
"Biometric",
"AI"
],
"IP": "192.0.2.1"
},
"Sensor": [
{
"IP": "192.0.2.2",
"Name": "Camera #23",
"Model": "SuperDuper Camera v1",
"Location": "Hallway to server room A1"
}
],
"Source": [
{
"Note": "Black Organization, aka. APT 4869"
}
],
"Vector": [
{
"Category": ["Man"],
"TI": ["Name:FBI-Wanted"],
"Name": "John Doe",
"Note": "Codename Vodka, known henchman for APT 4869",
"Location": "Hallway to server room A1",
"Attachment": ["pic01", "wanted"]
}
],
"Attachment": [
{
"Name": "wanted",
"FileName": "fbi-wanted-poster.jpg",
"Size": 1234567,
"Ref": ["https://www.fbi.gov/wanted/topten"],
"ContentType": "image/jpg",
"ContentEncoding": "base64",
"Content": "..."
},
{
"Name": "pic01",
"Note": "Hi-res picture showing John Doe near server room A1",
"ExternalURI": ["ftps://192.0.2.1/cam23/20210510165211.jpg"],
"ContentType": "image/jpg"
}
]
}
Incident de disponibilité
[modifier | modifier le code]Le serveur www.acme.com ne réponds pas aux requêtes de ping
{
"Version": "2.D.V0X",
"ID": "819df7bc-35ef-40d8-bbee-1901117370b3",
"Description": "A server did not reply to an ICMP ping request",
"Priority": "Medium",
"Status": "Incident",
"Cause": "Unknown",
"CreateTime": "2021-05-10T16:59:11.875209+00:00",
"StartTime": "2021-05-10T16:59:11.875209+00:00",
"Category": [
"Availability.Outage"
],
"Analyzer": {
"Name": "NMS",
"Hostname": "nms.example.com",
"Type": "Availability",
"Model": "Concerto NMS 5.2",
"Category": [
"NMS"
],
"Data": [
"Network"
],
"Method": [
"Monitor"
],
"IP": "192.0.2.1"
},
"Target": [
{
"IP": "192.168.1.2",
"Hostname": "www.acme.com",
"Service": "website",
"Location": "Server room A1, rack 10"
}
]
}
Implémentations
[modifier | modifier le code]Le GitHub IDMEFv2[11] héberge des bibliothèques Java et Python pour manipuler les alertes IDMEFv2 (format et transport), un prototype de CP-SIEM (Cyber & Physical Security Information & Event Management) et un outil de validation des alertes au format JSON.
Les cas d'usages de IDMEFv2
[modifier | modifier le code]Parmi les principaux cas d'usages, on peut citer la détection cyber et/ou physique, IDMEFv2 peut en effet être utilisé dans un système uniquement cyber ou physique. IDMEFv2 est également bien adapté à la protection des infrastructures critiques qui peuvent faire l’objet d’attaques ou d'incidents hybrides. Il en est de même pour les systèmes intelligents qui combinent cyber et physique (villes, maisons...) dont un des meilleurs exemples est la voiture connectée qui embarque aujourd'hui autant de physique que de cyber.
IDMEFv2 et l'écosystème existant
[modifier | modifier le code]En se limitant à la détection d'incidents, IDMEFv2 se présente clairement comme complémentaire aux formats et standards existants que sont par exemple SNMP pour la seule disponibilité, l’initiative OCSF[12] pour la définition des événements de securité, IODEF pour la description d'un incident (après la détection) ou encore STIX pour la Cyber Threat Intelligence.
Liens externes
[modifier | modifier le code]- Le site web IDMEFv2
- Le draft IETF IDMEFv2 format
- Le draft IETF IDMEFv2 transport
- Le GitHub IDMEFv2
- Le LinkedIn IDMEFv2
- La liste de diffusion IDMEFv2
- Le site du projet Safe4Soc
- La RFC 4765[3] (IDMEFv1 - 2007)
- ENISA RIST (Reference-Security-Incident-Taxonomy) Task Force
- Cas d'usage de IDMEFv2 sur le projet H2020 7SHield
Références
[modifier | modifier le code]- Gilles Lehmann, « The Incident Detection Message Exchange Format version 2 (IDMEFv2) », IETF, Internet Engineering Task Force, no draft-lehmann-idmefv2-03, (lire en ligne, consulté le )
- Gilles Lehmann, « Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS », IETF, Internet Engineering Task Force, no draft-lehmann-idmefv2-https-transport-02, (lire en ligne, consulté le )
- (en) Request for comments no 4765
- Benjamin Feinstein, David Curry et Herve Debar, « The Intrusion Detection Message Exchange Format (IDMEF) », IETF, Internet Engineering Task Force, no RFC 4765, (lire en ligne, consulté le )
- « Safety and Security Standards of Space Systems, ground Segments and Satellite data assets, via prevention, detection, response and mitigation of physical and cyber threats | 7SHIELD Project | Fact Sheet | H2020 » (consulté le )
- Marc Jacob, « Télécom SudParis lance une Task Force* internationale pour la standardisation d'un format de détection d'incidents cybers et physiques », (consulté le )
- « EU Funding & Tenders Portal » (consulté le )
- (en-US) « Home », (consulté le )
- enisaeu/Reference-Security-Incident-Taxonomy-Task-Force, ENISA - EU Agency for Cybersecurity, (lire en ligne)
- (en) « CRED: Epidemiology of disasters » (consulté le )
- (en) « IDMEFv2 : Incident Detection Message Exchange Format » (consulté le )
- « Open Cybersecurity Schema Framework », sur schema.ocsf.io (consulté le )