Projets & Gouvernance

Comparatif des taxonomies de cybersécurité utilisées par les CSIRT, CERT et SOC

by  • 

Résumé exécutif

Les CSIRT (Computer Security Incident Response Team), CERT (Computer Emergency Response Team) et SOC (Security Operations Center) s’appuient sur des taxonomies de cyberincidents pour classifier, analyser et partager efficacement les informations relatives aux menaces et aux incidents de sécurité. Cet article propose un panorama comparatif des principales taxonomies employées par ces équipes, en examinant pour chacune leur origine, leur structure, leurs usages, des exemples d’application, ainsi que leurs avantages, limites et leur interopérabilité éventuelle.

Parmi les taxonomies abordées figurent notamment la taxonomie eCSIRT.net (un standard historique de classification des incidents), la taxonomie de l’ENISA (Agence de l’UE pour la cybersécurité), le schéma de classification FIRST CSIRT, les taxonomies du projet MISP, le cadre VERIS de Verizon, ainsi que le référentiel MITRE ATT&CK.

L’analyse met en évidence que chaque taxonomie répond à des besoins spécifiques, du classement global des types d’incidents jusqu’à la description fine des techniques d’attaque et qu’une harmonisation progressive est en cours pour faciliter l’échange d’information entre équipes.

En conclusion, bien qu’aucune taxonomie unique ne couvre entièrement tous les besoins, la connaissance et l’utilisation combinée de ces référentiels complémentaires permettent aux CSIRT, CERT et SOC d’améliorer leur efficacité, leur communication mutuelle et leur compréhension des cybermenaces.

Introduction

Dans le domaine de la cybersécurité, la taxonomie désigne un système de classification structuré qui permet de catégoriser les incidents de sécurité, les menaces ou les comportements malveillants selon une nomenclature commune. L’adoption de taxonomies claires est cruciale pour les équipes CSIRT, CERT et SOC : en classant de façon cohérente les incidents et indicateurs, ces équipes peuvent mieux prioriser les réponses, communiquer avec précision sur les incidents, dégager des statistiques utiles, et partager des informations avec d’autres entités de manière compréhensible par tous.

Au fil du temps, plusieurs taxonomies ont émergé, chacune développée par des organisations reconnues dans le domaine (agences gouvernementales, consortiums de réponse aux incidents, communautés open source, entreprises privées, etc.) et visant à standardiser un aspect particulier de la classification en cybersécurité.

Cet article présente les principales taxonomies utilisées par les CSIRT, CERT et SOC, en les replaçant dans leur contexte d’origine et en décrivant leur structure. Pour chaque taxonomie, j’examine son origine (qui l’a créée et pourquoi), sa structure (comment elle est organisée, par exemple en catégories et sous-catégories), ses usages et cas d’application au sein des équipes opérationnelles, ainsi que ses avantages et limites. J’ aborderai également l’interopérabilité éventuelle entre ces taxonomies, c’est-à-dire dans quelle mesure elles peuvent être alignées ou traduites les unes dans les autres afin de faciliter l’échange d’informations.

Les taxonomies étudiées incluent la taxonomie historique eCSIRT.net, la taxonomie de l’ENISA, le schéma de classification proposé par le FIRST pour les CSIRT, les taxonomies intégrées au projet MISP, le cadre VERIS de Verizon, ainsi que le framework MITRE ATT&CK. D’autres modèles et référentiels couramment utilisés, tels que la Cyber Kill Chain de Lockheed Martin ou le modèle Diamond, seront également évoqués brièvement.

L’objectif est d’offrir une vue d’ensemble comparative, neutre et objective, aidant le lecteur à comprendre comment ces taxonomies se complètent et contribuent ensemble à une meilleure gestion des incidents de sécurité.

Taxonomie eCSIRT.net (classification d’incidents)

L’eCSIRT.net est l’une des premières taxonomies de classification d’incidents largement adoptées par la communauté des CSIRT. Issue du projet européen eCSIRT.net en 2003, elle proposait un jeu minimal de catégories d’incidents couvrant les principaux types techniques d’incidents de sécurité. Cette taxonomie a été développée à partir de travaux initiaux de Jimmy Arvidsson et Don Stikvoort, avec pour objectif d’établir un langage commun pour décrire les incidents informatiques les plus courants.

Au niveau de la structure et des catégories :
 La taxonomie eCSIRT.net est structurée de façon hiérarchique avec des classes d’incidents de haut niveau, déclinées en types d’incidents plus précis. Par exemple, elle divise les incidents en catégories telles que contenu abusif, code malveillant, collecte d’information, tentatives d’intrusion et intrusions, chaque catégorie comportant des sous-catégories et des exemples pour affiner la description. Parmi les grandes classes généralement incluses dans eCSIRT.net figurent notamment : la diffusion de contenus abusifs (ex. messages offensants, pédopornographie), le code malveillant (virus, vers informatiques, chevaux de Troie), la collecte d’information (reconnaissance par scans et sondes), les tentatives d’intrusion (exploitation de vulnérabilités connues pour essayer de compromettre un système), les intrusions avérées (compromission réussie d’un système ou d’un compte), mais aussi d’autres catégories comme les attaques sur la disponibilité (ex. déni de service), la fraude ou les atteintes à la sécurité du contenu informationnel (ex. vol ou altération de données sensibles).

Cette taxonomie se voulait suffisamment générale pour couvrir l’ensemble des incidents techniques rencontrés, tout en restant modeste en taille afin de faciliter son implémentation.

Dans les cas d’usages et d’applications :
 De nombreux CSIRT, en particulier en Europe, ont adopté ou adapté la taxonomie eCSIRT.net pour leur classification interne des incidents. Elle a servi de base à des déclinaisons nationales ou sectorielles. Par exemple, des CERT nationaux (CERT.PT au Portugal, CERT.BE en Belgique, etc.) ont utilisé eCSIRT.net comme point de départ de leur propre taxonomie d’incidents.

L’utilisation d’eCSIRT.net permet à ces équipes de classifier de manière cohérente les incidents dans leurs systèmes de ticketing et rapports, et de générer des statistiques uniformisées d’une année sur l’autre. La simplicité et la clarté de ses catégories la rendent compréhensible également pour des parties prenantes non techniques (direction, partenaires). Notons que la taxonomie eCSIRT.net a évolué au fil du temps : une version mise à jour dite eCSIRT.net mkII a été publiée en 2013 afin d’affiner certaines catégories et d’en ajouter de nouvelles face à l’émergence de nouvelles menaces.

Les avantages :
 La taxonomie eCSIRT.net a pour atout principal d’être simple et pragmatique. Son vocabulaire est compréhensible et couvre les notions de base sans complexité inutile, ce qui la rend appropriée à un usage opérationnel quotidien. Elle offre par ailleurs une structure multi-niveaux (catégorie / type) autorisant une agrégation efficace des données : par exemple, on peut comptabiliser tous les incidents classés sous la classe « Intrusions » ou zoomer sur un type spécifique comme « cheval de Troie » selon le besoin.
De plus, ayant été largement adoptée, elle a favorisé un langage commun au sein de la communauté des CSIRT pendant de nombreuses années.

les limites à mon sens :
 En contrepartie, eCSIRT.net étant un schéma relativement ancien, certaines catégories peuvent sembler trop générales ou datées face à l’évolution rapide des menaces. Par exemple, la catégorie « code malveillant » agrège toute sorte de malware sans distinguer les ransomwares, cryptomineurs, etc., ce qui peut limiter l’information si on ne prévoit pas des sous-catégories plus fines.
