The Prestige

"You don't really want to work it out. You want to be fooled." — ATT&CK's defensive mirror exists. Nobody checked whether it reflects anything.

The previous article asked the question: if ATT&CK, the most accomplished expression of the detect-and-respond model, delivers 21% SIEM coverage, 90% false positives, and 74% of breaches with ignored alerts, is the problem the framework or the model?

MITRE has an answer. It's called D3FEND — Detection, Denial, and Disruption Framework Empowering Network Defense. Launched in June 2021, funded by the NSA, version 1.3.0 (December 2025) catalogs 267 defensive techniques across seven tactics: Model, Harden, Detect, Isolate, Deceive, Evict, Restore¹. 128,000 registered users². The ambition: for each offensive ATT&CK technique, a defensive countermeasure. The symmetry hypothesis.

I examined all 267 techniques — their provenance, their distribution, their operational content. What I found does not match the stated ambition.

Where the techniques come from

The D3FEND FAQ describes the construction method. The primary source corpus: over 500 patents from the U.S. Patent Office, filed between 2001 and 2018³. Pete Kaloroumakis, the framework's creator, confirmed this in a Cisco interview in February 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."⁴

Other sources supplement the corpus: open technical specifications, external knowledge bases, GitHub code repositories. But the rule is strict. 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 catalogs what has been patented or publicly documented. What hasn't been patented doesn't exist in the framework.

A patent protects a single technical invention. You patent a DNS filtering process that compares queries against a list of authorized domains. You don't patent a multi-zone DNS architecture with a deny-by-default flow matrix that prevents by design the use of DNS as an exfiltration channel. Patents are atomic by construction. D3FEND inherits that granularity.

What the catalog contains

The distribution of 267 techniques by tactic:

Detect: 90 techniques, or 33.7% of the 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%)¹.

One-third of the framework is devoted to detection. The previous article documented the state of detection: 21% SIEM coverage, 960 daily alerts, 62% ignored, 74% of breaches with alerts that existed but were never acted upon. D3FEND devotes a third of its content to the pillar that empirical data shows is failing.

Kaloroumakis explains why: "We initially focused on detection since that was our background, and we want to fill out more of the matrix this year."⁴ The overrepresentation of Detect reflects the team's expertise, not a doctrine.

At the other end: Deceive, 11 techniques, 4.1%. The only pillar that inverts the information asymmetry between attacker and defender. If someone uses a Decoy User Credential, it's an attacker — the false positive rate is near zero. The only tactic that breaks out of the detect-and-respond model occupies the framework's margin. It's there because Cymmetria and Attivo Networks patented deception technologies, not because a doctrinal reasoning placed it there.

Bricks without architecture

Take a concrete problem: preventing data exfiltration through the DNS protocol.

D3FEND offers five techniques: DNS Allowlisting (D3-DNSAL), DNS Denylisting (D3-DNSDL), Forward Resolution Domain Denylisting, Homoglyph Denylisting, Reverse Resolution IP Denylisting⁵. Five atomic operations on a digital artifact — DNS traffic.

None of these five techniques describes the operational solution known to every network architect: separate the DNS infrastructure into zones (isolated internal recursive resolver, conditional forwarder, external authoritative resolver), apply a flow matrix where only the forwarder is allowed to emit to outbound port 53, deny all direct DNS traffic from client workstations to the outside. This architecture makes DNS exfiltration impossible by design, regardless of the quality of filtering lists. Security emerges from composition, not from the brick.

D3FEND cannot model this composition. The ontology operates on digital artifacts and unit operations. It can say "filter DNS." It cannot say "architect DNS so that filtering becomes secondary."

DNS exfiltration works just as well over NTP⁶. The NTP protocol (port 123/UDP) passes through nearly every enterprise firewall. Tools for encoding data in NTP extension fields exist. The architectural solution is identical: only internal NTP servers communicate with external NTP servers, client workstations have no direct outbound NTP access. The same pattern applies to ICMP, to any outbound-authorized protocol.

D3FEND has a "DNS Network Traffic" artifact in its ontology. It has no "NTP Network Traffic" artifact⁷. No artifact, no inferred relationship, no mapped countermeasure. DNS is covered because Cisco Umbrella and Infoblox patented DNS filtering products — a market exists. NTP is not covered because nobody patented a dedicated NTP filtering product — no market, no patent, no D3FEND technique.

