The Prestige

"You don't really want to work it out. You want to be fooled." — Le miroir défensif d'ATT&CK existe. Personne n'a vérifié s'il reflétait quelque chose.

L'article précédent posait la question : si ATT&CK, l'expression la plus aboutie du modèle detect-and-respond, produit 21% de couverture SIEM, 90% de faux positifs et 74% de brèches avec alertes ignorées, le problème est-il dans le cadre ou dans le modèle ?

MITRE a une réponse. Elle s'appelle D3FEND — Detection, Denial, and Disruption Framework Empowering Network Defense. Lancée en juin 2021, financée par la NSA, la version 1.3.0 (décembre 2025) catalogue 267 techniques défensives réparties en sept tactiques : Model, Harden, Detect, Isolate, Deceive, Evict, Restore¹. 128 000 utilisateurs enregistrés². L'ambition : pour chaque technique offensive ATT&CK, une contre-mesure défensive. L'hypothèse de symétrie.

J'ai examiné les 267 techniques, leur provenance, leur distribution, leur contenu opérationnel. Ce que j'ai trouvé ne correspond pas à l'ambition affichée.

D'où viennent les techniques

La FAQ de D3FEND décrit la méthode de construction. Le corpus source principal : plus de 500 brevets du U.S. Patent Office, déposés entre 2001 et 2018³. Pete Kaloroumakis, le créateur du framework, le confirme dans une interview pour Cisco en février 2022 : "The patent corpus was our initial focus for multiple reasons. There is strong motivation for inventors, investors, and organizations to describe and distinguish how their cybersecurity technologies work in patents."⁴

D'autres sources complètent le corpus : spécifications techniques ouvertes, bases de connaissances externes, dépôts de code source GitHub. Mais la règle est stricte. Kaloroumakis : "When we develop a D3FEND technique, we must point to some technical document which sufficiently details what the technology is doing. If there are no public technical references to use as evidence, we can't include it."⁴

D3FEND catalogue ce qui a été breveté ou documenté publiquement. Ce qui n'a pas été breveté n'existe pas dans le framework.

Un brevet protège une invention technique unitaire. On brevète un procédé de filtrage DNS par comparaison avec une liste de domaines autorisés. On ne brevète pas une architecture DNS multizone avec matrice de flux deny-by-default qui empêche by design l'utilisation du DNS comme canal d'exfiltration. Le brevet est atomique par construction. D3FEND hérite de cette granularité.

Ce que contient le catalogue

La répartition des 267 techniques par tactique :

Detect : 90 techniques, soit 33,7% du framework. Isolate : 57 (21,3%). Harden : 51 (19,1%). Model : 27 (10,1%). Evict : 19 (7,1%). Restore : 12 (4,5%). Deceive : 11 (4,1%)¹.

Un tiers du framework est consacré à la détection. L'article précédent documentait la situation de la détection : 21% de couverture SIEM, 960 alertes quotidiennes, 62% ignorées, 74% des brèches avec des alertes qui existaient mais n'ont pas été traitées. D3FEND consacre un tiers de son contenu au pilier dont les données empiriques montrent qu'il dysfonctionne.

Kaloroumakis explique pourquoi : "We initially focused on detection since that was our background, and we want to fill out more of the matrix this year."⁴ La surreprésentation de Detect reflète l'expertise de l'équipe, pas une doctrine.

À l'autre extrémité : Deceive, 11 techniques, 4,1%. Le seul pilier qui inverse l'asymétrie informationnelle entre attaquant et défenseur. Si quelqu'un utilise un Decoy User Credential, c'est un attaquant — le faux positif est quasi nul. La seule tactique qui sort du modèle detect-and-respond occupe la marge du framework. Elle y figure parce que Cymmetria et Attivo Networks ont breveté des technologies de deception, pas parce qu'un raisonnement doctrinal l'y a placée.

Des briques sans architecture

Prenons un problème concret : empêcher l'exfiltration de données par le protocole DNS.

D3FEND propose cinq techniques : DNS Allowlisting (D3-DNSAL), DNS Denylisting (D3-DNSDL), Forward Resolution Domain Denylisting, Homoglyph Denylisting, Reverse Resolution IP Denylisting⁵. Cinq opérations atomiques sur un artefact numérique — le trafic DNS.

Aucune de ces cinq techniques ne décrit la solution opérationnelle connue de tout architecte réseau : séparer l'infrastructure DNS en zones (resolver récursif interne isolé, forwarder conditionnel, resolver autoritaire externe), appliquer une matrice de flux où seul le forwarder est autorisé à émettre vers le port 53 sortant, interdire tout trafic DNS direct des postes clients vers l'extérieur. Cette architecture rend l'exfiltration DNS impossible by design, indépendamment de la qualité des listes de filtrage. La sécurité émerge de la composition, pas de la brique.