Par honnêteté, la recommandation dans la documentation eCSIRT est de classer tout logiciel malveillant dans « malicious code » même si ses effets varient.
Par ailleurs, certains concepts récents (tels que les attaques ciblant la chaîne d’approvisionnement logicielle, ou des catégories comme le phishing ciblé) ne sont pas explicitement adressés par la version de base.
Enfin, eCSIRT.net se focalise sur le type technique d’attaque et prend peu en compte d’autres dimensions utiles d’un incident (par ex. l’acteur menaçant ou l’impact business), ce qui nécessite de compléter avec d’autres cadres pour une vue complète.

Interopérabilité : La taxonomie eCSIRT.net a joué un rôle de pivot dans des efforts d’harmonisation. De nombreuses taxonomies ultérieures s’en sont inspirées ou l’ont partiellement intégré. Ainsi, la taxonomie de référence plus récente élaborée par ENISA et ses partenaires (voir plus loin) a utilisé eCSIRT.net comme point de départ.
De même, la plate-forme MISP propose un jeu de tags correspondant exactement aux catégories eCSIRT pour faciliter le partage (sous l’espace de nom ecsirt).
Néanmoins, eCSIRT.net étant principalement une classification des types d’incidents, son interopérabilité avec des taxonomies orientées menaces (comme ATT&CK) n’est pas directe ; elle peut nécessiter des tables de correspondance ou un mapping manuel (par ex. faire correspondre la catégorie « Intrusion » à une liste de techniques ATT&CK pertinentes, etc.). Nous verrons plus loin que cette interopérabilité s’améliore via l’émergence de taxonomies unifiées.

Les Taxonomies de l’ENISA (threat taxonomy et classification d’incidents)

L’ENISA (Agence de l’Union européenne pour la cybersécurité) a contribué de manière significative aux taxonomies en cybersécurité, à travers deux initiatives principales : d’une part une taxonomie des menaces (ENISA Threat Taxonomy) pour structurer l’information sur les cybermenaces, et d’autre part une taxonomie de classification des incidents souvent appelée taxonomie de référence ENISA pour uniformiser le signalement des incidents par les CSIRT en Europe.

ENISA Threat Taxonomy (taxonomie des menaces) :
 Face à la diversité croissante des cybermenaces, l’ENISA a publié en 2016 une première version de sa taxonomie des menaces, comme outil pour organiser et nommer de façon cohérente les différents types de menaces dans ses rapports de paysage des menaces (Threat Landscape). Mise à jour en 2022, cette taxonomie ENISA est devenue la référence standard pour catégoriser les menaces dans les publications de l’ENISA et sert de guideline interne pour l’analyse des menaces.

Elle classe les menaces cyber à un haut niveau en grandes familles et sous-catégories. Par exemple, la version 2016 distinguait des catégories de haut niveau comme les logiciels malveillants, les attaques Web, les attaques sur la disponibilité, les atteintes aux données, les campagnes d’influence, etc., chacune déclinée en sous-types plus précis. Cette taxonomie couvre à la fois des menaces intentionnelles (attaques) et d’autres sources de risque (ex. catastrophes naturelles, erreurs humaines), fournissant ainsi un cadre global pour structurer tout type d’événement menaçant.

Si on revient à l’origine et la structure :
 Élaborée par l’ENISA en concertation avec la communauté, la taxonomie des menaces s’appuie sur l’observation des tendances réelles et intègre d’autres taxonomies existantes lorsque pertinent. Elle est régulièrement affinée pour demeurer actionnable (“mature, actionable framework”) en fonction du retour d’expérience des analystes.

Par exemple, une révision en 2022 a pu ajouter de nouvelles catégories pour couvrir les menaces émergentes ou mieux aligner certaines notions avec le langage courant de la communauté.

Au niveau des usages :
Cette taxonomie est utilisée en premier lieu par l’ENISA elle-même pour rédiger ses rapports annuels « Cyber Threat Landscape ». De plus, elle sert de référence pour d’autres entités européennes ou nationales cherchant une nomenclature de menaces partagée. Par exemple, une CERT gouvernementale pourrait s’en inspirer pour structurer son propre rapport de tendances de menaces.
L’intégration de cette taxonomie dans des outils de partage d’information comme MISP (sous l’espace de nom enisa) facilite également son adoption par la communauté.

Les avantages et les limites :
La taxonomie des menaces de l’ENISA a l’avantage d’être complète et régulièrement mise à jour, ce qui en fait un standard vivant collant à l’actualité des attaques. Son usage officiel par une agence européenne confère une crédibilité et encourage l’harmonisation transfrontalière dans l’UE. En revanche, par sa nature générique et stratégique, elle peut manquer de granularité technique pour un usage opérationnel direct en SOC. Par exemple, elle va catégoriser une attaque par rançongiciel simplement comme un type de malware, sans détailler les techniques employées; on aura alors recours à d’autres taxonomies (comme ATT&CK) pour cette granularité. Elle vise plus à décrire le panorama qu’à servir d’outil de triage en temps réel.

Taxonomie de référence pour la classification des incidents (ENISA/EC3) :
Parallèlement à la taxonomie des menaces, l’ENISA a coordonné un effort pour harmoniser la classification des incidents de sécurité entre CSIRT, en collaboration avec Europol/EC3 et le réseau des CERT européens. Ce travail a abouti à une taxonomie commune appelée « Reference Incident Classification Taxonomy » (souvent abrégé RSIT pour Reference Security Incident Taxonomy). Publiée en 2018, cette taxonomie de référence est en fait une évolution de la taxonomie eCSIRT.net décrite plus haut, enrichie pour correspondre aux besoins actuels des CSIRT et incluant des correspondances vers le cadre légal (infractions pénales) afin de faciliter la coopération avec les forces de l’ordre .

L’Origine :
L’initiative a démarré en 2017 lors d’un atelier ENISA/EC3 réunissant CSIRT et services de police, constatant “l’urgence d’une liste de taxonomie de référence sur laquelle tous pourraient s’accorder”. Un groupe de travail dédié (RSIT Working Group) au sein de TF-CSIRT a été créé pour développer et faire vivre cette taxonomie.
La version initiale a pris comme point de départ eCSIRT.net mkVI et la taxonomie commune LE/CSIRT du CERT-PT, afin de capitaliser sur l’existant.

La structure :
La taxonomie de référence conserve une structure hiérarchique proche d’eCSIRT.net (des classes et types d’incidents), mais elle a affiné certaines définitions et ajouté des catégories pour couvrir des phénomènes récents. Par exemple, on y retrouve des classes similaires (Malicious code, Intrusion Attempts, Intrusions, Availability, Information Content Security, Fraud, Abusive Content, etc.), parfois renommées pour plus de clarté.
Une attention particulière a été donnée à la cohérence des termes afin que chaque catégorie soit mutuellement exclusive et bien définie. L’un des avantages notables de cette taxonomie est d’offrir en annexe un mapping avec d’autres taxonomies courantes, servant de pont pour traduire une classification locale en la référence commune . Par exemple, un incident classé « Web Defacement » dans un CERT pourrait correspondre à la classe « Information Content Security » de la taxonomie de référence, ce qui facilite la comparaison des statistiques entre équipes.

