MITRE ATT&CK et CVE en cybersécurité

Le MITRE est une organisation américaine à but non lucratif, financée principalement par des contrats fédéraux, dont les productions ont dépassé depuis longtemps leur périmètre national. ATT&CK et CVE structurent désormais le travail quotidien des équipes de détection, de réponse à incident et de gestion des vulnérabilités.

→ Lire l’explication complète de la marmotte

Le MITRE, opérateur fédéral et référence mondiale

MITRE n’est plus développé comme un acronyme officiel. L’organisation est née aux États-Unis pour exploiter des centres de recherche financés par l’État fédéral, les Federally Funded Research and Development Centers, ou FFRDC (Federally Funded Research and Development Centers). Elle opère notamment des programmes pour la défense, l’aviation et la cybersécurité.

Cette origine compte. Le MITRE n’est ni une autorité de normalisation internationale comme l’ISO, ni une agence de régulation, ni un cabinet de conseil déguisé en fournisseur de slides. Ses référentiels ne créent pas d’obligation juridique directe. Leur autorité vient de leur adoption opérationnelle, de leur accès public et de leur capacité à établir un identifiant ou un vocabulaire stable entre éditeurs, chercheurs, administrations et équipes de sécurité.

Le compromis central est net : on gagne un langage partagé, largement gratuit et exploitable par machine ; on paie une dépendance à des classifications qui simplifient forcément des phénomènes complexes. La recommandation est donc d’adopter ATT&CK et CVE comme identifiants de travail, jamais comme modèle exhaustif de risque ou preuve de couverture sécurité.

Un numéro CVE ne dit pas si une vulnérabilité est exploitable dans un environnement donné. Une technique ATT&CK ne prouve pas qu’une détection fonctionne. Confondre référencement et protection est une forme très rentable de sommeil collectif.

Le MITRE occupe une place charnière entre plusieurs écosystèmes :

le NIST publie des cadres, contrôles et méthodes de gestion du risque ;
la CISA publie notamment le catalogue KEV (Known Exploited Vulnerabilities), centré sur les vulnérabilités exploitées ;
l’ANSSI fixe les attentes françaises en matière de sécurité, de qualification et de gouvernance ;
le MITRE fournit des identifiants et des taxonomies réutilisés par ces acteurs, les éditeurs de sécurité et les plateformes d’analyse.

Cette neutralité pratique ne doit pas être surinterprétée. Le financement fédéral américain impose de surveiller la pérennité des programmes, les conditions contractuelles et les évolutions de gouvernance. Un référentiel ouvert reste un actif externe. Il faut donc pouvoir en conserver une copie versionnée, documenter la version consommée et maintenir des règles internes indépendantes de sa disponibilité.

ATT&CK : décrire les comportements adverses

ATT&CK signifie Adversarial Tactics, Techniques, and Common Knowledge. Il s’agit d’une base de connaissances décrivant les comportements observés chez des adversaires : objectifs poursuivis, méthodes employées, logiciels, groupes attribués et mesures de détection ou de mitigation associées.

ATT&CK distingue notamment les tactiques, qui expriment un objectif, et les techniques, qui décrivent une manière d’y parvenir. Par exemple, l’accès à des comptes valides relève d’une technique fréquemment utilisée pour contourner des contrôles sans déclencher les alertes attendues. Le fait qu’une session soit authentifiée ne rend pas son usage bénin. Les journaux d’identité et les règles de détection doivent donc examiner le contexte, l’origine, le rythme et les privilèges, pas seulement le succès de l’authentification.

Pour une équipe SOC (Security Operations Center), ATT&CK sert à mapper une alerte ou un incident : chaque hypothèse de comportement reçoit un ou plusieurs identifiants. Cette cartographie permet ensuite de comparer les détections aux techniques couvertes, d’identifier les angles morts et de relier des sources de télémétrie aux scénarios d’attaque.

La bonne pratique consiste à rattacher chaque règle de détection à trois objets distincts :

une technique ATT&CK ciblée ;
les sources de données nécessaires à l’observation ;
les conditions précises de déclenchement et les faux positifs connus.

Sans cette séparation, une matrice ATT&CK devient rapidement un tableur décoratif, très photogénique et incapable d’expliquer pourquoi une alerte ne part jamais.

