Moneyball became famous for a simple but uncomfortable idea: the metrics everyone had agreed mattered for decades, batting average, RBIs, stolen bases, were poor predictors of what actually won games. The Oakland A's found undervalued players by measuring what actually correlated with runs scored, not what looked impressive on a highlight reel.
Cybersecurity has its own version of batting average. Number of alerts triaged, patches deployed per month, vulnerabilities closed, these are the metrics most security teams report up to leadership, and most of them correlate weakly, if at all, with whether the organization actually avoids a damaging breach. It's time security leaders start asking the same question Billy Beane asked: are we measuring what actually wins, or just what's easy to count.
The Vanity Metrics Problem in Security Reporting
Why Easy-to-Count Metrics Dominate Security Dashboards
Metrics like total alerts generated, number of phishing emails blocked, or patches applied per quarter persist because they are simple to pull from existing tools and easy to present as a number trending in the right direction. Leadership sees a chart going up or down and assumes progress is being made. The problem is that none of these numbers directly measure whether the organization's actual risk of a damaging incident has decreased.
A team that closes ten thousand low-severity vulnerabilities in a quarter while leaving three critical internet-facing exposures unpatched looks productive on paper and remains dangerously exposed in reality.
The Difference Between Activity Metrics and Outcome Metrics
Activity metrics measure how busy the security function has been. Outcome metrics measure whether that activity actually reduced the likelihood or impact of a real incident. Most security reporting skews heavily toward the former because outcome metrics are harder to define and require more rigorous data infrastructure to calculate reliably.
The Moneyball parallel here is direct: RBIs measure activity within a specific narrative of success. On-base percentage and slugging percentage, the metrics Beane's team prioritized, correlate far more directly with the actual outcome that matters, runs scored. Security needs its own shift toward metrics that correlate with the outcome that matters: reduced breach likelihood and reduced impact when incidents do occur.
Finding Security's Equivalent of On-Base Percentage
Mean Time to Detect and Mean Time to Contain
Rather than counting how many alerts were triaged, measuring how quickly genuine threats are detected and contained correlates far more directly with actual damage prevented. A ransomware operator given six hours of unimpeded lateral movement causes dramatically more damage than one detected and contained within twenty minutes, regardless of how many total alerts the SOC processed that day.
Calculating this accurately requires correlating detection timestamps against actual dwell time, which means instrumenting your SIEM or SOAR platform to track this specifically rather than relying on alert volume as a proxy:
python
import pandas as pd
def calculate_mttd_mttc(incidents_df):
incidents_df['detect_time'] = pd.to_datetime(incidents_df['detected_at']) - pd.to_datetime(incidents_df['occurred_at'])
incidents_df['contain_time'] = pd.to_datetime(incidents_df['contained_at']) - pd.to_datetime(incidents_df['detected_at'])
mttd = incidents_df['detect_time'].mean()
mttc = incidents_df['contain_time'].mean()
return mttd, mttc
df = pd.read_csv("incident_log.csv")
mttd, mttc = calculate_mttd_mttc(df)
print(f"Mean Time to Detect: {mttd}")
print(f"Mean Time to Contain: {mttc}")Tracking this trend over time, rather than as a single static number, shows whether detection engineering and hunting investments are actually improving the metric that correlates with real damage reduction.
Percentage of Critical Assets With Verified Detection Coverage
Rather than reporting total detection rules deployed, a far more meaningful metric is what percentage of your organization's actual critical assets, the systems that would cause real damage if compromised, have verified, tested detection coverage against the techniques most relevant to your threat profile.
This requires cross-referencing your asset criticality inventory against your detection rule mapping, similar to a coverage gap analysis:
python
def calculate_coverage_percentage(critical_assets, covered_assets):
coverage = len(set(critical_assets) & set(covered_assets)) / len(critical_assets)
return round(coverage * 100, 1)
critical = ["domain_controller_01", "finance_erp", "customer_db_prod", "payment_gateway"]
covered = ["domain_controller_01", "customer_db_prod"]
print(f"Critical Asset Detection Coverage: {calculate_coverage_percentage(critical, covered)}%")A security program covering fifty percent of low-value assets with detection but only twenty percent of genuinely critical assets is optimizing for the wrong denominator entirely, much like a baseball team optimizing for stolen bases while ignoring on-base percentage.
Exploitability-Weighted Vulnerability Exposure, Not Raw Vulnerability Count
Reporting a raw count of open vulnerabilities tells leadership almost nothing useful, since a thousand low-severity findings on isolated internal systems represent far less real risk than five critical findings on internet-facing infrastructure with known active exploitation.
A weighted exposure score that factors in exploitability, exposure, and asset criticality gives a far more accurate picture than raw counts:
python
def exploitability_weighted_score(vulnerabilities):
total_score = 0
for vuln in vulnerabilities:
exposure_multiplier = 3 if vuln['internet_facing'] else 1
exploit_multiplier = 2 if vuln['known_exploited'] else 1
total_score += vuln['cvss'] * exposure_multiplier * exploit_multiplier
return total_score
vulns = [
{"cvss": 9.8, "internet_facing": True, "known_exploited": True},
{"cvss": 4.2, "internet_facing": False, "known_exploited": False}
]
print(f"Weighted Exposure Score: {exploitability_weighted_score(vulns)}")This kind of weighted scoring, rather than a flat vulnerability count, is the security equivalent of slugging percentage: it accounts for actual impact rather than treating every occurrence as equally significant. Organizations looking to build out this kind of metrics framework from scratch can find structured approaches at www.sagefoxusa.com.
Finding Undervalued Investments in Security Programs
Identity Hygiene Is Security's Undervalued On-Base Percentage
Just as the A's found undervalued players who got on base without flashy stats, security programs often overlook identity hygiene, things like dormant account cleanup, service account credential rotation, and least-privilege enforcement, in favor of flashier investments like new detection platforms. Yet identity-based compromise remains one of the most common entry vectors across real incidents, meaning consistent identity hygiene work often delivers outsized risk reduction relative to its cost and visibility.
powershell
Get-ADServiceAccount -Filter * -Properties PasswordLastSet |
Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-365) } |
Select-Object Name, PasswordLastSetService accounts with credentials unchanged for over a year are common findings in this kind of audit, and remediating them is inexpensive relative to the risk reduction achieved, exactly the kind of undervalued investment the Moneyball framing is meant to surface.
Tabletop Exercises Deliver Outsized Readiness Value at Low Cost
Compared to large capital investments in new security tooling, structured tabletop exercises are inexpensive to run and consistently surface critical gaps in response coordination, communication chains, and decision-making authority that would otherwise only become apparent during an actual incident. This is a high on-base-percentage investment: low cost, consistently valuable, but often deprioritized in favor of more visible tooling purchases.
Backup Restoration Testing Outperforms Additional Prevention Spending
Security budgets frequently skew heavily toward prevention and detection tooling while backup restoration testing gets treated as an IT operations afterthought. Yet verified, tested restoration capability directly determines whether a ransomware incident becomes a contained inconvenience or a company-ending event, as demonstrated repeatedly in real incidents. This is precisely the kind of undervalued, unglamorous investment that a Moneyball-style analysis would flag as delivering disproportionate outcome impact relative to its cost and visibility.
Building a Metrics Framework That Actually Predicts Outcomes
Start by Defining What Winning Actually Means
Before selecting metrics, define explicitly what a successful security program looks like in outcome terms: reduced dwell time, contained blast radius when incidents occur, verified recovery capability, and demonstrable coverage of the techniques most relevant to your actual threat profile. Every metric tracked afterward should trace back to one of these outcomes, rather than existing simply because a tool makes it easy to report.
Audit Your Current Reporting for Vanity Metrics
Take your current board or leadership reporting deck and honestly assess each metric: does this number, moving up or down, actually tell us whether we are more or less likely to suffer a damaging incident. Metrics that fail this test should either be reframed into an outcome-oriented version or dropped from leadership reporting entirely, even if they remain useful for internal operational tracking.
Reallocate Investment Based on Correlation With Outcomes, Not Visibility
Just as the Moneyball approach meant benching statistically favored but overvalued players in favor of undervalued ones with better underlying metrics, security leaders should be willing to reallocate budget away from highly visible tooling investments toward less glamorous work, identity hygiene, backup testing, tabletop exercises, that demonstrably correlates better with actual outcome improvement. This is often a harder internal sell, since it involves deprioritizing visible, easy-to-justify purchases in favor of less visible operational discipline, but the data consistently supports the reallocation. Sagefox Cybersecurity helps security leaders build this kind of outcome-correlated investment case for their own leadership teams, with frameworks available at www.sagefoxusa.com.
Key Takeaways
Cybersecurity has spent years measuring its version of batting average: alert counts, patch numbers, vulnerability totals, because those numbers are easy to pull and easy to present. Real risk reduction comes from a different set of metrics entirely, ones that correlate directly with dwell time, blast radius, and recovery capability, much like on-base percentage correlated with actual runs scored in a way traditional baseball statistics never fully captured.
The security programs that will outperform their peers over the next several years are not necessarily the ones with the biggest tooling budgets. They are the ones willing to question which metrics actually predict outcomes, and reallocate investment toward the undervalued, unglamorous work that the data shows actually moves the needle. If you want help building an outcome-focused metrics framework for your own security program, Sagefox Cybersecurity's team can help at www.sagefoxusa.com.