Adoption et usage :
Rapidement après sa publication, cette taxonomie de référence a été adoptée par de nombreux CSIRT en Europe pour le partage d’incidents dans des plateformes communes. Elle est notamment intégrée à la plateforme MISP sous l’appellation « rsit », où elle est disponible pour tagguer les événements.
Des outils de ticketing ou de gestion d’incidents (tels que RTIR, utilisés par certains CERT) ont également ajouté cette classification par défaut. L’utilisation de ce référentiel commun permet aux équipes de “parler le même langage” et d’agréger des données fiables à l’échelle européenne.
Par exemple, le réseau CSIRT européen peut consolider le nombre d’incidents de type « Intrusion » rapportés par chaque pays de manière cohérente.

Les avantages et limites :
Le principal atout de la taxonomie de référence ENISA est de représenter un consensus actuel de la communauté, répondant à un besoin de normalisation. En tant que synthèse de plusieurs schémas antérieurs, elle est assez complète tout en restant compréhensible. Son maintien via un groupe de travail ouvert (avec contributions sur GitHub) assure qu’elle peut évoluer si nécessaire.
Du côté des limites, on peut noter que comme toute classification figée, elle peut être moins réactive que l’apparition de nouvelles catégories d’incidents (les mises à jour nécessitent l’accord de la communauté). Par ailleurs, certaines équipes pourraient la trouver trop générique et préférer garder en interne des sous-types plus fins adaptés à leurs besoins (ce qu’elles peuvent faire, en mappant ensuite vers la catégorie RSIT la plus proche lors du partage externe).

En résumé, l’ENISA fournit à la fois un cadre pour nommer les menaces (menaces stratégiques et techniques) et une taxonomie pivot pour classer les incidents. Ces deux apports se situent à des niveaux différents mais complémentaires : la taxonomie des menaces aide à comprendre la nature des adversaires et des attaques à un niveau macro, tandis que la taxonomie d’incident de référence aide les CSIRT à parler d’une même voix lorsqu’ils décrivent des incidents qu’ils gèrent opérationnellement.

Classification de la fondation FIRST.ORG (schéma de catégorisation du FIRST)

Le FIRST (Forum of Incident Response and Security Teams) – organisation internationale rassemblant les équipes de réponse aux incidents a proposé également un schéma de classification visant à aider les CSIRT à gérer leurs cas de manière cohérente. L’un des documents de référence du FIRST en la matière est le guide intitulé “CSIRT Case Classification” (rédigé initialement pour un CSIRT d’entreprise), qui fournit des lignes directrices aux responsables d’incidents (Incident Managers) pour classer chaque nouveau cas selon trois axes : la catégorie d’incident, le niveau de criticité, et le niveau de sensibilité .

Objectif et origine : L’initiative du FIRST part du constat qu’une classification cohérente en interne permet au CSIRT d’assurer un suivi approprié des incidents et de fournir un reporting précis à la direction. Ce guide du FIRST propose donc une méthode et une taxonomie type pour y parvenir. Ce n’est pas une norme obligatoire, mais une recommandation de bonne pratique largement diffusée dans la communauté.

Structure du schéma du FIRST :
Catégories d’incident : Le FIRST suggère une liste de catégories normalisées dans laquelle chaque incident doit entrer. Par exemple, dans l’exemple de classification fourni, on trouve des catégories telles que : Déni de service, Malware, Intrusion externe (activité suspecte provenant de l’extérieur), Intrusion interne (activité suspecte en interne), Atteinte à la confidentialité (compromission d’informations sensibles), Acte illégal (fraude, vol, activités nécessitant l’intervention des autorités), Forensique (investigations numériques), Violation de politique (non-respect des politiques internes), etc..

Chaque catégorie est accompagnée d’une description et associée à un niveau de sensibilité par défaut (ex. Malware est typiquement marqué S3, sensibilité faible, alors qu’une Intrusion avec vol de données serait S1, hautement sensible). L’idée est d’englober tous les types d’incidents que le CSIRT pourrait gérer, y compris ceux qui ne relèvent pas d’une cyberattaque directe (par ex. assistance en matière de politique de sécurité, demandes de conseil – classées comme “Consulting”).

Les niveaux de criticité : Indépendamment du type, chaque incident reçoit un niveau de criticité (par exemple Criticité 1, 2 ou 3), qui détermine l’urgence de la réponse et l’effort à y consacrer. Le guide du FIRST fournit une matrice de criticité en fonction de l’impact potentiel de l’incident sur les systèmes critiques ou la clientèle, avec pour chacun des délais de réponse maximum et des exigences de communication pendant la gestion de l’incident.
Par exemple, un incident de criticité 1 (critique) exige une prise en charge immédiate (< 1 h) 24/7 et des mises à jour fréquentes aux parties prenantes, tandis qu’un incident de criticité 3 (faible) peut être traité durant les heures ouvrables normales avec des points de situation hebdomadaires.

Niveaux de sensibilité : Le schéma introduit aussi un marquage de la sensibilité/confidentialité du cas (S1, S2, S3…) qui indique à quel point l’information sur l’incident doit être restreinte. Par exemple, un incident S1 pourrait impliquer des données hautement sensibles ou des implications légales (donc diffusion limitée aux seuls personnels autorisés), tandis qu’un S3 serait relativement bénin du point de vue de la sensibilité. Ce niveau oriente la manipulation et le partage de l’information du cas.

Usages : Ce schéma de classification du FIRST est surtout utilisé comme guide interne par les CSIRT, notamment ceux du secteur privé qui veulent structurer leurs procédures. Il sert de modèle qu’une équipe peut adopter tel quel ou adapter à son contexte. Par exemple, un CSIRT d’entreprise adoptera une liste de catégories d’incidents similaire pour assurer que chaque analyste classe les incidents de la même façon dans l’outil de tickets. En outre, certains CSIRT nationaux s’inspirent également de ces recommandations pour harmoniser leur gestion interne, même s’ils utilisent par ailleurs la taxonomie de référence ENISA pour l’échange externe. Le document du FIRST a donc un rôle pédagogique et d’encadrement des pratiques.

Les avantages : Le schéma de classification du FIRST a le mérite d’être pragmatique et orienté processus. En couvrant la dimension de criticité et de sensibilité en plus de la simple catégorie technique, il aide à prioriser la réponse et à définir des SLA (accords de niveau de service) internes . Il insiste sur la cohérence et la rapidité de la classification (dès l’ouverture du ticket, l’incident doit être catégorisé et un niveau de criticité assigné) pour cadrer la réponse. Ce type de classification intégrée garantit que le CSIRT a une vision globale de son portefeuille d’incidents (combien d’incidents critiques en cours, combien relèvent de tel type, etc.) et qu’il peut en rendre compte efficacement à la direction.

Les limites : Ce schéma reste un exemple générique et doit être personnalisé. Les catégories proposées par le FIRST peuvent ne pas convenir exactement à toutes les organisations (certaines ajouteront par exemple une catégorie spécifique pour le phishing s’il est très fréquent, plutôt que de le ranger sous “Malware” ou “Intrusion externe”).
De plus, ce schéma étant surtout pensé pour un usage interne, il n’a pas de vocation d’être un standard universel pour l’échange de données entre organisations – il n’est pas autant normalisé qu’eCSIRT.net ou la taxonomie ENISA par exemple. Chaque organisation peut l’adapter, ce qui fait que deux CSIRT différents suivant le guide du FIRST n’auront pas forcément exactement les mêmes catégories ou seuils de criticité.
Enfin, l’approche du FIRST se concentre sur la gestion opérationnelle (SLA, etc.) et moins sur l’analyse fine des techniques d’attaque utilisées (on y parle de catégories larges comme “Malware” sans distinguer quel vecteur d’infection), donc elle gagnera à être complétée par des référentiels de menace lors de l’analyse a posteriori de l’incident.