D3FEND ne sait pas modéliser cette composition. L'ontologie opère sur des artefacts numériques et des opérations unitaires. Elle sait dire "filtrer le DNS." Elle ne sait pas dire "architecturer le DNS de sorte que le filtrage devienne secondaire."

L'exfiltration par DNS fonctionne aussi par NTP⁶. Le protocole NTP (port 123/UDP) traverse la quasi-totalité des pare-feux d'entreprise. Des outils d'encodage de données dans les champs d'extension NTP existent. La solution architecturale est identique : seuls les serveurs NTP internes communiquent avec les serveurs NTP externes, les postes clients n'ont aucun accès NTP direct vers l'extérieur. Le même pattern s'applique à ICMP, à tout protocole autorisé en sortie.

D3FEND a un artefact "DNS Network Traffic" dans son ontologie. Il n'a pas d'artefact "NTP Network Traffic"⁷. Pas d'artefact, pas de relation inférée, pas de contre-mesure mappée. Le DNS est couvert parce que Cisco Umbrella et Infoblox ont breveté des produits de filtrage DNS — un marché existe. Le NTP n'est pas couvert parce que personne n'a breveté de produit de filtrage NTP dédié — pas de marché, pas de brevet, pas de technique D3FEND.

Le problème est identique. La solution architecturale est identique. Mais D3FEND ne voit que ce que le marché a breveté.

Ce que D3FEND ne fait pas

La FAQ MITRE pose les limites explicitement : "D3FEND does not prescribe specific countermeasures, it does not prioritize them, and it does not characterize their effectiveness."²

D3FEND ne priorise pas. Broadcast Domain Isolation (D3-BDI), qui peut neutraliser des dizaines de techniques de mouvement latéral ATT&CK en une seule implémentation, a le même poids ontologique que File Magic Byte Verification (D3-FMBV), qui vérifie les octets magiques d'un fichier. Le CISO qui cherche où investir d'abord ne trouvera pas de réponse.

D3FEND ne mesure pas l'effectivité. Les relations entre techniques défensives et techniques offensives utilisent le préfixe "may-" : may-counter, may-harden, may-isolate⁸. Une technique D3FEND peut contrer une technique ATT&CK. Peut-être. La relation est inférée par l'ontologie, pas validée par l'empirie.

D3FEND ne modélise pas l'architecture. Pas de notion de composition, de défense en profondeur, de propriété émergente. Pas de modèle de maturité, pas de séquence d'implémentation, pas de dépendance entre techniques.

ATT&CK, malgré les biais documentés dans l'article précédent, est construit sur des observations d'attaques réelles — la Cyber Threat Intelligence. D3FEND est construit sur ce que des vendeurs ont déclaré pouvoir faire dans des demandes de brevet. La distance entre "nous avons observé cette attaque" et "nous avons breveté cette contre-mesure" est la distance entre le terrain et le bureau d'étude.

Qui utilise D3FEND

Kaloroumakis a identifié sa cible : "We have initially described the audience as security architects."⁴ Les architectes sécurité — ceux qui conçoivent les systèmes, choisissent les mesures, dessinent les architectures DNS multizone.

L'industrie a réinterprété la cible. ManageEngine (vendeur SIEM) : "countermeasure techniques involve strategies that a SOC team can use"⁹. Vectra AI (vendeur NDR) : "Security Operations Centers use D3FEND to evaluate and improve detection coverage"¹⁰. Exabeam (vendeur SIEM/UEBA) : "Incorporate D3FEND into SOC playbooks"¹¹. Cymulate (vendeur BAS) : "SOC teams can use D3FEND to develop comprehensive detection coverage"¹².

L'industrie a poussé D3FEND vers les SOC parce que les SOC achètent des SIEM, des EDR, des XDR — les produits de ces mêmes vendeurs.

Le SOC ne met pas en place des mesures de sécurité. Son périmètre, dans tous les référentiels existants — NIST CSF, ISO 27001, ITIL — couvre la surveillance, la détection, le triage des alertes, la réponse aux incidents et l'escalade. Le SOC ne conçoit pas l'architecture DNS. Il ne déploie pas la segmentation réseau. Il ne définit pas la politique de hardening. Il n'installe pas de honeypots en production. Ces responsabilités relèvent de l'architecture sécurité, de l'ingénierie infrastructure, de la gouvernance SSI — des fonctions distinctes du SOC, avec des chaînes de responsabilité distinctes.

