Why You Keep Buying Tools That End Up on the Shelf

Security shelfware is well-documented at this point. A 2019 RSA Conference presentation by Diana Kelley and Ed Moyle surveyed security practitioners and found that IDS, IPS, vulnerability scanners, GRC tools, SIEM, FIM, and WAFs were the most common products gathering dust. The reasons respondents gave: not enough expertise to use them, inability to use or enable features, internal politics, and lack of staff.

Notice what’s not on that list. Price. The products weren’t unused because they were too expensive. They were unused because the organizations that bought them lacked the human capacity to operate them.

The CDM explains exactly why this happens, and it’s not complicated once you see it.

The buy-technology-for-everything instinct

Security budgets have historically been easier to spend on technology than on people. Headcount requires ongoing commitment: salary, benefits, training, retention. A tool purchase is a single procurement event that activates a budget line and produces something tangible. Leadership can see the tool. They can see the vendor’s logo on a slide. Headcount is harder to visualize and politically harder to justify in organizations where security competes with other functions for staff.

The result is that most security programs are over-tooled relative to their analyst capacity, and this imbalance is worst in the parts of the security program where people matter most.

Look at the CDM’s People/Tech continuum again. Technology dependency is high at Identify and Protect. That’s where automated tools do well: scanners, patch management, access control enforcement, firewall policy. These functions can be largely automated because the right answer to “what does a firewall rule look like” or “is this system missing a patch” doesn’t require much human judgment per event.

Move right to Detect, Respond, and Recover. Technology is still necessary but it’s not sufficient. A SIEM ingesting 100,000 events per day and producing 500 alerts doesn’t protect you if there are no analysts to work those alerts. A forensics platform doesn’t reconstruct an intrusion by itself. A backup system doesn’t execute recovery without someone making decisions about sequencing, priorities, and acceptable data loss.

The shelfware problem is concentrated in exactly those columns. SIEM, IDS/IPS, FIM: all Detect or Respond tools. All require sustained analyst investment to produce value. All ended up on the shelf when the analyst investment wasn’t made.

The 2019 data in context

The Kelley/Moyle survey identified the top “shelfware” products as:

IDS and IPS (most common), Vulnerability Scanners, GRC platforms, FIM, SIEM, IDAM/SSO, User Awareness training, AV, Forensics, Web filtering, WAF.

Map those to the CDM. IDS/IPS is Networks/Detect. Vulnerability scanners are Devices/Identify or Applications/Identify. GRC is a supporting capability spanning the matrix. FIM is Devices/Detect. SIEM is Detect, spanning multiple asset rows. IDAM is Devices and Users/Protect. User awareness is Users/Protect. Forensics is Devices or Networks/Respond.

The pattern: almost everything on the shelfware list lives in Detect or Respond, or in the high-people-dependency end of Protect. The tools that are genuinely automated and don’t need much analyst capacity (AV, web filtering, basic IAM) don’t end up on the shelf because they mostly run themselves once deployed.

This is not a coincidence. Organizations buy Detect and Respond tools because they’re the right tools for the threat landscape they’re facing, then fail to staff for them because the staffing cost didn’t come with the procurement decision.

The Tech:People ratio by function

Yu’s “Reloaded” presentation includes specific ratio guidance that’s worth taking seriously:

• Identify: approximately 10:1 Technology to People
• Protect: approximately 2:1 Technology to People
• Detect: approximately 1:1 Technology to People
• Respond: approximately 1:2 Technology to People (more people than technology)
• Recover: approximately 1:10 Technology to People (heavily people-driven)

These are rough ratios expressed in terms of resource investment, not headcount. A 10:1 ratio at Identify doesn’t mean ten scanners per analyst; it means your investment in technology at Identify should be roughly ten times your people investment, because the technology is doing most of the work.

At Detect, the ratio is 1:1. Equal investment. If you have $2M of SIEM and detection tooling at the Detect column, you should have roughly equivalent investment in the analysts who operate it. Most organizations have something closer to 5:1 or 10:1 technology to people at Detect, which is why the alerts aren’t getting worked.