En résumé, la contribution du FIRST en matière de taxonomie se traduit par un cadre de classification opérationnel aidant les CSIRT à classer et prioriser leurs incidents dès la détection. Ce cadre, bien que non obligatoire, s’est répandu comme une bonne pratique, souvent utilisé en parallèle des taxonomies techniques plus détaillées pour couvrir tous les besoins (classification interne et partage externe).

Taxonomies du projet MISP (classification pour le partage d’indicateurs)

MISP (Malware Information Sharing Platform, aujourd’hui renommé MISP Threat Sharing) est une plateforme open source largement utilisée par les CERT, CSIRT, SOC et autres communautés de renseignement sur les menaces pour partager des indicateurs de compromission et des informations sur les menaces. L’un des piliers de MISP est son système flexible de taxonomies de tags qui permet d’annoter les événements et indicateurs partagés avec des labels normalisés. Plutôt que d’introduire une énième taxonomie propriétaire, MISP a adopté une approche différente : il sert de contenant pour de multiples taxonomies existantes et propose un format standardisé pour les représenter et les échanger.

Concept de taxonomies dans MISP : MISP introduit la notion de machine tags (étiquettes formatées) sous forme de triplets namespace:predicate=value. Chaque ensemble de tags structuré selon un vocabulaire commun est appelé une taxonomie dans MISP. Par exemple, la taxonomie TLP (Traffic Light Protocol) est implémentée dans MISP avec des tags du type tlp:level=amber ou tlp:level=red. De même, la taxonomie eCSIRT.net est disponible sous forme de tags tels que ecsirt:malicious-code=virus etc. MISP maintient un référentiel de taxonomies sous forme de fichiers JSON, librement accessible sur GitHub, qui rassemble un grand nombre de taxonomies populaires .

Les taxonomies supportées : La bibliothèque MISP inclut plus d’une cinquantaine de taxonomies couvrant divers besoins. On y trouve des taxonomies techniques d’incident (eCSIRT.net , FIRST CSIRT, ENISA, VERIS , etc.), des taxonomies de menace et TTP (MITRE ATT&CK, kill chain , CAPEC), des taxonomies de contexte et gouvernance (ex. marqueurs de classification de documents OTAN, échelle Admiralty pour la fiabilité des sources , niveaux de confidence estimative, etc.), des taxonomies de secteur d’activité (ex. secteurs critiques DHS , secteur UE NIS), et bien d’autres encore.
L’objectif est de permettre aux utilisateurs de s’aligner sur un vocabulaire commun pour décrire chaque information partagée. Par exemple, si un analyste veut indiquer qu’un indicateur est lié à du phishing, il peut appliquer le tag misp:category= »phishing » (catégorie prédéfinie dans la taxonomie interne MISP) ou mieux, un tag issu d’une taxonomie standard telle que veris:action.social.phishing= »true » ou encore attack:tactic=initial-access + attack:technique=phishing-link si l’on utilise ATT&CK. Cette flexibilité fait de MISP un agrégateur de taxonomies.

Origine et structure : Les taxonomies MISP ont été initiées par le CIRCL (Luxembourg) qui développe MISP, en réponse au besoin de classifications partagées entre instances MISP. Le format JSON des taxonomies MISP a même fait l’objet d’un document de travail IETF pour standardisation. Chaque taxonomie est structurée en un fichier listant les termes acceptés (les “valeurs” possibles) et leurs définitions. Les taxonomies MISP sont modulaires : une organisation peut choisir d’activer uniquement certaines taxonomies pertinentes pour elle, et même définir ses propres taxonomies privées pour des besoins spécifiques  .

Usages et cas d’application : Dans la pratique, MISP permet lors de la création ou l’enrichissement d’un événement de lui appliquer des tags issus des taxonomies activées. Ces tags peuvent servir à filtrer le partage (par ex. ne partager qu’avec certains partenaires les événements taggués comme TLP:RED), à rechercher de l’information (ex. retrouver tous les événements liés à la catégorie “rançongiciel”), ou à donner du contexte aux indicateurs. Par exemple, on peut tagguer une adresse IP avec confidence:score=high (haute confiance) ou tlp:level=green (partage restreint) selon les taxonomies. L’un des cas d’application majeurs est l’échange au sein de communautés de confiance : en définissant un référentiel commun de tags (par exemple, en convenant d’utiliser la taxonomie “eCSIRT” pour typer les incidents et “TLP” pour la diffusion), plusieurs CSIRT peuvent partager via MISP des alertes et indicateurs de manière interopérable et compréhensible immédiatement par tous.

Avantages : L’approche MISP offre une grande souplesse et favorise l’interopérabilité. Plutôt que d’imposer une unique taxonomie, MISP permet à chacun de s’exprimer dans le vocabulaire standard de son choix, tout en rendant ces vocabulaires compris des autres. Les taxonomies MISP étant publiques et versionnées, toute amélioration ou ajout profite à l’ensemble de la communauté. En outre, parce que les tags sont exportables et attachés aux données, ils permettent un échange d’informations enrichies, on ne partage pas qu’une simple liste d’IP, on partage aussi leur classification (par ex. “IP liée à un malware de type cheval de Troie” via un tag). Cette richesse contextuelle améliore considérablement la qualité du renseignement échangé. Enfin, MISP fournit des outils (API, scripts) pour manipuler ces taxonomies, les convertir, ou en créer de nouvelles facilement .

Limites : La contrepartie de cette flexibilité est le risque de dispersion. Comme il existe de très nombreuses taxonomies disponibles, sans gouvernance forte, deux organisations pourraient choisir des taxonomies différentes pour tagguer le même concept, ce qui réintroduit de l’hétérogénéité. Par exemple l’une pourrait classifier un incident avec la taxonomie veris et l’autre avec la taxonomie eCSIRT, rendant la corrélation indirecte. Pour pallier cela, il convient au sein d’une communauté donnée de s’accorder sur les taxonomies principales à utiliser. Par ailleurs, l’utilisation correcte des tags suppose une discipline des analystes (choisir les bons tags parmi des dizaines n’est pas toujours intuitif et demande un apprentissage). Enfin, MISP ne résout pas les écarts de sémantique fine entre taxonomies; il les met juste toutes à disposition. C’est un outil, pas un référentiel normatif en soi.

En somme, MISP agit comme un catalyseur d’interopérabilité taxonomique. Il a intégré nativement les taxonomies de l’ENISA, du FIRST, de VERIS, etc., afin que les informations partagées via la plateforme puissent être comprises et filtrées aisément par les SOC, CERT et CSIRT du monde entier. Son approche illustre bien l’importance croissante de la standardisation machine-readable des taxonomies, condition essentielle pour échanger à grande échelle des indicateurs de menace de façon automatisée et pertinente.

Taxonomie VERIS (Vocabulary for Event Recording and Incident Sharing)

VERIS (Vocabulary for Event Recording and Incident Sharing) est un cadre de classification et un schéma de données conçu pour décrire de manière structurée les incidents de sécurité. Développé à l’origine par Verizon et utilisé notamment pour alimenter le célèbre rapport annuel DBIR (Data Breach Investigations Report), VERIS se présente comme un langage commun doté d’un ensemble de métriques pour consigner les détails d’un incident de façon cohérente et répétable.

Contrairement aux taxonomies plus simples qui listent des types d’incidents, VERIS est une modélisation multidimensionnelle complète d’un incident, couvrant les acteurs, les modes d’action, les actifs impactés, les conséquences, etc.

