Using the CDM to Cut Through Vendor Noise

RSA Conference 2024 had roughly 600 exhibitors on the expo floor. That number has been roughly stable for a few years, bouncing between 500 and 700 depending on the year. Every one of those vendors had a booth, a pitch, a problem they claimed to solve, and a category name that may or may not have existed five years ago.

Walking that floor without a framework is genuinely disorienting. “AI-native autonomous threat detection with behavioral analytics and XDR integration” describes something. It’s not clear what. The vendor next to them says almost the same thing with different nouns.

The CDM’s original use case, the one that Yu built it for, was exactly this problem: how do you organize the security vendor landscape into something navigable? The answer is the single-aisle test.

The single-aisle test

Every security vendor belongs in one cell. Not because every vendor is a point product (some aren’t), but because every vendor has a primary function against a primary asset class. That’s the cell they belong in.

The test: where does this product spend most of its effort? What asset class is it primarily protecting, monitoring, or responding to? What operational function does it primarily serve?

A vulnerability scanner is Devices/Identify (or Applications/Identify if it’s a DAST tool). A next-generation firewall is Networks/Protect. An EDR platform is Devices/Detect with some Devices/Respond capability. A SIEM is an interesting case: it’s primarily a Detect tool, but it aggregates telemetry from across all asset rows. Place it at Networks/Detect or Devices/Detect depending on where its primary detection value lives in your environment.

When you can’t place a vendor in one cell without serious effort, that’s diagnostic. It usually means one of three things:

The vendor is a genuine platform with multiple primary capabilities. Palo Alto Networks, for example, has built a portfolio that genuinely spans multiple cells: network security, endpoint, cloud, identity. That’s not marketing; it’s the result of 15+ acquisitions. Platforms like this exist and they’re legitimate. They’re also harder to evaluate because you need to assess each capability set independently rather than treating the platform as a unit.

The vendor is marketing across multiple cells but primarily delivers in one. This is more common. A company that calls itself an “XDR platform” might primarily be an EDR vendor that ingests network logs. Put them in Devices/Detect, evaluate them there, and be clear-eyed about what the “X” in XDR is actually delivering.

The vendor’s product genuinely doesn’t fit the matrix cleanly because it’s a supporting capability rather than a primary security function. GRC platforms, security awareness training programs, and risk management tools are real security investments that span the matrix in a supporting role rather than residing in a single cell. This is fine. The CDM distinguishes between primary and supporting capabilities, and we’ll cover that distinction below.

Primary versus supporting capabilities

Yu makes a distinction in his presentations that doesn’t get enough attention: primary capabilities versus supporting capabilities.

A primary capability directly delivers a security function against an asset class. An EDR tool detecting malicious process execution on an endpoint is a primary capability in Devices/Detect.

A supporting capability enables or improves primary capabilities but doesn’t deliver them directly. Threat intelligence feeds are a supporting capability: they inform detection rules, enrich alerts, and improve analyst context, but the detection event itself comes from somewhere else. Orchestration platforms are supporting capabilities. Security awareness training is a supporting capability for Users/Protect; the protection comes from changed human behavior, not from the training platform itself.

This distinction matters for portfolio management. When you’re looking at your coverage map and you see a crowded cell, check whether what’s in that cell is primary or supporting capability. It’s common to find cells where there are three supporting capabilities and no primary capability. You’ve invested in enrichment and automation for a detection function you don’t actually have.

It also matters for vendor evaluation. A vendor whose product is primarily a supporting capability but is selling in a primary-capability budget cycle is a mismatch. Not necessarily a bad product, but you should be clear about what you’re buying and where the actual security function comes from.

Building a vendor map

The practical exercise is simple and worth doing with your team rather than solo. It produces more honest results when more people have to agree on cell placement.

List your current security tools and programs. For each one, answer two questions: what asset class does it primarily address? What operational function does it primarily serve? Put it in the cell.

When you’re done, step back and look at the distribution.