At Recover, the ratio flips to 1:10. Recovery is almost entirely a human activity: decisions about prioritization, sequencing, communication, and what “normal” means after a significant incident. Technology assists but doesn’t drive. Organizations that have invested heavily in backup technology but have no documented recovery process and no trained team to execute it have the ratio exactly backwards.

You cannot automate Detect

This point deserves its own section because it runs against the current marketing wave.

The dominant narrative in security vendor marketing from roughly 2022 onward is AI-driven autonomous detection and response: systems that ingest telemetry, identify threats, and act on them without human involvement. Some of this is real. Some of it is not.

What’s real: machine learning improves detection accuracy, reduces false positive rates, and can surface patterns that human analysts would miss in high-volume environments. Automated response playbooks can execute containment actions faster than any human. Behavioral analytics can identify anomalies that rules-based systems miss.

What’s not real: the idea that you can fully automate Detect and eliminate the analyst requirement. Detection is not just pattern matching. It requires judgment about context: is this unusual process execution an attacker or a legitimate admin task? Is this data exfiltration or a scheduled backup to an unusual destination? Is this lateral movement or an authorized IT activity that looks like lateral movement? Those questions require someone who knows the environment, understands the business, and can make a call under ambiguity. No current system does that reliably without human oversight.

The vendors selling “autonomous SOC” capabilities are, at best, selling a capability that reduces analyst workload per alert. That’s valuable. It doesn’t eliminate the analyst requirement; it changes what analysts do. The ratio at Detect shifts somewhat toward technology, but it doesn’t approach the 10:1 you can achieve at Identify.

Organizations that buy into full automation at Detect and defund their analyst teams discover this the hard way, usually when an attacker does something slightly unusual that the model hasn’t been trained on.

Detecting by use case, not by telemetry

One of Yu’s more useful observations in the “Reloaded” presentation: mapping at Detect should be done by use case, not by telemetry source.

The distinction matters. A SIEM ingesting firewall logs, DNS logs, endpoint logs, and cloud API logs is a telemetry aggregator. What detection use cases does it serve? Lateral movement? Data exfiltration? Insider threat? Credential abuse? Each of those is a detection use case that requires specific data sources, specific detection logic, and specific analyst skills to investigate.

When you map by telemetry, you end up counting data sources: “we’re ingesting 15 log types, coverage is good.” When you map by use case, you end up with a different picture: “we have good coverage for network-based lateral movement, weak coverage for application-layer exfiltration, and no coverage for cloud API abuse.”

The shelfware problem often hides in this gap. The SIEM is ingesting logs (telemetry present, check) but the detection rules for the actual use cases the organization cares about haven’t been written, tuned, or operationalized. The tool exists. The capability doesn’t.

The CDM addresses this by placing detection in the context of specific asset rows. Detection in Networks/Detect has different use cases than detection in Applications/Detect. Building your detection coverage map by cell forces you to specify what use cases you’re covering in each cell, not just what telemetry you’re collecting.

The practical budget implication

The CDM makes a specific recommendation implicit: security budgets should be weighted toward technology at Identify and Protect, but as you move right toward Detect, Respond, and Recover, people investment should increase relative to technology investment.

In practice, this means a few things:

New technology purchases at Detect should come with a funded analyst or a clear plan for how the tool will be operated. If that plan doesn’t exist, the procurement decision should be deferred or the tool should be procured through a managed service that provides the people layer.

Existing tools in Detect and Respond that aren’t being used should be audited for the actual reason they’re unused. If the answer is “not enough expertise” or “not enough staff,” the fix is people, not a different tool.

Budget conversations with executive leadership about the Detect and Respond columns should be framed in terms of capability, not tool count. “We have a SIEM” is not the same as “we have functional threat detection.” The former is a procurement outcome. The latter is an operational state.

Technology vendors know that security buyers default to tool purchases. The CDM is useful here not because it stops you from buying tools, but because it makes visible what you’re actually buying and whether the human infrastructure to make it work exists.

Next: Article 5 — Who Owns What: Mapping Security Responsibilities Across Your Organization