Une structure modulaire : Au cœur de VERIS se trouve le modèle dit A4 (quatre axes) qui décrit un incident en répondant aux questions suivantes : Acteurs (qui est à l’origine de l’incident ? ex. acteur externe, interne, partenaire, groupe menace spécifique), Actions (quelles actions malveillantes ont été menées ? ex. hacking, malware, ingénierie sociale, usage abusif, erreur, physique, environnemental), Actifs (quels actifs ou ressources ont été touchés ? ex. serveurs, base de données, personnes, réseaux) et Attributs (quels impacts sur la confidentialité, l’intégrité, la disponibilité ?).
À chacun de ces axes correspond une taxonomie interne (appelée énumération) : par exemple l’axe Action se subdivise en catégories Hacking, Malware, Social, Misuse, Physical, Error, Environmental, chacune ayant des sous-catégories pour préciser (pour Malware : cheval de Troie, ransomware, spyware, etc.; pour Social : phishing, pretexting, etc.).
En plus du modèle A4, VERIS inclut un axe Victime (données démographiques sur la victime), un axe Timeline (découverte et réponse), un axe Impact (quantification des pertes ou dommages), et un axe Value Chain décrivant les actions de préparation en amont de l’attaque. L’ensemble forme un schéma JSON riche qui permet de coder intégralement un incident avec tous ses détails.

Origine et adoption : VERIS a été initié par l’équipe de Verizon qui, en analysant des milliers d’incidents pour le DBIR, a éprouvé le besoin d’un format standard pour collecter et comparer ces données. La première version date de la fin des années 2000 et le framework a depuis été rendu public et communautarisé (il existe un site web dédié, un GitHub ouvert sur le schéma, et une base de données communautaire d’incidents VERIS). Le DBIR s’appuie toujours sur cette taxonomie : chaque incident recensé dans le rapport est encodé en VERIS, ce qui permet de sortir des statistiques globales (par ex. X% des brèches impliquent de l’hameçonnage, Y% ont un acteur interne, etc.). Au-delà de Verizon, certaines grandes organisations utilisent VERIS en interne pour enregistrer et analyser leurs incidents, et des chercheurs l’utilisent pour partager des données d’incidents anonymisées.

Usages typiques : VERIS est particulièrement adapté à la collecte de données d’incident à grande échelle et à l’analyse statistique. Un CERT national pourrait par exemple encoder tous les incidents déclarés par ses constituants en VERIS pour identifier des tendances (secteurs les plus touchés, vecteurs d’attaque les plus fréquents, etc.). Le schéma étant public, il facilite l’échange anonyme d’incidents : deux organisations qui adoptent VERIS peuvent partager leurs jeux de données et les agréger sans ambiguïté sémantique. Par exemple, la VERIS Community Database (VCDB) sur GitHub compile des centaines d’incidents publics encodés VERIS mis à disposition pour la recherche . VERIS a aussi servi de base à certaines initiatives gouvernementales cherchant un format commun de rapport d’incident.

Avantages : L’avantage majeur de VERIS est sa complétude : en suivant la structure VERIS, on s’assure de n’oublier aucune dimension importante d’un incident (quoi, qui, comment, impact…). C’est un standard ouvert, mûr et éprouvé par plus d’une décennie de DBIR, ce qui lui confère une certaine autorité. En fournissant un langage formel, il permet de mesurer et gérer les risques de manière empirique et constructive à partir des expériences passées . Il est suffisamment flexible pour décrire tant une intrusion complexe qu’une erreur humaine, et permet la capture d’attributs quantitatifs (montant des pertes, nombre d’enregistrements compromis, etc.) utiles au management des risques. Pour la communauté, l’existence de VERIS a encouragé le partage de données sur les incidents au-delà des simples narratifs textuels, en facilitant l’anonymisation (puisqu’on catégorise au lieu de nommer des entités spécifiques).

Limites : En contrepartie, VERIS est un schéma lourd et complexe à mettre en œuvre au quotidien pour un SOC ou CSIRT. La granularité de détail demandée fait qu’il peut être chronophage de remplir un formulaire VERIS complet pour chaque incident. Il est donc souvent réservé à un usage a posteriori (quand on documente l’incident clos) ou agrégé (campagnes d’enquête, rapports annuels), plutôt qu’en pleine gestion d’incident. Par ailleurs, malgré ses efforts de normalisation, certaines catégories VERIS restent générales et sujettes à interprétation ; par exemple la frontière entre Hacking et Malware peut dépendre du point de vue. Il a fallu des guides d’utilisation pour homogénéiser les codages entre analystes. Un autre point est que VERIS, créé initialement pour les besoins du DBIR, qui va mettre l’accent sur des aspects statistiques macro (e.g. vecteur d’action) et ne détaille pas toujours finement les techniques d’attaque spécifiques utilisées, c’est ici qu’une complémentarité avec ATT&CK est utile (voir section suivante). En effet, ATT&CK va par exemple distinguer “Credential Dumping via Mimikatz”, alors que VERIS noterait plus globalement une action de type “Hacking Use of stolen creds”.

Interopérabilité : Sur le plan de l’interopérabilité, VERIS peut jouer le rôle de schéma pivot pour comparer des incidents provenant de différentes sources, à condition que ceux-ci soient mappés dans VERIS. Il existe des efforts notables pour relier VERIS à d’autres référentiels ; en particulier, le Centre for Threat-Informed Defense (MITRE) a conduit un projet de mapping entre VERIS et MITRE ATT&CK. Ce projet a établi des correspondances permettant de passer d’une valeur VERIS (par ex. Action.Malware.C2) à une ou plusieurs techniques ATT&CK pertinentes, et inversement. Le but est de tirer parti de la richesse de VERIS tout en bénéficiant de la précision d’ATT&CK pour décrire les comportements adverses. De même, des mappings vers la taxonomie de référence ENISA ou d’autres standards peuvent être envisagés, bien que la granularité différente rende l’exercice partiel (VERIS a des champs sans équivalent ailleurs et vice-versa). Enfin, mentionnons que MISP inclut VERIS dans ses taxonomies supportées, rendant possible l’étiquetage d’un événement MISP avec des catégories VERIS .

En somme, VERIS se distingue des autres taxonomies présentées ici par son ambition de tout capturer d’un incident en un format unifié. C’est un outil puissant pour l’analyse rétrospective et le partage de données d’incident de manière normalisée. Son usage au quotidien dans un SOC est moins direct, mais il influence fortement la manière dont on pense la data d’incident et incite à plus de rigueur dans la collecte d’informations lors des réponses à incidents.

Cadre MITRE ATT&CK (tactiques et techniques d’attaque)

Le MITRE ATT&CK est aujourd’hui l’un des référentiels les plus en vue dans le monde de la cybersécurité. Acronyme de Adversarial Tactics, Techniques & Common Knowledge, MITRE ATT&CK se présente comme une base de connaissance globale des tactiques et techniques employées par les adversaires, construite à partir d’observations réelles. Contrairement aux taxonomies de type “classes d’incidents”, ATT&CK ne classe pas les incidents en catégories, mais détaille comment les attaques se déroulent, étape par étape, du point de vue de l’attaquant. Il est ainsi largement utilisé par les SOC, les équipes de threat hunting et de renseignement pour analyser, mapper et contrer les activités malveillantes de manière plus granulaire.