The problem is identical. The architectural solution is identical. But D3FEND only sees what the market has patented.

What D3FEND does not do

The MITRE FAQ states the limits explicitly: "D3FEND does not prescribe specific countermeasures, it does not prioritize them, and it does not characterize their effectiveness."²

D3FEND does not prioritize. Broadcast Domain Isolation (D3-BDI), which can neutralize dozens of ATT&CK lateral movement techniques in a single implementation, carries the same ontological weight as File Magic Byte Verification (D3-FMBV), which checks a file's magic bytes. The CISO looking for where to invest first will find no answer.

D3FEND does not measure effectiveness. The relationships between defensive and offensive techniques use the "may-" prefix: may-counter, may-harden, may-isolate⁸. A D3FEND technique may counter an ATT&CK technique. Perhaps. The relationship is inferred by the ontology, not validated by evidence.

D3FEND does not model architecture. No notion of composition, defense in depth, or emergent properties. No maturity model, no implementation sequence, no dependencies between techniques.

ATT&CK, despite the biases documented in the previous article, is built on observations of real attacks — Cyber Threat Intelligence. D3FEND is built on what vendors claimed they could do in patent applications. The distance between "we observed this attack" and "we patented this countermeasure" is the distance between the field and the drawing board.

Who uses D3FEND

Kaloroumakis identified his target: "We have initially described the audience as security architects."⁴ Security architects — those who design systems, choose measures, draw multi-zone DNS architectures.

The industry reinterpreted the target. ManageEngine (SIEM vendor): "countermeasure techniques involve strategies that a SOC team can use"⁹. Vectra AI (NDR vendor): "Security Operations Centers use D3FEND to evaluate and improve detection coverage"¹⁰. Exabeam (SIEM/UEBA vendor): "Incorporate D3FEND into SOC playbooks"¹¹. Cymulate (BAS vendor): "SOC teams can use D3FEND to develop comprehensive detection coverage"¹².

The industry pushed D3FEND toward SOCs because SOCs buy SIEMs, EDRs, XDRs — the products of those same vendors.

A SOC does not implement security measures. Its scope, in every existing framework — NIST CSF, ISO 27001, ITIL — covers monitoring, detection, alert triage, incident response, and escalation. The SOC does not design DNS architecture. It does not deploy network segmentation. It does not define hardening policies. It does not install honeypots in production. These responsibilities belong to security architecture, infrastructure engineering, and security governance — functions distinct from the SOC, with distinct chains of responsibility.

