How CDM Connects to the Frameworks You're Already Using

Most security organizations are already using at least one other framework. MITRE ATT&CK for threat-informed defense. The Cyber Kill Chain for describing attack progression. CIS Controls for control implementation prioritization. NIST CSF as the governance spine.

The CDM doesn’t ask you to replace any of these. It sits above them as an organizing layer. Once you understand how each framework maps to the CDM, you can use all of them together more effectively: each one doing what it’s actually good at, with the CDM providing the coordinate system that connects them.

The Cyber Kill Chain

Lockheed Martin’s Kill Chain (2011) describes seven stages of a targeted intrusion: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, Actions on Objectives. The model is attacker-centric: it describes what adversaries do, in sequence, to achieve their goals.

The CDM is defender-centric: it describes what you do to prevent, detect, and respond to what adversaries do. Mapping the two together tells you which CDM cells are relevant at each stage of an attack.

Reconnaissance maps primarily to Identify functions. Attackers are inventorying your external attack surface: what systems are exposed, what software versions are running, what email addresses are discoverable, what credentials are in data breaches. Your Identify column activities (attack surface measurement, vulnerability scanning, data exposure monitoring) are directly responsive to what attackers do at this stage.

Weaponization and Delivery map to Protect functions, particularly in the Devices and Users rows. Email security, web proxy filtering, application sandboxing, and user awareness training are the primary defensive responses to the delivery stage of an attack. The weapon is created externally; delivery is where your controls first have the opportunity to intervene.

Exploitation maps to Protect and Detect. Protective controls attempt to prevent successful exploitation (patching, WAF, RASP, hardening). Detection controls attempt to identify exploitation when it occurs (endpoint behavioral detection, application anomaly detection, exploit telemetry).

Installation maps to Devices/Detect and Devices/Respond. Persistence mechanisms (scheduled tasks, registry modifications, service installation, rootkits) are the targets for endpoint detection at this stage. File integrity monitoring, process behavior analysis, and endpoint detection tools are the relevant CDM cell occupants.

Command and Control maps to Networks/Detect and Networks/Respond. C2 traffic, DNS beaconing, HTTPS tunneling to external infrastructure: these are network-layer detection problems. Network traffic analysis, DNS monitoring, and proxy log analysis live in Networks/Detect.

Actions on Objectives maps across the Data row (for data exfiltration goals), the Applications row (for application-layer manipulation or sabotage), and all of Respond and Recover depending on what the attacker’s ultimate goal is.

The Kill Chain mapping is useful for tabletop exercises: walk through each stage and ask which CDM cells are engaged at that stage, and what coverage you have in those cells. Gaps in Kill Chain stage coverage are gaps in specific CDM cells.

MITRE ATT&CK

ATT&CK is more granular than the Kill Chain and considerably more useful for detection engineering. Where the Kill Chain describes stages, ATT&CK catalogs specific techniques and sub-techniques adversaries use: credential dumping, living-off-the-land binaries, DNS-based C2, specific persistence mechanisms. As of ATT&CK v14 (October 2023), the Enterprise matrix contains 14 tactics and 196 techniques with hundreds of sub-techniques.

ATT&CK maps to the CDM in three distinct ways corresponding to three different uses of the framework.

ATT&CK Mitigations map to the Protect column. ATT&CK’s mitigation objects (M-prefixed IDs) describe defensive measures that prevent or limit the effectiveness of specific techniques. These map directly to CDM Protect cells. M1017 (User Training) is Users/Protect. M1041 (Encrypt Sensitive Information) is Data/Protect. M1031 (Network Intrusion Prevention) is Networks/Protect. When you’re building out the Protect column of your CDM, ATT&CK mitigations give you a technique-specific implementation guide for each cell.

ATT&CK Data Sources map to the Detect column. Each ATT&CK technique specifies the data sources that produce telemetry relevant for detecting that technique. Process creation logs, network traffic, file system modifications, authentication logs, DNS queries. These data sources map to CDM Detect cells by asset class: process creation logs are Devices/Detect telemetry, network traffic is Networks/Detect telemetry, authentication logs span Users/Detect and Networks/Detect.

This mapping is useful for detection engineering prioritization. If you want to detect a specific set of ATT&CK techniques relevant to your threat model, the data source mapping tells you which CDM Detect cells need to be producing telemetry, and the CDM coverage map tells you which of those cells you currently have covered.

The MITRE Cyber Analytics Repository (CAR) maps to Detect and Respond. CAR provides specific detection analytics and pseudocode for detecting ATT&CK techniques. These are Detect-column resources: they’re what your analysts implement in the SIEM or analytics platform to generate alerts for specific behaviors. The CDM cell they map to depends on the asset class of the technique being detected.