Structure : Le cœur d’ATT&CK est le modèle des tactiques et techniques. On définit une tactique comme l’objectif stratégique d’un attaquant à une phase donnée de son opération (le “pourquoi”), et une technique comme la manière concrète d’atteindre cet objectif (le “comment”). MITRE a identifié actuellement 14 tactiques couvrant l’ensemble de la chaîne d’attaque, depuis la reconnaissance initiale jusqu’à l’impact final.
Parmi ces tactiques on trouve par exemple : Reconnaissance, Développement des ressources, Accès initial, Exécution, Persistance, Élévation de privilèges, Évasion de défense, Accès aux informations d’identification, Découverte, Mouvement latéral, Collecte, Commandement et contrôle, Exfiltration, Impact.
Pour chacune, de multiples techniques (et sous-techniques) sont documentées. Par exemple, pour la tactique Accès initial, on a des techniques comme Hameçonnage par pièce jointe (T1566.001), Exploitation de vulnérabilité externe (T1190), Utilisation d’informations d’identification valides (T1078), etc. Chaque technique est décrite en détail dans la base ATT&CK (mécanisme, exemples d’utilisation par des groupes APT, détection, mitigations).

Origine : Le framework ATT&CK a été développé par le MITRE à partir de 2013 environ, initialement pour modéliser les comportements d’attaquants dans des environnements Windows (projet ATT&CK Enterprise). Il a depuis été étendu à Linux, macOS, et à d’autres domaines (ATT&CK Mobile, ATT&CK pour ICS industrielles). MITRE le maintient et le met à jour régulièrement en intégrant de nouvelles techniques au gré de l’actualité et des contributions de la communauté. Il est mis à disposition librement et a un écosystème très actif.

Usages par les CSIRT/SOC : Le succès d’ATT&CK vient de son utilité concrète dans plusieurs cas d’usage :

  • Analyse d’incident et threat intelligence : Lorsqu’un incident est investigué, les analystes peuvent mapper les actions observées à des techniques ATT&CK spécifiques, ce qui permet de comprendre les tactiques de l’attaquant. Par exemple, une attaque ayant utilisé un script PowerShell encodé sera associée à la technique “Exécution via PowerShell” (T1059.001). Cette cartographie sert ensuite à enrichir les rapports de renseignement (en indiquant quelles techniques ont été employées par tel groupe menaçant) et à partager plus clairement les informations sur les TTP (Tactiques, Techniques et Procédures) adverses.
  • Défense et couverture de détection : Les SOC utilisent le matrix ATT&CK pour évaluer leurs capacités de détection et de protection. En listant l’ensemble des techniques et en notant lesquelles sont couvertes par des règles SIEM, EDR, etc., on identifie des lacunes. C’est une approche courante appelée “ATT&CK coverage” où l’on cherche à avoir au moins une alerte ou mesure de sécurité par technique critique. Par exemple, si aucune alerte n’est en place pour détecter l’utilisation d’outils de credential dumping (T1003), cela révèle une faiblesse à combler.
  • Red Teaming et évaluation : Les exercices de Red Team (intrusion simulée) sont souvent planifiés et reportés en termes ATT&CK. On va par exemple se fixer d’essayer plusieurs techniques d’accès initial (phishing, USB drop, exploitation) et voir lesquelles ont réussi, ce qui permet ensuite de discuter des défenses manquantes. De même, des frameworks d’émulation d’adversaire (Atomic Red Team, Caldera de MITRE) s’alignent sur ATT&CK.
  • Partage et standardisation : ATT&CK est devenu un langage commun pour décrire les attaques de manière normalisée. Ainsi, quand un rapport de renseignement indique qu’un groupe APT particulier utilise les techniques T1218 (Living-off-the-land via scripts système) et T1569 (Service Control), on comprend précisément de quelles actions il s’agit sans ambiguïté. Des formats d’échange comme STIX 2.1 permettent d’inclure des références ATT&CK pour décrire des modus operandi dans les renseignements partagés .

Avantages : Le référentiel MITRE ATT&CK a pour force d’être très détaillé et concret. Il couvre des centaines de techniques et scénarios, basés sur des cas réels, ce qui en fait une ressource extrêmement riche pour les praticiens. Son adoption quasi-unanime dans l’industrie en fait un standard de facto : SOC, éditeurs de solutions de sécurité, analystes du monde entier l’utilisent, ce qui aligne le vocabulaire. Il est aussi en constante évolution, suivant de près les nouvelles tactiques découvertes (ex. ajout de techniques d’attaque cloud, containers, etc. ces dernières années). ATT&CK encourage une approche plus proactive et méthodique de la défense (identifier des comportements plutôt que des signatures statiques). Enfin, c’est un référentiel ouvert et gratuit, favorisant les contributions communautaires.

Limites : On pourrait dire qu’ATT&CK n’est pas une taxonomie “traditionnelle” d’incidents et qu’il ne remplace pas les classifications d’incidents. En effet, ATT&CK ne va pas vous dire “cet événement est un incident de type ransomware” – il va plutôt l’exprimer comme une séquence de techniques (par ex. l’attaquant a utilisé T1566 Phishing, puis T1059 PowerShell, puis T1486 Data Encrypted for Impact). Cela nécessite une expertise pour être utilisé efficacement : le cadre ATT&CK peut être intimidant pour des débutants du fait du volume d’informations. Par ailleurs, toutes les attaques ne s’y prêtent pas – ATT&CK se focalise sur les intrusions intentionnelles; des incidents plus généraux (pannes, erreurs sans adversaire) n’y entrent pas. Enfin, ATT&CK n’indique pas la sévérité ou l’impact d’un incident (ce n’est pas son objet). Il est donc souvent utilisé conjointement avec d’autres schémas (par ex. on utilise ATT&CK pour décrire l’attaque, et une taxonomie d’incident pour classer l’incident global, ou VERIS pour capturer l’impact).

Interopérabilité : ATT&CK s’intègre bien dans l’écosystème de partage : comme mentionné, STIX intègre nativement les objets ATT&CK (Groupes, Logiciels, Techniques) pour enrichir les échanges CTI. De plus, MISP propose également des galaxies ATT&CK (collections d’objets) et la taxonomie “attack” pour tagguer avec Tactique/Technique . Il existe aussi des correspondances établies entre ATT&CK et d’autres modèles : la Cyber Kill Chain (Lockheed Martin) peut se mapper aux tactiques ATT&CK (chaque phase de la kill chain correspond grossièrement à une ou plusieurs tactiques ATT&CK, par ex. Delivery → Accès initial), et comme évoqué, un mapping vers VERIS a été réalisé pour faire le lien entre techniques et catégories d’actions. Ces interconnexions permettent aux SOC et CSIRT de traduire entre un langage d’incident (ex. un incident classé “intrusion via phishing” peut être enrichi par “technique ATT&CK T1566 utilisée”) et un langage de menace technique.

En synthèse, MITRE ATT&CK apporte un cadre taxonomique focalisé sur le comment des attaques, parfaitement complémentaire des taxonomies orientées quoi/qui/impact vues précédemment. Son adoption massive en fait un outil incontournable pour les SOC/CSIRT modernes, utilisé aussi bien en prévention (pour identifier les lacunes de sécurité) qu’en détection et en réponse (pour comprendre et communiquer les mécanismes d’attaque). Il ne couvre pas à lui seul tous les besoins (il ne qualifie pas la nature juridique d’un incident, ni son impact business), mais combiné à une classification d’incident traditionnelle, il offre une vue à 360° nécessaire dans le monde actuel des cybermenaces.

Autres taxonomies et frameworks notables

