D3FEND Is a Better Parts Catalog. This Is Where the Parts Go.
D3FEND catalogs 272 defensive countermeasures, and its taxonomy is more granular than anything here. ASOM-Fed is not a rival catalog — it is a scheme for arraying one. So the useful question is not which is bigger, it is whether every part in the catalog has somewhere to sit in the scheme.
D3FEND v1.5.0 · 432 technique-to-technique mappings · every figure on this page computed from the published register
240 of 272, and a Reason for the Rest.
The denominator is the whole point. A coverage claim that lists only what it covers is the shape of a document that overstates itself, so the full D3FEND register is published alongside the mapping and this page counts against it.
4 of the seven tactics are reached in full. The shortfall is concentrated in Harden at 63%, and it is not an oversight — most of what sits there is configuration hardening inherited from the SP 800-53 baseline, which a scheme of maneuver assumes rather than schedules. Every gap is listed below with the reason it is a gap.
New to this vocabulary? The framework fixes 10 object classes, and four of them are ordinary English words doing exact work. The object model states each one with the question it answers and the class it is most often mistaken for.
Where the Coverage Sits, and Where It Does Not.
D3FEND's seven tactics are not a sequence and do not map onto the six campaign phases. They are kinds of countermeasure, which is exactly why a scheme of maneuver has to reach all of them.
Model
27/27100% reached · complete
Harden
35/5663% reached · 21 not reached
Detect
80/9089% reached · 10 not reached
Isolate
56/5798% reached · 1 not reached
Deceive
11/11100% reached · complete
Evict
19/19100% reached · complete
Restore
12/12100% reached · complete
Every Mapping, Both Directions.
The join is technique-to-technique. Mapping ASOM-Fed's controls onto D3FEND would cross abstraction levels — a control is an assessable obligation, a D3FEND technique is a countermeasure, and the thing with a countermeasure's shape here is the technique.
That a technique reaches a D3FEND countermeasure says the two describe the same defensive act. It does not say the countermeasure is deployed, configured, or working — that is an assessment finding about your estate, not a property of the framework. Each D3FEND identifier links to its own entry here, which lists the ASOM-Fed techniques that reach it — the direction a reader arriving from D3FEND actually needs.
32 Countermeasures This Framework Does Not Reach.
Published rather than omitted. A coverage claim is only checkable if the misses are named, and several of these are scope statements rather than gaps — a maneuver framework that scheduled every configuration setting would be a baseline, not a scheme.
| D3FEND | Tactic | Why it is not reached |
|---|---|---|
| D3-AEM Application Exception Monitoring | Detect | Below the maneuver-planning level of abstraction; inherited from the SP 800-53 baseline. |
| D3-ANAA Administrative Network Activity Analysis | Detect | Below the maneuver-planning level of abstraction; inherited from the SP 800-53 baseline. |
| D3-APM Application Performance Monitoring | Detect | Below the maneuver-planning level of abstraction; inherited from the SP 800-53 baseline. |
| D3-CA Certificate Analysis | Detect | Below the maneuver-planning level of abstraction; inherited from the SP 800-53 baseline. |
| D3-CFI Control Flow Integrity | Harden | Source-code and compiler hardening. ASOM-Fed excludes secure SDLC (PR.PS-06) as inherited from SA-15. |
| D3-DCE Dead Code Elimination | Harden | Compiler-level. Secure SDLC, inherited. |
| D3-DNSTA DNS Traffic Analysis | Detect | Below the maneuver-planning level of abstraction; inherited from the SP 800-53 baseline. |
| D3-EHPV Exception Handler Pointer Validation | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-EMH Electromagnetic Radiation Hardening | Harden | Electromagnetic radiation hardening — outside the archetype. |
| D3-ET Encrypted Tunnels | Isolate | Below the maneuver-planning level of abstraction; inherited from the SP 800-53 baseline. |
| D3-IPCTA IPC Traffic Analysis | Detect | Below the maneuver-planning level of abstraction; inherited from the SP 800-53 baseline. |
| D3-IPRA IP Reputation Analysis | Detect | Subsumed by D3-IRA Identifier Reputation Analysis, which M1.06, M1.10, M9.04 and M10.01 cover. |
| D3-IRV Integer Range Validation | Harden | Input-validation countermeasure at code level. Secure SDLC, inherited. |
| D3-MA Message Analysis | Detect | Abstract parent of message-analysis techniques; children are covered via M1.08 and M5.12. |
| D3-MBSV Memory Block Start Validation | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-MH Message Hardening | Harden | Abstract parent of message-hardening techniques; children are covered via M2.15. |
| D3-NPC Null Pointer Checking | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-OLV Operational Logic Validation | Harden | Code-level logic validation. Secure SDLC, inherited. |
| D3-PAN Pointer Authentication | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-PHDURA Per Host Download-Upload Ratio Analysis | Detect | Below the maneuver-planning level of abstraction; inherited from the SP 800-53 baseline. |
| D3-PRH Particle Radiation Hardening | Harden | Particle radiation hardening — outside the archetype. |
| D3-PSEP Process Segment Execution Prevention | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-PV Pointer Validation | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-RFS RF Shielding | Harden | RF shielding — outside the archetype. |
| D3-RH Radiation Hardening | Harden | Radiation hardening — spacecraft and high-radiation environments outside the Federal Reference Agency archetype. |
| D3-RN Reference Nullification | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-RTA RPC Traffic Analysis | Detect | Below the maneuver-planning level of abstraction; inherited from the SP 800-53 baseline. |
| D3-SAOR Segment Address Offset Randomization | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-SCH Source Code Hardening | Harden | Source Code Hardening is the parent of the above. Explicitly out of scope per Framework section 6. |
| D3-SFCV Stack Frame Canary Validation | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-VI Variable Initialization | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
| D3-VTV Variable Type Validation | Harden | Memory-safety countermeasure. Secure SDLC, inherited. |
And Six Techniques With Nothing to Map To.
D3FEND catalogs countermeasures. These six are governance, doctrine and reporting acts, and an absent mapping is recorded so it stays distinguishable from a forgotten one.
Statutory Availability Floor — a legal constraint on defensive action, not a countermeasure.
Intelligence Requirement Revision — an analytic governance activity.
D3FEND™ and ATT&CK® are trademarks of The MITRE Corporation. This mapping is published by threatDefendr and is neither produced nor endorsed by MITRE.