Reading the Matrix · A-00
Why Your Security Program Needs a Map, Not More Maps
The security industry has a framework problem. Not a shortage of them. An excess.
NIST CSF, ISO 27001, CIS Controls, MITRE ATT&CK, the Kill Chain, OWASP, COBIT, SABSA, ITIL, SOC 2. Each one is defensible on its own terms. Each one also creates its own vocabulary, its own organizational logic, its own reporting surface. Stack a few of them and you spend more time reconciling frameworks than running a security program.
What most of them don’t give you is a clean answer to a basic operational question: do I have coverage across the things that matter, and am I spending my resources in the right places?
The Cyber Defense Matrix, created by Sounil Yu, answers that question. It doesn’t replace the other frameworks. It organizes them. Think of it as the coordinate system you put underneath everything else so the pieces relate to each other.
Yu first presented the CDM at RSA Conference in 2016. The 2019 “Reloaded” version added eight new use cases and deepened the analytical toolkit considerably. A book followed. The framework has since been adopted by security teams at major enterprises, integrated into vendor evaluation processes, and mapped against ATT&CK, the Kill Chain, and the CIS Controls.
This series works through the CDM methodically: what it is, how it works, and how to actually use it. The focus is on practical application. If a concept doesn’t connect to something you’d do differently on Monday morning, it’s not in here.
What the CDM actually is
Two dimensions, 25 cells.
The columns are the five operational functions from the NIST Cybersecurity Framework: Identify, Protect, Detect, Respond, Recover. The rows are five asset classes: Devices, Applications, Networks, Data, Users. Put them together and you get a 5x5 matrix where every cell represents a specific security problem space.
Endpoint vulnerability scanning sits in Devices/Identify. Firewall policy lives in Networks/Protect. SIEM alerting is Networks or Devices/Detect depending on the use case. Incident response is spread across Respond, shaped by which asset class was compromised.
Below the matrix sits a continuum that shows how your dependency on Technology versus People shifts as you move left to right across the functions. Technology dominates at Identify and Protect. People matter more at Detect, Respond, and Recover. Process stays roughly constant throughout. This continuum is one of the most useful diagnostic tools in the framework and one of the most commonly ignored.
That’s the basic structure. Simple enough to sketch on a whiteboard in two minutes, which is part of why it works.
What you can do with it
Yu’s presentations document 20+ use cases. The ones that show up repeatedly in real programs:
Vendor evaluation. Put any security product in one cell. If it won’t fit in one cell, that’s information. Either the vendor is genuinely a platform (rare) or they’re marketing across multiple problems they don’t actually solve equally well (common). The single-aisle test cuts through most vendor noise.
Portfolio gap analysis. Map your current tools and programs against the matrix. The white space shows you where you have no coverage. The crowded cells show you where you’ve over-invested or where you’re relying entirely on technology in functions that need people.
Organizational design. The matrix makes handoffs visible. Who owns Devices/Identify? Is it IT, security, or both with no clear RACI? The framework forces that conversation in a way that’s concrete rather than jurisdictional.
Resource allocation. If you’re spending 80% of your security budget on prevention (Identify and Protect columns) and almost nothing on Detect and Respond, the matrix shows you exactly why that’s a problem. The People/Tech continuum quantifies the imbalance.
Measurement. You can score each cell against existing checklists or control sets. The result is a heat map of your posture across the full attack surface, not a single compliance percentage that obscures everything.
Assessment planning. Vulnerability assessments, penetration testing, breach and attack simulation, and red team exercises map to different columns. Understanding which column you’re testing determines whether you’re getting signal or spending money on theater.
How this series is structured
The articles run in roughly the order you’d use the framework if you were picking it up for the first time, then applying it progressively.
Articles 1 and 2 cover the core structure: the matrix itself, the continuum, and the extended asset model that goes beyond enterprise-owned infrastructure.
Articles 3 through 6 work through the primary operational use cases: vendor mapping, the People/Tech split, organizational handoffs, and posture measurement.
Articles 7 through 10 go deeper on applied use cases: business constraints and design patterns, security assessment sequencing, Zero Trust architecture through a CDM lens, and how the framework connects to ATT&CK, the Kill Chain, and CIS Controls.
Article 11 looks at the APJ context specifically: how JFSA and FISC guidance maps to CDM cells, where regional operating environments create unusual coverage gaps, and what the framework looks like for teams without a dedicated security architecture function.
The companion piece covers CDM and post-quantum cryptography: where cryptographic risk lives in the matrix, how CBOM discovery maps to the Identify function, and what a PQC migration program looks like when you structure it through CDM.
A note on attribution
Everything in this series builds on Sounil Yu’s work. The CDM is his framework. The use cases documented here come from his RSA presentations, the CDM website at cyberdefensematrix.com, and his book. Where this series adds something, it’s in the application layer: how to use the framework in specific contexts, with specific tools, for specific decisions. Credit for the underlying model belongs to Yu.
His presentations are publicly available on SlideShare. The book is on Amazon and through Knostic Press. If you’re going to use the CDM seriously, read the source material.
Next: Article 1 — Five Functions, Five Assets, One Matrix: Understanding the CDM’s Basic Structure