The combined ATT&CK/CDM view looks like this: pick the ATT&CK techniques most relevant to your threat model (based on threat intelligence about who targets your industry and sector). Map each technique to a CDM cell using the tactic-to-column and technique-to-row logic. Check your CDM coverage map against that set of cells. Where you have coverage gaps that overlap with high-priority techniques, that’s your detection engineering backlog.

This is threat-informed defense in a form that’s actually actionable: specific techniques, specific cells, specific gaps.

CIS Controls v8

The CIS Controls are the most operationally specific of the major control frameworks. The 18 controls and 153 safeguards describe concrete implementation steps rather than principles or outcomes. That specificity makes them a good fit for the CDM scorecard approach from Article 6.

Yu’s “Reloaded” presentation includes a detailed mapping of CIS Controls (at the time, CIS Top 20) to CDM cells. The v8 mapping is broadly similar with some reorganization. A summary of how the controls distribute:

Devices row, Identify: Controls 1 (Inventory and Control of Enterprise Assets) and 2 (Inventory and Control of Software Assets) are almost entirely Devices/Identify and Applications/Identify. These two controls alone contain dozens of safeguards and represent the foundation of CDM Identify coverage. They’re also the controls most commonly implemented at low fidelity: tools exist but data quality is poor.

Devices and Networks rows, Protect: Controls 4 (Secure Configuration), 5 (Account Management), 6 (Access Control Management), 12 (Network Infrastructure Management), and 13 (Network Monitoring and Defense, partially) occupy the Devices and Networks Protect cells heavily. These are the controls driving most enterprise security spending.

All rows, Detect: Control 8 (Audit Log Management) and Control 10 (Malware Defenses) generate detection telemetry across multiple rows. Control 13 (Network Monitoring and Defense) is primarily Networks/Detect. Control 17 (Incident Response Management) bridges Detect and Respond.

All rows, Respond and Recover: Controls 17 (Incident Response Management) and 11 (Data Recovery) are the primary Respond and Recover controls in the CIS framework. Notably, these two controls together represent a small fraction of the 153 total safeguards — which reflects the historical bias of the CIS Controls toward preventive controls and away from detection and response maturity.

This distribution reveals a structural characteristic of CIS Controls: they are weighted toward Identify and Protect, particularly for Devices and Networks. The Users row is covered through Controls 5, 6, and 14 (Security Awareness and Skills Training) but less comprehensively than the technical asset rows. The Data row gets coverage through Controls 3 (Data Protection) and 11 but is thinner than the network and endpoint rows.

Using the CDM to visualize CIS Controls coverage isn’t a criticism of the framework — it’s showing you how the framework is balanced and where it leaves gaps that you need to fill from other sources.

NIST CSF 2.0

NIST released CSF 2.0 in February 2024, adding a sixth function (Govern) to the original five. The Govern function covers organizational context, risk management strategy, cybersecurity supply chain risk management, and oversight.

The Govern function doesn’t map into the standard 5x5 CDM matrix because it sits above the operational functions rather than alongside them. It’s closer to the governance layer that Yu describes as surrounding the CDM rather than existing within it.

The original five functions (Identify, Protect, Detect, Respond, Recover) are the CDM columns. The mapping is direct because NIST CSF explicitly provided the column structure for the CDM. Using CSF 2.0 as a reporting framework while using CDM as the operational model is clean: every CDM cell maps to a CSF function, and CSF Govern provides the organizational context that determines how you prioritize across cells.

Using multiple frameworks together

The practical conclusion from all of this mapping work: each framework is good at one thing.

The Kill Chain is good for explaining attack progression to leadership and for structuring tabletop exercises. It’s too coarse-grained for detection engineering.

ATT&CK is good for detection engineering, threat intelligence operationalization, and red team planning. It’s too detailed to use as an organizational or program planning framework without an organizing layer.

CIS Controls are good for implementation specificity: they tell you what to actually do in concrete terms. They’re weighted toward Protect and weak on Detect and Respond.

NIST CSF is good for governance communication, regulatory alignment, and executive reporting. It’s too abstract for operational security decisions.

The CDM is the organizing layer. Put it underneath all of them and they stop competing for primacy. ATT&CK techniques map to CDM cells for detection prioritization. CIS Controls safeguards map to CDM cells for implementation planning. Kill Chain stages map to CDM columns for tabletop structure. NIST CSF functions are the CDM columns.

Run your program against the CDM. Report to the board using NIST CSF language. Prioritize your detection engineering using ATT&CK. Implement specific controls using CIS guidance. None of that requires choosing one framework over the others.

Next: Article 11 — Reading the Matrix in the APJ Context