ATT&CK ne garantit pas la qualité des données collectées. Une détection associée à une technique reste aveugle si les événements nécessaires sont absents, tronqués ou conservés trop peu longtemps. La journalisation des annuaires, des postes, des équipements réseau, des services cloud et des outils d’administration doit être définie avant de mesurer la couverture. Le vocabulaire ne remplace pas les logs. Il leur donne une destination.

Les mises à jour ATT&CK doivent être traitées comme toute dépendance de sécurité : suivre les versions, analyser les techniques dépréciées ou renommées, mettre à jour les mappings et conserver l’historique des décisions. Une couverture affichée sur une ancienne version ne démontre rien sur la version courante. Les taxonomies aussi vieillissent, simplement avec moins de bruit qu’un serveur qui tombe.

CVE : identifier les vulnérabilités sans les confondre avec le risque

CVE signifie Common Vulnerabilities and Exposures. Un identifiant CVE référence publiquement une vulnérabilité connue sous une forme stable, par exemple CVE-2021-44228. Le programme CVE, historiquement opéré par le MITRE depuis 1999, attribue ces identifiants via des CNA (CVE Numbering Authorities), des autorités habilitées à réserver et publier des numéros pour des périmètres définis.

Le mécanisme évite que chaque éditeur, chercheur ou outil invente son propre nom pour le même défaut. Il permet de faire correspondre un avis d’éditeur, un scanner, un ticket de correction, une règle de détection et une exception de risque. C’est une fonction d’interopérabilité, pas une évaluation de danger.

Un CVE ne garantit pas :

qu’un correctif existe ;
que le logiciel concerné est déployé ;
que la vulnérabilité est exploitable ;
que l’exposition est accessible depuis un attaquant ;
que la compromission est détectable après exploitation.

La priorisation ne doit donc jamais reposer sur le seul CVSS (Common Vulnerability Scoring System), score de sévérité standardisé. Un score élevé sur un composant absent vaut zéro travail immédiat. À l’inverse, une vulnérabilité de score inférieur, exploitable sur un service exposé avec des privilèges élevés, mérite une correction prioritaire.

La décision doit croiser au minimum l’inventaire réel, la version installée, l’exposition réseau, les privilèges obtenus après exploitation, la disponibilité d’un correctif ou d’une mesure compensatoire, et l’existence d’exploitation active. Le catalogue KEV de la CISA est un signal de priorité fort, mais il ne remplace pas l’analyse de l’exposition locale.

La gestion opérationnelle impose aussi une discipline de données. Conserver le CVE comme clé primaire dans le registre de vulnérabilités, puis rattacher les actifs, exceptions, échéances, correctifs et preuves de remédiation. Écraser l’identifiant avec un libellé interne casse les rapprochements futurs. Les noms maison finissent toujours par produire une archéologie documentaire digne d’un site antique, sans le charme des colonnes.

Exemple : interroger une fiche CVE du MITRE

L’API publique CVE du MITRE expose les enregistrements publiés au format JSON (JavaScript Object Notation). La commande suivante interroge une vulnérabilité connue et extrait les descriptions françaises lorsqu’elles existent. Elle nécessite curl et jq.

# Récupérer l'enregistrement CVE depuis l'API publique du MITRE.
# jq sélectionne les descriptions dont la langue est le français.
curl --fail --silent \
  "https://cveawg.mitre.org/api/cve/CVE-2021-44228" \
  | jq -r '.containers.cna.descriptions[]
           | select(.lang == "fr")
           | .value'

Cette requête ne constitue pas une chaîne de traitement de vulnérabilités. En production, prévoir un cache horodaté, la journalisation des erreurs HTTP (Hypertext Transfer Protocol), un contrôle de schéma et une stratégie de reprise. Une indisponibilité de source externe ne doit pas supprimer la capacité à prioriser les vulnérabilités déjà inventoriées.

Les données récupérées doivent être rapprochées d’un inventaire de composants, idéalement sous la forme d’une nomenclature logicielle versionnée. Sans inventaire, l’automatisation produit une liste de numéros. Avec inventaire, elle produit des décisions : corriger, isoler, désactiver, surveiller ou accepter explicitement un risque résiduel.

Exploitation, sécurité et limites des référentiels MITRE

ATT&CK et CVE sont des données publiques. Aucun secret cryptographique, HSM (Hardware Security Module) ou coffre-fort de mots de passe ne protège leur consultation. En revanche, les enrichissements internes associés à ces référentiels peuvent révéler des informations sensibles : logiciels déployés, versions, défauts non corrigés, règles de détection, chemins d’attaque et systèmes critiques.