Harden, Isolate, Deceive, Model — quatre des sept tactiques D3FEND — ne relèvent pas du SOC. Seules Detect et Evict correspondent au périmètre opérationnel d'un centre de sécurité. D3FEND flotte entre l'architecte (qui pense en systèmes et n'a pas besoin d'un catalogue de briques atomiques) et le SOC (qui n'a autorité que sur la détection et la réponse, et pour lequel les CIS Controls ou les mitigations ATT&CK suffisent).

La boucle

L'article 11 de cette série documentait un circuit : Gartner définit les catégories, les vendeurs remplissent les catégories, les budgets suivent les catégories, l'innovation hors catégorie est invisible. Le radar dispense de réfléchir.

D3FEND reproduit le même circuit au niveau doctrinal. Le framework catalogue les techniques que le marché a brevetées. Les vendeurs déclarent couvrir les techniques du framework. Les acheteurs évaluent les vendeurs par rapport au framework. Les vendeurs développent ce que le framework référence. Ce que le framework ne référence pas n'existe pas dans la conversation.

Le NTP n'est pas dans D3FEND parce que personne ne l'a breveté. Personne ne l'a breveté parce qu'il n'y a pas de marché. Il n'y a pas de marché parce que le NTP n'est pas dans les frameworks d'évaluation. La boucle se ferme.

L'architecture DNS multizone n'est pas dans D3FEND parce qu'on ne brevète pas un design pattern. Un design pattern ne se vend pas comme un produit. Il requiert de l'expertise d'architecture, pas l'achat d'une solution. Et l'expertise d'architecture n'apparaît dans aucun Magic Quadrant.

D3FEND ne reflète pas la défense. Il reflète le marché de la défense. L'article 11 documentait la divergence entre le marché de la cybersécurité et la cybersécurité effective. D3FEND donne à cette divergence une formalisation académique en OWL 2 DL.

Ce que je ne sais pas

Je ne sais pas si D3FEND évoluera vers un outil opérationnel. Le projet est jeune — version 1.0 en janvier 2025 seulement. L'extension OT de décembre 2025¹³ montre une volonté d'élargissement. L'outil CAD (Countermeasure Architecture Design) introduit récemment pourrait, à terme, permettre de modéliser des compositions de défense. Mais en l'état, le framework reste un catalogue atomique.

Je ne sais pas si l'ontologie OWL 2 DL de D3FEND a une valeur pour la recherche académique que je sous-estime. Les requêtes SPARQL sur un graphe de connaissances formalisé permettent des inférences automatiques. Des travaux de recherche utilisent D3FEND pour de la modélisation de scénarios attaque-défense¹⁴. La valeur académique et la valeur opérationnelle sont deux choses différentes.

Je ne sais pas si les quatre personnes qui maintiennent D3FEND ont les moyens de combler les lacunes documentées ici. Le NTP, l'architecture, les mesures d'effectivité, le rééquilibrage Detect/Deceive — chacun de ces chantiers est considérable. Le financement NSA peut évoluer, dans un sens comme dans l'autre.

Ce que je sais : un architecte sécurité qui doit protéger une infrastructure critique dispose des CIS Controls (153 safeguards, priorisés, avec Implementation Groups par maturité), de NIST 800-53 Rev. 5 (plus de 1 000 contrôles, avec niveaux d'impact), d'ISO 27001 (avec processus de certification), et des mitigations ATT&CK intégrées au framework offensif. Chacun de ces outils est plus actionnable que D3FEND. Aucun n'est parfait. Mais chacun priorise, prescrit, ou mesure — les trois choses que D3FEND déclare ne pas faire.

Le miroir et la question

ATT&CK outillait un modèle — le detect-and-respond — qui a eu son utilité. Il a donné à la CTI un esperanto de la menace. Avant ATT&CK, chaque vendeur nommait les mêmes techniques différemment. La standardisation avait une valeur réelle, et la taxonomie survivra à MITRE comme le modèle OSI survit sans que personne ne consulte les documents ISO originaux.

D3FEND devait être le miroir défensif de cet esperanto. Le résultat est un catalogue de brevets formalisé en ontologie, incomplet sur des sujets que tout architecte réseau considère comme triviaux, incapable de penser l'architecture, sans mesure d'effectivité, adressé à un public qui n'en a pas l'usage, et récupéré par un marché qui s'en sert pour vendre des produits au seul acteur de la chaîne — le SOC — qui n'a pas autorité sur les mesures qu'il catalogue.

ATT&CK, avec ses biais de survivabilité, décrit au moins les avions qui reviennent. D3FEND décrit les briques que les fabricants d'abris ont brevetées, sans vérifier si elles protègent des bombes.

L'article précédent demandait si le problème est dans le cadre ou dans le modèle. La réponse de MITRE — D3FEND — ne résout ni l'un ni l'autre. Elle ajoute une couche. La question reste entière : si le detect-and-respond atteint ses limites empiriques, quel modèle le remplace ?

Quatorzième article d'une série sur les failles de construction de la cybersécurité occidentale :

• Article 1 : La vulnérabilité de la gestion des vulnérabilités
• Article 2 : La dépendance européenne aux standards américains
• Article 3 : Les États, architectes cachés du marché noir des vulnérabilités
• Article 4 : L'IA ou l'effondrement du modèle défensif occidental
• Article 5 : Desert Power — survivre sans l'Empire
• Article 6 : I Am Altering the Deal
• Article 7 : Le dernier canal
• Article 8 : Lord of Cyber War
• Article 9 : Les faucons du numérique
• Article 10 : They Live... we sleep
• Article 11 : Soylent Green
• Article 12 : Ghost in the Binary
• Article 13 : Now You See Me

Références

¹ MITRE D3FEND v1.3.0 (décembre 2025) — 267 techniques défensives, 7 tactiques, ontologie OWL 2 DL https://d3fend.mitre.org/

² MITRE D3FEND FAQ — "D3FEND does not prescribe specific countermeasures, it does not prioritize them, and it does not characterize their effectiveness." 128 000+ utilisateurs. https://d3fend.mitre.org/faq/

³ MITRE D3FEND FAQ — "a targeted sample of over 500 countermeasure patents from the U.S. Patent Office from the years 2001 to 2018, served as the source material to build this knowledge graph." https://d3fend.mitre.org/faq/

⁴ Cisco Blogs, Q&A on the MITRE D3FEND Framework (février 2022) — Interview de Pete Kaloroumakis, créateur de D3FEND. Citations sur le corpus de brevets, la cible architecte, la surreprésentation de Detect. https://blogs.cisco.com/security/qa-on-the-mitre-d3fend-framework

⁵ MITRE D3FEND — techniques Isolate > Network Isolation : DNS Allowlisting (D3-DNSAL), DNS Denylisting (D3-DNSDL), Forward Resolution Domain Denylisting, Homoglyph Denylisting, Reverse Resolution IP Denylisting https://d3fend.mitre.org/

⁶ MITRE ATT&CK, T1048 — Exfiltration Over Alternative Protocol. Le DNS est le canal d'exfiltration le plus documenté, mais le même mécanisme s'applique à NTP, ICMP, et tout protocole autorisé en sortie. https://attack.mitre.org/techniques/T1048/

⁷ MITRE D3FEND, Digital Artifact Ontology — L'ontologie référence "DNS Network Traffic" comme artefact numérique mais ne dispose pas d'artefact équivalent pour le trafic NTP. https://d3fend.mitre.org/dao/

⁸ MITRE D3FEND, ontologie OWL — Les relations entre techniques défensives et offensives utilisent le préfixe "may-" (may-counter, may-harden, may-isolate) indiquant des relations inférées, non validées empiriquement. https://d3fend.mitre.org/ontologies/d3fend.owl

⁹ ManageEngine, "MITRE D3FEND: A cyberdefense blueprint for blue teams everywhere" — "countermeasure techniques involve strategies that a SOC team can use to model digital systems; harden access to computer networks" https://www.manageengine.com/log-management/cyber-security/mitre-attack-mitre-defend-for-soc.html

¹⁰ Vectra AI, "MITRE D3FEND explained" (février 2026) — "Security Operations Centers use D3FEND to evaluate and improve detection coverage" https://www.vectra.ai/topics/mitre-d3fend

¹¹ Exabeam, "What Is MITRE D3FEND" (juillet 2025) — "Incorporate D3FEND into SOC playbooks" https://www.exabeam.com/explainers/mitre-attck/what-is-mitre-d3fend/

¹² Cymulate, "What is the MITRE D3FEND Matrix?" (août 2025) — "SOC teams can use D3FEND to develop comprehensive detection coverage" https://cymulate.com/cybersecurity-glossary/mitre-defend/

¹³ MITRE D3FEND for OT (décembre 2025) — Extension pour les environnements opérationnels (cyber-physical systems), financée par le Cyber Warfare Directorate et la NSA. https://d3fend.mitre.org/

¹⁴ ACM, "Cybersecurity Survivability Testing Technology Based on ATT&CK and D3FEND" (2025) — Utilisation académique de D3FEND pour la modélisation de scénarios attaque-défense. https://dl.acm.org/doi/10.1145/3728725.3728768