You Deployed 350 Detection Rules. Only 50 Fire Regularly. Are the Other 300 Working?

Open your SIEM right now and count how many detection rules have fired in the last 90 days. Not how many you have deployed. How many have actually produced an alert.

If you're running a mature detection library (200, 350, maybe 500 rules) the number that fires regularly is almost certainly under 20% of the total. The rest are silent. They've been sitting in your analytics engine for months, consuming compute cycles, and you have no evidence they work.

This is not a hypothetical. During purple team engagements, detection rules fail to fire on techniques they were explicitly written to catch. Rules that passed review, worked when deployed, and that the team had full confidence in. The telemetry was there. The events were being generated. But the detection logic was no longer matching because something underneath it had changed.

The dangerous part: nobody noticed. False positives are loud. Analysts complain about them, leadership hears about alert fatigue, and resources get allocated to tuning. False negatives are completely silent. No one submits a ticket that says "the credential dump that just happened didn't trigger an alert." You find out about false negatives during an incident review, or during a purple team exercise when someone asks why the rule didn't fire and the answer is that it hasn't been firing for weeks.

Three reasons a rule goes silent

A rule that hasn't fired in 90 days falls into exactly one of three categories. Only one of them is acceptable.

The attack hasn't happened. Your T1003.006 DCSync detection hasn't fired because nobody has attempted DCSync against your domain. This is fine. The rule is working. It's waiting. This is the only good reason for silence, and it's the one every team assumes applies to all their silent rules.

The telemetry pipeline broke. A data connector went stale. A log source changed its schema. Someone updated the Windows audit policy and stopped collecting Event ID 4662. The rule is correctly written, but the data it depends on is no longer arriving. The rule can't fire on events that don't exist. This happens more often than most teams realise. A Graylog study found that five minutes of silence from a high-volume source like a firewall or domain controller can indicate a collection failure that silently invalidates every rule that depends on that source.

The rule logic is wrong. The query references a field name that got renamed in a platform update. Someone tuned the rule to reduce false positives and accidentally scoped out the real attack path. The threshold is set to 50 but the actual attack generates 12 events. The rule was written against one version of the attacker tooling and the current version produces different telemetry. CardinalOps documented this pattern across hundreds of SOCs: rules that looked thorough on paper had silent gaps in practice, not because the teams lacked skill, but because the environment changed and no one re-validated.

The problem is that from your SIEM dashboard, categories two and three look identical to category one. A rule that's waiting for an attack it will catch and a rule that's broken and will never fire again produce the same output: zero alerts.

Find your silent rules right now

This takes 5 minutes. Run these two queries against your SIEM and you'll know exactly where you stand.

The first query classifies every rule that has fired at least once. It tells you which rules are active, which are low-volume, and which fired months ago but have gone dormant.

// Classify detection rules by firing pattern over 90 days
// Rules with zero fires won't appear here. Cross-reference against
// your analytics rule list to find the truly silent ones.
let lookback = 90d;
SecurityAlert
| where TimeGenerated > ago(lookback)
| summarize
    AlertCount = count(),
    LastFired = max(TimeGenerated),
    DaysSinceLastFire = datetime_diff('day', now(), max(TimeGenerated))
    by AlertName = DisplayName
| extend Category = case(
    AlertCount between (1 .. 5) and DaysSinceLastFire > 60, "Dormant",
    AlertCount between (1 .. 5), "Low-volume",
    AlertCount > 5 and DaysSinceLastFire > 60, "Dormant",
    "Active")
| project AlertName, Category, AlertCount, LastFired, DaysSinceLastFire
| order by Category asc, AlertCount asc

The critical insight: rules that have never fired in 90 days don't appear in this output at all. You need to compare the list of rules that produced alerts against your full analytics rule list. In Sentinel, check Analytics > Active rules and compare against the AlertName column above. Every active rule that doesn't appear in your results is a truly silent rule. That's where your blind spots live.

| rest /services/saved/searches splunk_server=local
    search="alert.track=1"
| rename title as RuleName
| join type=left RuleName
    [search index=notable earliest=-90d
    | stats count as AlertCount, max(_time) as LastFired by search_name
    | rename search_name as RuleName]
| eval Category=case(
    isnull(AlertCount) OR AlertCount==0, "Silent",
    AlertCount<=5, "Low-volume",
    AlertCount>5, "Active")
| table RuleName, Category, AlertCount, LastFired
| sort Category, AlertCount

And the same concept as a Sigma meta-rule for platforms that track rule execution metadata:

title: Detection Rule Health Audit
description: |
  Identify rules with zero fires in 90 days.
  Not a detection rule. An operational audit query.
  Run monthly against your SIEM's rule execution metadata.
  Sigma does not define this natively; each platform
  tracks rule execution differently. The KQL and SPL
  queries above are the platform-specific implementations.

