Five Functions, Five Assets, One Matrix

Most security frameworks start from the attacker’s perspective. The Kill Chain tracks the stages of an intrusion. ATT&CK catalogs the specific techniques adversaries use. Both are useful, but they’re attacker-centric. They tell you what attackers do. They don’t directly tell you how to organize your defense.

The Cyber Defense Matrix starts from the defender’s perspective. It asks: what are you trying to protect, and what does protecting it actually require? The structure follows from those questions.

The two dimensions

Dimension one: what you’re protecting (the rows)

Five asset classes cover almost everything a security program cares about:

Devices are the physical and virtual compute endpoints: workstations, servers, phones, tablets, IoT devices, storage, network infrastructure. Anything with a CPU that your organization touches.

Applications are the software and interactions running on those devices: the code, the APIs, the authentication flows, the business logic. The line between Devices and Applications is sometimes blurry (is a containerized workload a device or an app?), but the CDM handles that gracefully: place it where the primary security problem lives.

Networks are the connections and traffic between devices and apps: the physical and logical paths, the protocols, the flows. This includes internal network segments, cloud connectivity, and remote access infrastructure.

Data is the information at rest, in transit, and in use across all of the above. Not the systems that hold it — the data itself. This distinction matters because data has a security lifecycle that cuts across devices, apps, and networks simultaneously.

Users are the people operating the systems. Not the accounts or the credentials (those are part of Devices or Applications depending on where they live), but the humans: their behaviors, their training, their susceptibility to manipulation.

Five rows. Every security problem you have fits into one of them.

Dimension two: what you’re doing about it (the columns)

The five operational functions come directly from the NIST Cybersecurity Framework, published in 2014 and revised in 2024. The CDM borrows the structure but uses it differently.

Identify covers knowing what you have and understanding the risk: asset inventory, vulnerability assessment, attack surface measurement, threat modeling, risk prioritization. You can’t protect something you don’t know exists.

Protect covers preventing or limiting impact: patching, hardening, access control, segmentation, encryption. The defensive measures you put in place before an event occurs.

Detect covers discovering that something is happening: event logging, anomaly detection, threat hunting, security analytics. The gap between intrusion and detection is one of the most consequential numbers in security; the 2024 IBM Cost of a Data Breach report put the global mean time to identify a breach at 194 days.

Respond covers acting on confirmed events: eradication, forensic reconstruction, damage assessment, coordination. What you do after detection, before you’re back to normal.

Recover covers returning to normal operations: service restoration, resilience testing, lessons-learned documentation. The function that most organizations under-invest in until after a major incident.

The 25 cells

Put the two dimensions together and you get 25 cells. Each cell represents a distinct security problem space with its own tooling, its own staffing requirements, its own maturity model.

A few examples to make this concrete:

Devices/Identify: Asset inventory, configuration management databases, vulnerability scanners. The question this cell answers: do I know what devices I have and what’s wrong with them?

Applications/Protect: Secure coding practices, SAST/DAST tooling, WAF, RASP, software composition analysis. The question: am I preventing vulnerabilities from reaching production and blocking exploitation when they do?

Networks/Detect: Netflow analysis, IDS/IPS, DNS logging, firewall log review. The question: am I seeing malicious traffic when it crosses my network?

Data/Respond: Forensic data recovery, breach scope analysis, data classification review post-incident. The question: when something happens to my data, can I figure out what was taken and how?

Users/Recover: Post-incident training updates, insider threat review, HR coordination on affected accounts. The question: have I addressed the human factors that contributed to or were affected by the incident?

Every vendor you buy, every analyst you hire, every process you build maps somewhere in this grid. If it doesn’t map cleanly, that’s worth examining.

The continuum under the matrix

This is the part most people skip past and shouldn’t.

Below the 5x5 grid, the CDM shows a continuum that describes how the dependency on Technology, People, and Process shifts as you move from left to right across the five functions.

At Identify: Technology dependency is highest. Automated scanners, CMDBs, vulnerability databases. The people-intensive parts (threat modeling, risk prioritization) exist, but technology does most of the heavy lifting.

At Protect: Still heavily technology-dependent. Firewalls, patch management, encryption, access control systems. Humans design the policies but technology enforces them.

At Detect: The balance shifts. You need technology (SIEM, EDR, analytics platforms) but you can’t automate your way through this column. Threat hunting requires analysts. Alert triage requires judgment. Detection rules require tuning by humans who understand the environment. An equal mix of people and technology is roughly right here. Programs that try to automate Detect entirely end up with either alert floods they can’t process or gaps they can’t see.

At Respond: People-dependent. Incident response is a human activity. Technology assists with forensics and orchestration, but decisions about scope, containment strategy, external communication, and recovery sequencing require people with judgment and authority.

At Recover: Most people-dependent of all. Business continuity, executive communication, regulatory notification, rebuilding trust with affected parties. Technology gets the systems back online; people figure out what “back to normal” means.

Process runs at a roughly constant level throughout all five functions. Documented procedures matter everywhere, which is why organizations that treat process as a compliance checkbox rather than an operational asset tend to struggle uniformly across the matrix.

The practical implication of this continuum: if your security budget is heavily weighted toward technology purchases, and most of it is in the Identify and Protect columns, that’s defensible. If you’re also spending heavily on technology in the Detect and Respond columns and assuming it covers the people requirement, you have a mismatch. You’ve bought tools that need analysts to operate them and you haven’t funded the analysts.

This is the single most common structural failure in enterprise security programs. The continuum makes it visible.

Where the CDM doesn’t map cleanly

No framework covers everything perfectly. A few areas where the CDM requires some judgment:

Cloud-native architectures compress or eliminate parts of the Networks row. In a serverless environment, you don’t control the underlying compute or network infrastructure in the same way. The Devices row gets thinner too. The CDM still applies, but your coverage map looks different from a traditional on-premises estate.

Governance and compliance activities sit awkwardly across the matrix. Risk management, audit, regulatory reporting, and policy management are real security program functions but they don’t fit neatly into individual cells. Yu addresses this in his later work, mapping governance processes above or alongside the matrix rather than inside it.

Third-party and supply chain risk is partially addressed by the multi-ring model covered in Article 2, but the CDM’s native structure treats your own assets as the primary subject. Third-party risk management requires extending the framework deliberately.

Identity, specifically modern identity infrastructure in a hybrid or multi-cloud environment, spans multiple rows. An identity platform touches Devices (endpoint authentication), Applications (SSO, API authorization), Networks (network access control), Data (authorization to data stores), and Users (the account lifecycle). IAM platforms resist single-cell placement, which is fine: the CDM can be used to evaluate each capability an IAM platform provides separately.

These aren’t flaws in the framework. They’re edge cases that require you to think, which is the point. A model that answers every question without judgment isn’t a model; it’s a checklist.

Using the matrix right now

You don’t need a six-month implementation project to get value from the CDM.

Take your current security tool inventory. For each tool, put it in one cell: the cell that represents its primary function against its primary asset class. Not the cell where the vendor claims it provides value, the cell where it actually does the most work in your environment.

When you’re done, look at what you have. Where are the clusters? Where are the gaps? Are there cells where you have four tools but no analyst to operate them? Are there cells where you have an analyst but no tooling?

That exercise takes a few hours and will tell you more about your program’s actual shape than most maturity assessments.

Next: Article 2 — You Don’t Just Defend Your Assets: The Four-Ring Model