En plus des taxonomies majeures détaillées ci-dessus, les équipes de sécurité peuvent recourir à d’autres modèles de classification ou d’analyse, souvent complémentaires, pour adresser des besoins spécifiques. En voici quelques-uns qui, sans être développés en détail dans cet article, méritent d’être mentionnés :

  • Cyber Kill Chain : Introduit par Lockheed Martin en 2011, le modèle de la Cyber Kill Chain décrit les 7 étapes d’une attaque ciblée (Reconnaissance, Armement, Livraison, Exploitation, Installation, Commande & Contrôle, Atteinte aux objectifs) . Il fournit un cadre simple pour comprendre le déroulement d’une intrusion de manière chronologique et identifier à quelle étape l’attaque a pu être détectée ou stoppée. La Kill Chain est souvent utilisée en conjonction avec ATT&CK (les tactiques ATT&CK se mappent sur ces étapes) pour structurer des rapports ou planifier des contrôles de sécurité à chaque phase.
  • Modèle Diamond : Proposé en 2013 par Caltagirone et al., le Diamond Model est un framework d’analyse qui représente un événement de sécurité comme une relation entre quatre éléments principaux (Adversaire, Infrastructure, Capacité et Victime). Ce modèle incite les analystes à examiner chaque incident sous ces quatre angles (qui est l’adversaire, quelle infrastructure a-t-il utilisée, quelle capacité/technique a-t-il employée, qui était la victime/cible) et à explorer les liens entre incidents via ces pivots communs. Le Diamond Model est très utilisé en threat intelligence pour relier des campagnes d’attaque entre elles via des points communs (même infrastructure d’attaque, mêmes outils, etc.), mais ce n’est pas une taxonomie de classification à proprement parler – plutôt un cadre conceptuel d’enquête.
  • Standards de catégorisation d’informations : On peut citer également des taxonomies non techniques mais importantes pour les CSIRT/SOC, comme le Traffic Light Protocol (TLP), qui définit un code couleur (White/Green/Amber/Red) pour classifier la sensibilité des informations partagées . Bien que TLP ne catégorise pas des incidents ou menaces, c’est une taxonomie de diffusion de l’information essentielle pour indiquer jusqu’à quel point un renseignement peut être partagé. De même, l’échelle d’Admiralty (NATO) mentionnée plus haut permet de tagguer la fiabilité des sources et la crédibilité des informations (par des codes comme A1, B2, etc.) . Ces systèmes, disponibles aussi dans MISP, font partie de l’outillage quotidien des analystes pour gérer et échanger de l’information en toute confiance.
  • CAPEC et CWE : Pour être complet, mentionnons que le MITRE maintient aussi CAPEC (Common Attack Pattern Enumeration and Classification), un catalogue de patterns d’attaque connus, et CWE (Common Weakness Enumeration) qui recense les types de vulnérabilités logicielles. Ces deux référentiels sont utilisés par les équipes techniques (développeurs, pentesteurs) pour classifier respectivement les méthodes d’attaque et les faiblesses de code. Par exemple, CAPEC peut décrire un schéma d’attaque comme “Injection SQL” ou “Spearphishing via service web”, et CWE va qualifier une vulnérabilité comme “Buffer Overflow” ou “Injection OS Command”. Bien qu’ils ne soient pas directement utilisés pour classer les incidents, ils s’intègrent dans l’écosystème global de la taxonomie cyber (notamment via des liens vers ATT&CK, CVE, etc.) et fournissent un langage précis pour la description des techniques et failles.

Chaque organisation peut donc enrichir son approche en combinant plusieurs taxonomies et modèles selon le contexte : par exemple, un incident peut être classé selon eCSIRT/ENISA (ex. Intrusion/Malicious Code), décrit en techniques ATT&CK (ex. T1059 PowerShell, T1003 Credential Dumping), analysé via le Diamond Model (adversaire identifié, infrastructure utilisée, etc.), tout en marquant le partage de l’info en TLP:AMBER. Cette diversité peut sembler complexe, mais elle reflète la spécialisation de chaque référentiel pour un angle particulier de la cybersécurité.

Interopérabilité et correspondances entre taxonomies

Étant donné la multiplicité des taxonomies et frameworks en usage, un enjeu crucial est leur interopérabilité – c’est-à-dire la possibilité de faire correspondre ou traduire les classifications d’un système à l’autre pour permettre une compréhension mutuelle et un échange sans perte d’information. Plusieurs efforts ont vu le jour pour rapprocher ces référentiels ou au moins fournir des points de correspondance entre eux.

Taxonomie de référence comme pivot : Comme évoqué, l’ENISA et le réseau TF-CSIRT ont établi la Reference Incident Classification Taxonomy justement pour servir de pivot commun entre organisations . Cette taxonomie a été construite en intégrant les catégories d’eCSIRT.net et en y faisant correspondre la “Common Taxonomy” utilisée entre CSIRT et forces de l’ordre . L’idée est qu’un incident classé dans une taxonomie locale puisse être mappé à une catégorie de la taxonomie de référence. Par exemple, si une banque utilise sa propre liste interne de types d’incidents, elle peut associer chacun de ses types à l’un des codes de la taxonomie de référence, de sorte que lors d’un partage au régulateur ou à un CSIRT national, le code commun soit compris . Cet effort d’harmonisation est en constante amélioration via le groupe de travail RSIT (qui publie les changements sur GitHub et encourage les retours).

Intégration multi-taxonomies via MISP : La plateforme MISP joue un rôle important dans l’interopérabilité. En supportant simultanément de nombreuses taxonomies, elle permet à un même événement d’être taggué selon plusieurs référentiels. Par exemple, un indicateur partagé peut avoir un tag eCSIRT (ecsirt:intrusion-attempt) et un tag VERIS (veris:action.hacking.bruteforce=true), rendant l’équivalence explicite. MISP offre aussi des outils pour exporter les tags dans différents formats, ou pour filtrer selon une taxonomie spécifique, facilitant la conversion. En pratique, on voit des communautés adopter, via MISP, un jeu combiné de taxonomies : par ex. taxonomie de référence ENISA pour les classes d’incident, ATT&CK pour les TTP, TLP pour le niveau de diffusion – le tout dans un même flux de partage. Cela fluidifie énormément l’échange, chaque destinataire pouvant automatiser le traitement (ex. un script peut router les événements TLP:RED de façon isolée, ou déclencher une alerte si un tag ATT&CK critique apparaît). Ainsi, MISP concrétise l’interopérabilité en permettant aux outils de parler plusieurs langages en même temps.

Mappings entre schémas de menace : Dans le domaine de la threat intelligence, on a vu des projets de mapping entre frameworks de menace. Le plus notable est celui réalisé par le Center for Threat-Informed Defense (lié à MITRE) qui a aligné les catégories VERIS avec les techniques ATT&CK. Ce mapping, mis à jour en 2023, permet par exemple de passer d’une action VERIS “Malware – C2” à la technique ATT&CK T1071 (Communication chiffrée avec C2) ou T1095 (Exfiltration via un protocole externe) selon le contexte. L’inverse est également possible : donnée une technique ATT&CK observée, on peut associer quelles entrées VERIS correspondantes devraient être enregistrées (par ex. si T1569 Service Execution a été utilisée, alors dans VERIS on aura une action de type “Hacking – Abuse of functionality”). De telles correspondances enrichissent les deux mondes : elles apportent la dimension statistique de VERIS aux données ATT&CK, et la précision tactique d’ATT&CK aux données VERIS. Plus largement, ce genre d’initiative illustre l’intérêt d’aligner les taxonomies pour pouvoir pivoter de l’une à l’autre et bénéficier de la complémentarité des approches.