Crowded cells usually indicate one of: a real problem that justified multiple investments (fine), a history of buying competing products without rationalizing the portfolio (common after acquisitions or leadership changes), or heavy investment in a compliance-driven control area regardless of whether it’s actually your highest risk.

Empty cells are more interesting. Not every cell needs a tool; some cells are genuinely lower priority for your environment. But empty cells in your highest-risk asset rows, or empty cells in Detect and Respond across the board, are worth examining carefully. A blank in Networks/Detect in an organization running a large on-premises environment is a real gap. A blank in Data/Recover is a question about whether your backup and restoration capability has actually been tested.

The map also shows you where you’re relying entirely on technology with no people component, and where you have people but no tooling. The continuum from Article 1 applies here: Detect and Respond cells that are fully automated (no analyst capacity) are underperforming regardless of how good the tools are.

The conference floor as a CDM exercise

Yu’s original suggestion was to use the CDM at RSA’s expo hall: when you walk up to a vendor booth, ask them where they fit in the matrix. One cell. If they can’t answer or if they try to claim five cells, that’s useful information.

This works because it forces the conversation away from the vendor’s preferred framing (“we’re an AI-native platform for comprehensive cyber resilience”) and toward something concrete (“we’re primarily a DAST tool with some API security monitoring”). The former is marketing. The latter is something you can evaluate.

It also works as a prioritization filter before you walk the floor. If you know you have no coverage in Applications/Detect and reasonable coverage everywhere else, you can spend your limited time with vendors who actually live in that cell. You skip the endpoint vendors even if they have an impressive AI story, because that’s not where your gap is.

The same logic applies to inbound vendor outreach. Most enterprise security organizations receive dozens of vendor emails and calls per week. The first filter should be: what cell does this vendor live in? If it’s a cell where you’re already well-covered, the conversation is probably not worth the time right now. If it’s a cell where you have a gap, it might be.

Comparing point products and platforms

The point-product-versus-platform question has been a recurring debate in security for at least 15 years. The CDM offers a reasonably clean framework for thinking about it that gets past the vendor-influenced framing.

A point product delivers a primary capability in one or two cells very well. It’s usually best-in-class in its cell, requires integration work to connect to the rest of your stack, and creates operational overhead if you’re managing many of them.

A platform delivers primary capabilities across multiple cells with native integration between them. The integration value is real. The risk is that no individual capability in a platform is as strong as the best point product in that cell, and the platform creates vendor concentration risk: one renewal negotiation, one acquisition, one product decision at the vendor affects your coverage across multiple cells simultaneously.

Neither is categorically better. The CDM helps you make the decision based on your actual situation: where do you need best-in-class capability (a cell where your risk is highest), and where is good-enough coverage with strong integration preferable (cells where the primary value comes from correlation and workflow, not raw detection fidelity)?

Security operations centers that have tried to run 40 point products know the integration problem intimately. Organizations that went all-in on a single platform vendor know the renewal negotiation problem intimately. The CDM doesn’t resolve the trade-off, but it gives you a way to have the conversation with specifics rather than marketing abstractions.

A note on new categories

The security industry generates new category names at a rate that outpaces any reasonable person’s ability to track them. XDR, CNAPP, ITDR, DSPM, ASPM, CIEM. Each of these describes something real. Each of them is also a marketing construct designed to create a new budget category.

The CDM cuts through this cleanly. Whatever the category name, the question is the same: what asset class, what function, primary or supporting? DSPM (Data Security Posture Management) maps to Data/Identify and Data/Protect. ITDR (Identity Threat Detection and Response) maps to Users/Detect and Users/Respond. CIEM (Cloud Infrastructure Entitlements Management) maps to Devices/Identify and Devices/Protect in a cloud context, or Networks/Identify depending on how you’ve chosen to model cloud resources.

You don’t need to learn every new acronym the industry produces. You need to know which cell it lives in and whether you have a gap there.

Next: Article 4 — Why You Keep Buying Tools That End Up on the Shelf