Harden, Isolate, Deceive, Model — four of D3FEND's seven tactics — fall outside the SOC's scope. Only Detect and Evict match the operational perimeter of a security operations center. D3FEND floats between the architect (who thinks in systems and doesn't need a catalog of atomic bricks) and the SOC (which only has authority over detection and response, and for which CIS Controls or ATT&CK mitigations suffice).

The loop

Article 11 in this series documented a circuit: Gartner defines the categories, vendors fill the categories, budgets follow the categories, innovation outside the categories is invisible. The radar substitutes for thinking.

D3FEND reproduces the same circuit at the doctrinal level. The framework catalogs the techniques the market has patented. Vendors declare coverage of the framework's techniques. Buyers evaluate vendors against the framework. Vendors develop what the framework references. What the framework doesn't reference doesn't exist in the conversation.

NTP is not in D3FEND because nobody patented it. Nobody patented it because there's no market. There's no market because NTP is not in the evaluation frameworks. The loop closes.

Multi-zone DNS architecture is not in D3FEND because you don't patent a design pattern. A design pattern doesn't sell as a product. It requires architecture expertise, not a product purchase. And architecture expertise doesn't appear in any Magic Quadrant.

D3FEND doesn't reflect defense. It reflects the defense market. Article 11 documented the divergence between the cybersecurity market and effective cybersecurity. D3FEND gives that divergence a formal academic expression in OWL 2 DL.

What I don't know

I don't know whether D3FEND will evolve into an operational tool. The project is young — version 1.0 only shipped in January 2025. The December 2025 OT extension¹³ shows a willingness to expand. The recently introduced CAD tool (Countermeasure Architecture Design) could eventually enable defense composition modeling. But as it stands, the framework remains an atomic catalog.

I don't know whether D3FEND's OWL 2 DL ontology has academic research value I'm underestimating. SPARQL queries on a formalized knowledge graph enable automatic inferences. Research papers use D3FEND for attack-defense scenario modeling¹⁴. Academic value and operational value are different things.

I don't know whether the four people maintaining D3FEND have the means to address the gaps documented here. NTP, architecture, effectiveness measurement, rebalancing Detect versus Deceive — each of these is a substantial undertaking. NSA funding can shift, in either direction.

What I know: a security architect protecting critical infrastructure has the CIS Controls (153 safeguards, prioritized, with Implementation Groups by maturity), NIST 800-53 Rev. 5 (over 1,000 controls, with impact levels), ISO 27001 (with a certification process), and ATT&CK mitigations built into the offensive framework. Each of these tools is more actionable than D3FEND. None is perfect. But each prioritizes, prescribes, or measures — the three things D3FEND declares it does not do.

The mirror and the question

ATT&CK served a model — detect-and-respond — that had its use. It gave CTI an esperanto of threats. Before ATT&CK, each vendor named the same techniques differently. The standardization had real value, and the taxonomy will outlive MITRE the way the OSI model survives without anyone consulting the original ISO documents.

D3FEND was meant to be the defensive mirror of that esperanto. The result is a patent catalog formalized into an ontology, incomplete on topics any network architect considers trivial, unable to think in terms of architecture, with no effectiveness measurement, aimed at an audience that has no use for it, and co-opted by a market that uses it to sell products to the one actor in the chain — the SOC — that lacks authority over the measures it catalogs.

ATT&CK, with its survivorship biases, at least describes the planes that came back. D3FEND describes the bricks that shelter manufacturers patented, without checking whether they protect against bombs.

The previous article asked whether the problem lies in the framework or the model. MITRE's answer — D3FEND — resolves neither. It adds a layer. The question remains: if detect-and-respond has reached its empirical limits, what model replaces it?

Fourteenth article in a series on the structural flaws of Western cybersecurity (articles 1-5 in French):

• 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: The Last Channel
• Article 8: Lord of Cyber War
• Article 9: The digital hawks
• Article 10: They Live... we sleep
• Article 11: Soylent Green
• Article 12: Ghost in the Binary
• Article 13: Now You See Me

References

¹ MITRE D3FEND v1.3.0 (December 2025) — 267 defensive techniques, 7 tactics, OWL 2 DL ontology 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+ users. 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 (February 2022) — Interview with Pete Kaloroumakis, D3FEND creator. Citations on patent corpus, architect target audience, Detect overrepresentation. https://blogs.cisco.com/security/qa-on-the-mitre-d3fend-framework

⁵ MITRE D3FEND — Isolate > Network Isolation techniques: 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. DNS is the most documented exfiltration channel, but the same mechanism applies to NTP, ICMP, and any outbound-authorized protocol. https://attack.mitre.org/techniques/T1048/

⁷ MITRE D3FEND, Digital Artifact Ontology — The ontology references "DNS Network Traffic" as a digital artifact but has no equivalent artifact for NTP traffic. https://d3fend.mitre.org/dao/

⁸ MITRE D3FEND, OWL ontology — Relationships between defensive and offensive techniques use the "may-" prefix (may-counter, may-harden, may-isolate) indicating inferred, not empirically validated, relationships. 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" (February 2026) — "Security Operations Centers use D3FEND to evaluate and improve detection coverage" https://www.vectra.ai/topics/mitre-d3fend

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

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

¹³ MITRE D3FEND for OT (December 2025) — Extension for operational technology environments (cyber-physical systems), funded by the Cyber Warfare Directorate and the NSA. https://d3fend.mitre.org/

¹⁴ ACM, "Cybersecurity Survivability Testing Technology Based on ATT&CK and D3FEND" (2025) — Academic use of D3FEND for attack-defense scenario modeling. https://dl.acm.org/doi/10.1145/3728725.3728768