Standards et formats communs : L’interopérabilité passe aussi par l’adoption de formats standards qui véhiculent des champs normalisés. Par exemple, le format d’incident STIX 2.x possède des champs pour la classification type incident_category, dans lesquels des vocabulaires contrôlés (issus de la taxonomie ENISA, par ex.) peuvent être insérés. De plus, STIX 2 prend en charge nativement les objets ATT&CK (techniques, etc.) et permet aussi d’ajouter des labels libres. Ainsi, un rapport STIX sur un incident peut embarquer à la fois une catégorie générale et la liste des techniques observées, le tout de manière normalisée. D’autres formats orientés incidents, comme l’IDEA (Incident Declaration format, utilisé en Europe centrale), prévoient également des champs alignés sur la taxonomie eCSIRT.net, assurant que lorsqu’un CERT envoie une alerte dans ce format, le type d’incident est compréhensible sans ambiguïté.

Malgré ces efforts, il faut reconnaître que l’interopérabilité parfaite reste un idéal difficile à atteindre, en raison des différences de focales entre taxonomies. Néanmoins, la tendance est clairement à la convergence : on standardise le langage (via des initiatives comme celles de l’ENISA ou du FIRST), on outille les plateformes pour qu’elles supportent plusieurs référentiels (MISP, STIX), et on élabore des tables de correspondance pour combler les écarts (mapping VERIS-ATT&CK, etc.). Pour les CSIRT, CERT et SOC, cela se traduit concrètement par une amélioration de la collaboration : un incident déclaré par une équipe peut être ingéré par une autre dans ses propres catégories sans perdre de sens, et un renseignement partagé par une source peut être directement opérationnel chez le destinataire car les tags et références sont compris de manière identique.

Ma conclusion

Les taxonomies en cybersécurité sont un élément fondamental pour instaurer un langage commun entre professionnels de la sécurité, qu’il s’agisse de décrire un incident, de caractériser une menace ou de partager un indicateur. Ce comparatif a mis en évidence la complémentarité des différentes taxonomies utilisées par les CSIRT, CERT et SOC :

  • Les taxonomies d’incidents (telles qu’eCSIRT.net et son évolution dans la taxonomie de référence ENISA, ou le schéma FIRST) permettent de classer les événements de sécurité selon des catégories harmonisées, ce qui est essentiel pour le suivi interne et les rapports statistiques. Elles répondent à la question “Quel type d’incident est-ce ?”.
  • Les taxonomies de menaces et techniques (ENISA Threat Taxonomy, MITRE ATT&CK, kill chain, etc.) apportent un éclairage sur les méthodes des attaquants et les tactiques employées. Elles aident à comprendre “Comment l’attaque se déroule-t-elle ?” et “Quel est l’objectif de l’adversaire ?”.
  • Des frameworks complémentaires comme VERIS offrent une vision encore plus large en structurant l’information de bout en bout sur un incident (du mode opératoire jusqu’à l’impact), ce qui répond en détail à “Que s’est-il passé, comment, et avec quelles conséquences ?”.
  • Enfin, des schémas transverses (TLP, Admiralty, Diamond) répondent à d’autres besoins (protection du partage, évaluation de la fiabilité, analyse relationnelle).

Aucune de ces taxonomies ne prétend remplacer les autres – au contraire, les équipes de réponse aux incidents tendent à les utiliser de concert, chaque référentiel venant enrichir un aspect du cycle de vie de la sécurité. Par exemple, lors d’un incident réel : le SOC identifiera une intrusion (classification eCSIRT/ENISA), en analysera les techniques (mapping ATT&CK), notifiera l’incident selon la catégorie standard requise (taxonomie de référence ENISA, ou standard national), tout en partageant avec ses partenaires des IoC taggués en TLP et éventuellement en ATT&CK via MISP.

L’évolution actuelle va clairement vers plus de standardisation et d’interopérabilité. Les organismes internationaux et régionaux (FIRST, ENISA, etc.) poussent des référentiels communs adoptés par un nombre croissant d’équipes, ce qui facilite la coopération, y compris avec les autorités (une classification commune CSIRT-Police a vu le jour, par exemple). Les outils et formats modernes intègrent ces taxonomies, permettant un échange automatisé où le contexte n’est pas perdu.

Pour les organisations, le défi consiste à intégrer ces taxonomies dans leurs processus sans alourdir leur fonctionnement. Il s’agit de former les analystes à ce langage commun, de mapper les catégories internes existantes aux standards externes, et de tirer profit des informations riches que ces classifications peuvent apporter (par exemple, utiliser ATT&CK pour identifier des mesures de défense manquantes, ou VERIS pour quantifier les risques). Heureusement, la richesse de ces taxonomies s’accompagne de nombreux guides, outils et communauté de partage, qui en rendent l’adoption plus aisée qu’auparavant.

Mon expérience remonte que la plus grande difficulté pour cette conclusion, est de maîtriser les différentes taxonomies de cybersécurité qui sont devenu indispensable pour un CSIRT, CERT ou SOC moderne.

Marc Frédéric GOMEZ
Head of CERT

Cela permet non seulement d’améliorer sa propre efficacité (en ayant des processus de classification clairs, en parlant un langage commun en interne), mais aussi de mieux collaborer avec l’écosystème (partenaires, clients, autres équipes, autorités) en évitant les malentendus et en accélérant l’échange d’informations critiques. À l’ère des menaces globalisées, cette harmonisation des taxonomies contribue à construire une réponse collective plus unifiée et plus réactive face aux cyberattaques.

Sources

  • ENISA – Taxonomies in incident prevention and detection (Good Practice Guide): https://www.enisa.europa.eu/sites/default/files/publications/WP2016%202-1%20D6%20Incident-tracking-and-taxonomies.pdf
  • ENISA – Reference Incident Classification Taxonomy (report & task force): https://www.enisa.europa.eu/publications/reference-incident-classification-taxonomy (et dépôt GitHub associé : https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force)
  • ENISA – ENISA Threat Taxonomy (mentionné dans le Cyber Threat Landscape methodology 2025): https://www.enisa.europa.eu/sites/default/files/2025-08/ENISA%20CTL%20Methodology_Updated%20August%202025.pdf
  • FIRST – CSIRT Case Classification – Example guide: https://www.first.org/resources/guides/csirt_case_classification
  • Trusted Introducer / TF-CSIRT – De-facto Standards for CSIRTs (section Incident Taxonomy – eCSIRT.net & RSIT): https://www.trusted-introducer.org/trusted-introducer/processes/de-facto-standards/
  • MISP Project – MISP Taxonomy overview (MISP user guide and taxonomy list): https://misp.gitbooks.io/misp-book/content/taxonomy/ (et dépôt : https://github.com/MISP/misp-taxonomies)
  • Verizon – VERIS Framework (site officiel et documentation): https://verisframework.org/
  • Center for Threat-Informed Defense – Mappings Explorer (VERIS to ATT&CK mapping methodology): https://center-for-threat-informed-defense.github.io/mappings-explorer/about/methodology/veris-methodology/
  • MITRE – ATT&CK knowledge base (site officiel, matrices & techniques): https://attack.mitre.org/
  • Autres sources techniques (exemples de taxonomies eCSIRT, etc.):
    • Incident Classification selon eCSIRT (Don Stikvoort, v.mkVI 2015) – Switch.ch (PDF) : https://www.switch.ch/static/cert/Incident-Classification-CERTs.pdf
    • CNCS (Portugal) – Taxonomy for Incident Classification (adaptation nationale): https://www.cncs.gov.pt/certpt/servicos/taxonomia_incidentes.html (exemple de catégories Incident Class, Type…)