Coverage
Detection Coverage Check
Paste your detection rules - see which ATT&CK techniques you actually cover, and exactly how to close the gaps
Paste your detection rules below - Sigma, Elastic, Splunk, or Microsoft Sentinel; the format is auto-detected. We read the ATT&CK techniques each rule already declares and report your coverage from that - it is your rules' own mapping, not a guess. Rules with no declared technique that match a rule we already hold are mapped from our data; anything left over is listed for you to tag. Optionally name a threat actor and we will show your coverage against that adversary, with the public detection content and tests we hold for every gap.
▸
“Coverage” means three different things - don’t confuse them
The word “coverage” hides three very different questions, and a SOC that conflates them over-reports what it can actually see. The coverage workbench, this check, and the telemetry ceiling each answer a different one:
1Does a detection exist anywhere? The public catalogue - a green result means someone wrote a rule for that technique. It says nothing about your environment. That is what the default heatmap and /compliance report.
2Do you actually run it? Your deployed coverage - true only when the rule is loaded in your SIEM and firing. This page is the most honest answer to that: it reads the ATT&CK techniques your pasted rules already declare (their own tags), so the count is your rules’ mapping, never inferred from rule logic.
3Could you ever detect it? Your telemetry ceiling. Even a perfect rule is blind without the log it queries. Tick your log sources above and each gap here is labelled missing a rule (writable) vs missing telemetry - the hard ceiling the ceiling page computes in full.
You are at layer 2. A red box here is only a real gap once the ceiling says the telemetry exists to detect it - otherwise the fix is collecting a log source, not writing a rule. Work it as: ceiling (what is possible), then this check (what you run), then close each gap the right way.
ⓘ
Why this exists
Every SOC says it "detects MITRE techniques," but few can show which ones. This turns the rules you already run into an honest coverage map, and for each gap it hands you adoptable rules and validation tests so the gap is something you can actually close, not just a red box.
⚙
How the mapping stays accurate
1If a rule declares its ATT&CK techniques (Sigma attack.tNNNN tags, Elastic threat mapping, Splunk mitre_attack_id, Sentinel relevantTechniques), we read them - deterministic, the rule's own mapping
2If it has no tag but its Sigma id matches a rule we already hold, we use the mapping we curated for it
3Otherwise it is listed as unmapped for you to tag - we never infer a technique from rule logic, so nothing unverified enters the count
▶
Check your coverage
Paste one or more rules in any supported format. Separate multiple YAML rules (Sigma, Splunk, Sentinel) with a line containing only ---; Elastic NDJSON is one rule per line.
Your rules are processed for this request only and are not stored. Sigma, Elastic, Splunk, and Microsoft Sentinel formats are auto-detected.