Home/Detection/Workspace

Detection coverage workspace

Declare your environment, your detection stack, the telemetry you collect, and the rules you run, then read an honest four-state coverage picture in one place - including the hard ceiling a better rule can’t lift.
▸ “Coverage” means three different things - this page is the hard floor
The word “coverage” hides three very different questions, and a SOC that conflates them over-reports what it can actually see. This one workspace answers all three, so you do not conflate them:
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 catalogue view here and the /compliance report. 2Do you actually run it? Your deployed coverage - true only when a rule is loaded in your SIEM and firing. Pasting your rules into this workspace reads the ATT&CK tags they declare and reports that honestly. 3Could you ever detect it? This page. Even a perfect rule is blind without the log it queries. Computed from each technique’s ATT&CK data-source requirements against the telemetry you tick, it shows what stays invisible no matter how good your detections get.
You are at layer 3 - the hard floor. A better rule can lift a missing-rule gap; it can never lift a missing-telemetry gap. Start here: there is no point authoring a detection for a technique whose data source you don’t collect. Fix the ceiling by adding telemetry, then write rules where the floor allows it.
A missing detection rule can be written; a missing log source can’t be queried. Tick the telemetry your environment actually collects and this shows the techniques that stay invisible no matter how good your detections get - computed from each technique’s ATT&CK data-source requirements (652 of 858 techniques carry data-source guidance).
STEP 1Your environment (optional scope)
Pick a platform and the telemetry list, technique counts, and gap in the steps below rescope to it. Leave it on All platforms to assess the full ATT&CK matrix.
STEP 2Your detection stack
Declare what you actually run, three ways. Any one is enough; together they give the truest gap: the detection products you operate, then the specific rules you have deployed, then any techniques you already cover.
2ASIEM backend
Tick one or more you run; none ticked counts any Sigma rule. Untick Sigma (SIEM) below to count no Sigma rules at all.
2BDetection systems
Covered counts a technique only if you run a system that detects it. Untick a system you do not operate and techniques only it covered drop to Blind-fixable. After you compute, a red −N beside a ticked system shows how many covered techniques it alone holds up - what you would lose by unticking it. Sigma is judged against the SIEM backend above; the others are independent. Changes apply when you compute the ceiling.
2CYour detection rules or techniques (paste rules you run, or list TTPs you cover)
Two things go in this one box. Detection rules you run (Sigma, Elastic, Splunk, Microsoft Sentinel, Suricata, Chronicle YARA-L, Panther) - we read the ATT&CK technique each one declares. And techniques / TTPs you already cover - just list the ATT&CK IDs (for example T1059, T1078.001). Either way, what maps folds into your coverage gap.
Read first-class and matched automatically: Sigma (via its attack.tNNNN tags), Elastic, Splunk, and Microsoft Sentinel, Suricata (via its mitre_technique_id metadata), Chronicle YARA-L, and Panther rules, plus bare ATT&CK technique IDs. You can paste several of these formats together in one go - each rule is read in its own format. Declaring a parent technique (like T1059) also credits its sub-techniques; a sub-technique credits only itself. A rule in another product’s format, or one carrying no ATT&CK tag we recognise, is flagged below and counts for nothing until you give it a technique.
Whatever maps folds into Covered wherever you also collect the telemetry for it, so your own coverage and our corpus rules land in one gap. Still blind where the telemetry is missing.

STEP 3Telemetry you collect

0 selected
Tick every log or telemetry source your environment actually collects. The number tagged on each row is how many ATT&CK techniques rely on that telemetry: collect it and those techniques become detectable, leave it unchecked and they stay invisible no matter how good your detection rules are. Click a heading to select a whole source at once.
Quick-fill from your stack (a starting point - review the ticked rows before computing; presets add to your selection, never remove):
0 selected
Active Directory
Application Log
Certificate
Cloud Service
Cloud Storage
Command
Container
DNS
Domain Name
Drive
Driver
File
Firewall
Firmware
Group
Image
Instance
Internet Scan
Kernel
Logon Session
Malware Repository
Module
Named Pipe
Network Share
Network Traffic
OS API Execution
Persona
Pod
Process
Scheduled Job
Script
Sensor Health
Service
Snapshot
User Account
Volume
WMI
Web Credential
Windows Registry
Sign in to save your detection rules so they persist and fold into your coverage automatically, no re-importing. Sign in.
Select your telemetry above
Tick the log and telemetry sources your environment collects, then compute the ceiling to see which techniques stay permanently invisible.
SOC and Response
CVE triage
Stack monitoring
Am I affected
IOC triage
KEV catalog
Recently exploited
Daily brief
Change tracking
Detection Engineering
Detection coverage workspace
Saved stacks
SIEM query builder
Detection rules
D3FEND
Threat Hunting
Threat actors
ATT&CK techniques
Attack paths
Indicators
Ransomware groups
Atomic tests
Red Team and Pentest
Exploitability triage
Recon pack
Attack paths
CAPEC patterns
Adversary emulation
Compliance and GRC
Framework mapping
Control assessment
Audit view
Atlas Search Threat actors Techniques Detection coverage Tools & malware CWE CAPEC KEV catalog Package vulns
About All capabilities Pricing API docs Privacy policy Terms of service
threatengine.sh