IDMEFv2 : Incident Detection Message Exchange Format V2

Incident Detection Message Exchange Format V2 (IDMEFv2)

IDMEFV2 (Incident Detection Message Exchange Format) est une initiative de standardisation d'un format d’alerte pour la détection d'incident. C'est une évolution du standard IETF IDMEFv1 (Intrusion Detection Message Exchange Format RFC 4765) 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. “Intrusion Detection” est donc remplacé par “Incident Detection” qui couvre un périmètre beaucoup plus large.

La genèse du format

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. 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.

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. 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

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.

La communauté travaille actuellement à la standardisation du format auprès de l’IETF.

La justification de la convergence cyber et physique

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,
• la difficulté voire l’impossibilité de détecter des incidents complexes, en cascade ou des attaques combinées,
• l’impossibilité de corrélation croisée ou de traitement 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

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, ...
• 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

La version V03 du Draft IDMEFV2 propose six classes:

• La source de l'incident : une adresse IP, un individu, ...
• Le vecteur : le vecteur d'attaque, le mode opératoire, un virus, un drone, ...
• La cible : un serveur cyber ou physique, un bâtiment, une zone, une personne, ...
• Le détecteur : une sonde, une caméra, un capteur de mouvement / de température, ...
• L'analyseur : l'outil qui analyse les données captées par le détecteur (analyseur et détecteur peuvent être une même instance),
• L'alerte en elle-même générée par l'analyseur.

Les spécificités du format  

La définition du format IDMEFv2 repose sur quatre principes majeurs:

• Universalité : 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 et du “Center for Research on the Epidemiology of Disasters” (CRED) pour les dangers,.
• Des concepts simples: 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), l’utilisation de technologies populaires avec JSON sur HTTPs,
• 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

Incident cyber

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

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é

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

Le GitHub IDMEFv2 héberge :

• Des librairies Java et Python pour manipuler les alertes IDMEFv2 (format et transport),
• Un prototype de CP-SIEM (Cyber & Physical Security Information & Event Management),
• Un outil de validation des alertes au format JSON.

Les cas d'usages de IDMEFv2

Parmi les principaux cas d'usages, on peut citer :

• Détection cyber et/ou physique : IDMEFv2 peut être utilisé dans un environnement purement cyber et/ou physique,
• Les infrastructures critiques qui peuvent faire l’objet d’attaques ou d'incidents hybrides,
• Les systèmes intelligents qui combinent cyber et physique (villes, maisons, ...),
• La voiture connectée qui embarque aujourd'hui autant de physique que de cyber.  

IDMEFv2 et l'écosystème existant  

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 disponibilité, IODEF pour la description d'un incident (après la détection) ou encore STIX pour la Cyber Threat Intelligence.

Liens externes

• 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 (IDMEFv1 - 2007)
• ENISA RIST (Reference-Security-Incident-Taxonomy) Task Force
• Cas d'usage de IDMEFv2 sur le projet H2020 7SHield