When you run this, expect the results to be uncomfortable. Most teams discover that 40-60% of their rules have either never fired or haven't fired in months.

Triage the list: not every silent rule is a problem

Your silent rule list will be long. Don't try to investigate all of them. Triage by asking two questions about each one.

Does this rule detect a technique that's relevant to your environment? A rule for T1053.007 (Container Orchestration Job) is correctly silent if you don't run Kubernetes. A rule for T1110.003 (Password Spraying) should not be silent if you run Entra ID. Someone is spraying you, guaranteed. Filter your silent list to techniques that apply to your technology stack and threat profile. The rest can wait.

Is the data source still feeding the SIEM? For every relevant silent rule, check whether the table or index it queries actually has recent data. This is the fastest way to separate "rule is waiting" from "rule is starving."

// Check when each critical table last received data
// Any table older than 60 minutes needs investigation
union
    (SigninLogs | summarize Last = max(TimeGenerated) | extend Table = "SigninLogs"),
    (DeviceProcessEvents | summarize Last = max(Timestamp) | extend Table = "DeviceProcessEvents"),
    (SecurityEvent | summarize Last = max(TimeGenerated) | extend Table = "SecurityEvent"),
    (EmailEvents | summarize Last = max(Timestamp) | extend Table = "EmailEvents"),
    (Syslog | summarize Last = max(TimeGenerated) | extend Table = "Syslog")
| project Table, Last, AgeMinutes = datetime_diff('minute', now(), Last)
| order by AgeMinutes desc

If the data source is stale, you've found a pipeline problem, not a rule problem. Fix the connector and the rules start working again. If the data source is healthy but the rule is still silent, you're in one of two places: the attack hasn't happened, or the rule logic is wrong. There's only one way to know which.

The only way to know: run the attack

You can audit rule logic by reading the query. You can check data sources by running freshness queries. But neither of these proves the rule actually fires when the attack happens. The only way to prove a detection works is to execute the technique it claims to detect and see whether an alert appears.

This is purple teaming. Pick a silent rule that detects a technique relevant to your environment. Run the corresponding Atomic Red Team test in your lab. Wait five minutes. Check your SIEM.

Here's what that looks like for T1003.001 (LSASS credential dumping), one of the highest-impact techniques that many rules claim to detect:

# Install Atomic Red Team (one-time setup)
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
Install-AtomicRedTeam -getAtomics

# Run the LSASS memory dump test
# This uses procdump to access lsass.exe — the exact technique
# your LSASS detection rule should catch
Invoke-AtomicTest T1003.001 -TestNumbers 1

# Wait 5 minutes for SIEM ingestion
# Then check: did your detection rule fire?

Three things can happen. The rule fires and you've validated it. Mark it as validated, record the date, move on. The rule doesn't fire but the telemetry is visible in raw logs. Your data pipeline is healthy, but the rule logic is wrong. Fix the query, re-test, validate. Or the telemetry isn't visible at all. Your detection has a data source gap. The rule is correct, but the events it needs are never collected. This is the worst outcome because it means the rule has never been capable of firing in your environment.

Build the habit: five rules, one hour, once a month

You don't need a formal purple team program to start validating. You need one hour per month and a prioritised list.

Week 1: Run the audit query. Get your silent rule list. Filter to techniques relevant to your stack. Rank by impact. Credential access, lateral movement, and persistence techniques first.

Week 2: Pick five. Choose the five highest-impact silent rules. For each one, check the data source. If the data source is stale, fix it. If it's healthy, schedule the validation.

Week 3: Run the attacks. Execute the corresponding Atomic Red Team test for each rule. Record whether the rule fired, whether telemetry was visible, and what the gap was.

Week 4: Fix what's broken. For rules that didn't fire despite healthy telemetry, fix the query logic. For data source gaps, fix the collection. Re-test everything you fixed.

Five rules per month means 60 validated rules per year. In 12 months, you'll have evidence-based confidence in your detection library instead of assumptions. You'll also have a documented trail of what you tested, what you found, and what you fixed. That trail is the difference between telling your CISO "our detections are working" and proving it.

What to do this week

1. Run the silent rule audit query against your SIEM. Get the number. How many of your rules have zero fires in 90 days?
2. Filter the list to techniques relevant to your environment. Ignore rules for platforms you don't run.
3. Check data source freshness for the top 10 silent rules. Is the data actually arriving?
4. Pick one high-impact silent rule, something in credential access or lateral movement. Run the Atomic Red Team test in your lab.
5. Record the result. Did it fire? Was telemetry visible? What needs fixing?

That's one validated detection. One rule you now have evidence for instead of an assumption. Do it five times next month. Then five more the month after. In six months, you'll know exactly which of your 350 rules are protecting you and which are decoration.

The number of rules you've deployed is a procurement metric. The number you've validated is a security metric. Start measuring the one that matters.