Les exports de vulnérabilités et matrices de couverture doivent donc être classifiés selon leur contenu réel. Une liste de CVE accompagnée d’hôtes, d’adresses internes et de dates de correction constitue un document d’attaque très convenablement indexé. L’attaquant apprécie généralement les bases de connaissance pré-remplies.

Prévoir les conditions d’exploitation suivantes :

versionner les jeux ATT&CK consommés et tracer la date de synchronisation ;
conserver les données CVE déjà ingérées pour résister à une indisponibilité externe ;
sauvegarder les mappings de détection, règles SIEM (Security Information and Event Management) et décisions de priorité ;
séparer les droits de modification des référentiels, des règles de détection et des exceptions de risque ;
superviser les échecs de synchronisation, les changements de schéma et les références devenues obsolètes ;
réexaminer périodiquement les exceptions, car une exception sans date d’expiration est un correctif qui a choisi une carrière administrative.

ATT&CK ne remplace pas une analyse de menace propre au système. Pour cela, relier les techniques aux actifs, aux chemins d’administration, aux dépendances d’identité et aux flux réseau. CVE ne remplace pas non plus la gestion de configuration : un actif non inventorié ne devient pas moins vulnérable parce qu’aucun scanner ne le voit.

La position à retenir est volontairement stricte : adopter ATT&CK pour structurer la détection et la réponse, adopter CVE pour relier les vulnérabilités entre outils, mais refuser toute métrique de couverture ou de conformité qui ne démontre ni la qualité de la télémétrie ni l’exposition effective. Les référentiels fournissent une grammaire. La sécurité commence quand les décisions opérationnelles suivent la phrase.

🐝 Ce qui arrive si on s’en passe

Sans identifiants partagés, chaque outil conserve son propre vocabulaire : un avis d’éditeur, un résultat de scanner, un ticket de correction et une règle de détection décrivent le même défaut sous quatre noms, et le rapprochement devient manuel, donc partiel. Les flux de renseignement sur la menace deviennent inexploitables, faute de clé de jointure avec la télémétrie locale. La transmission d’un incident entre équipes ou entre prestataires perd sa précision : les comportements observés se racontent en prose, ce qui empêche de vérifier si la même méthode est réapparue six mois plus tard. Les corrections se dupliquent sur certains actifs et manquent sur d’autres, et la reconstitution après incident ne peut plus démontrer quelle vulnérabilité a été traitée, à quelle date, ni sur quel périmètre.

🦫 Explication de la marmotte 🍫

Le MITRE est une organisation américaine qui produit des listes et des classifications utilisées par beaucoup d’organisations de sécurité dans le monde. Son rôle n’est pas de surveiller directement tous les systèmes ni d’imposer des lois. Il fournit surtout des repères communs.

Une première base décrit les méthodes utilisées par des attaquants. Elle classe leurs objectifs, puis les actions possibles pour atteindre ces objectifs. Une équipe de sécurité peut relier ses alertes à ces actions. Elle vérifie alors si ses ordinateurs, comptes et réseaux produisent les informations nécessaires pour repérer une attaque. Si les informations manquent, aucune classification ne peut les inventer.

Une seconde base donne un numéro public à chaque défaut de sécurité connu dans un logiciel. Ce numéro permet à un éditeur, un outil de scan et une équipe informatique de parler du même défaut. Mais le numéro ne dit pas automatiquement si le défaut touche réellement les machines présentes, ni si un attaquant peut l’exploiter.

Le travail réel consiste donc à croiser les listes du MITRE avec l’inventaire des logiciels installés, les accès réseau, les droits disponibles et les correctifs fournis. En cas d’échec de récupération des données externes, les copies déjà enregistrées doivent rester disponibles. Sans sauvegarde, suivi des changements et contrôle des accès aux données internes, ces référentiels restent des listes bien rangées, pas une défense.

Pages voisines

La citent

MITRE ATT&CK et CVE en cybersécurité

Elle cite

: les deux pages se citent l’une l’autre.

MITRE ATT&CK et CVE en cybersécurité

MITRE ATT&CK et CVE en cybersécurité

Le MITRE, opérateur fédéral et référence mondiale

ATT&CK : décrire les comportements adverses

CVE : identifier les vulnérabilités sans les confondre avec le risque

Exemple : interroger une fiche CVE du MITRE

Exploitation, sécurité et limites des référentiels MITRE

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines