Every detection team knows this moment. A rule is written or downloaded, reviewed, translated into the query language of the SIEM, and deployed. The status says enabled, the rule count goes up, and the coverage report gets a little greener.

None of that tells you whether the rule will detect the attack it was written for. A rule can be well written and still find nothing, because its logic, its data, or its translation quietly disagrees with reality. And since a rule that never fires looks the same as a rule with nothing to catch, the problem can stay hidden for a long time.

This article explains what separates a working rule from a broken one, where rules usually go wrong, and what you can do with SOC Prime to prove that a rule works before it ships and keep it working afterward.

Contact Sales

What “working” actually means

A working detection rule does three things. It expresses the right logic for the behavior it targets. It runs on data that actually contains that behavior. And it is written correctly for the platform it runs on. If any one of these fails, the rule is broken, even though it is enabled and throws no errors.

This framing helps because each failure has a different cause and a different fix:

• Logic problems live in the rule itself. It is too narrow to catch variations of the behavior, or so broad that it matches normal activity.
• Data problems live in the environment. The events the rule needs are not logged, not collected, or missing the fields the rule relies on.
• Translation problems live in the move between languages. The meaning of the rule changes when it is converted into a platform’s query syntax.

Most teams check the first one carefully when they write a rule. The second and third are where rules tend to break without anyone noticing.

Where working rules go wrong

Logic that doesn’t match the behavior. A rule keyed only on a tool’s file name is easy to evade by renaming the file. A rule keyed on a common command-line pattern, with no filtering, can match administrators all day. Neither mistake is visible at deployment. The first shows up when an attacker walks past it, the second as alert noise.

Data that isn’t there. A process creation rule that depends on command-line arguments is useless if command-line logging isn’t enabled, because the event arrives without the field. The same goes for a log source that was never onboarded, or an agent that stopped sending. The rule runs on schedule, finds nothing, and looks healthy.

Fields that mean different things in different places. The same concept can have different names across products, and even data models from different vendors are separate contracts. Splunk CIM and Microsoft Sentinel ASIM are a good example: a field that exists in one may not exist in the other. A character-by-character port produces a rule that references fields the destination never populates.

Translation that changes meaning. Automated translators handle straightforward selection logic well, but correlation rules and proprietary functions usually need human review. Platforms also differ in how they treat details like case sensitivity, wildcards, and regular expressions. A rule can be translated “successfully” and still behave differently from the original.

Platform limits that retire good rules. SIEMs cap how many rules can run. Teams routinely disable working rules to make room for new ones, so coverage shrinks without anyone deciding it should.

Why it matters

Every one of these problems leaves the rule count and the dashboard unchanged. Coverage figures that count deployed rules therefore overstate protection, and the gap usually surfaces during an incident, when someone discovers that the rule that should have fired never could.

There is a second cost: a quiet rule is ambiguous. If nothing fires, is the environment clean, is the telemetry missing, or is the logic wrong? Working that out after the fact means checking logic, data, and translation one after another. It is far cheaper to gather evidence early and keep it current.

How SOC Prime helps you prove a rule works

Detection validation is really a chain of questions: what does this rule need, does my environment provide it, does the rule behave as expected on my data, and if not, what should change? SOC Prime supports each step.

Understand detection requirements

Validation starts before any testing. SOC Prime provides contextual information around detection content, including its intended behavior, telemetry requirements, MITRE ATT&CK mapping, potential false positives, and other metadata. This gives detection engineers a starting point for deciding whether a detection is applicable to their environment and what prerequisites need to be in place before it is tested. A rule that needs command-line logging, for example, tells you so up front, instead of leaving you to find out later.

Assess available telemetry

Once you know what a rule needs, the next question is whether you have it. Prime Hunt can help teams assess the relationship between their available data and potential detection coverage. Data Audit analyzes available log data and maps it to MITRE ATT&CK to identify potential visibility gaps. This helps you determine whether a lack of detection coverage comes from missing telemetry rather than missing detection content, which are two very different problems with two very different fixes.

Test detections against organizational data

Prime Hunt can also run detection scans against data from connected environments. Testing detections against actual data gives you evidence of how the content behaves in your environment, rather than relying only on theoretical validation. Scan results help identify detections that produce relevant matches, and highlight those that need further investigation or tuning.

Investigate and improve detection logic

When a detection needs modification, SOC Prime provides detection engineering capabilities through Prime Core and Prime Architect. Detection content can be reviewed, customized, translated, and optimized for the target environment. This addresses differences in schemas, field mappings, query languages, and environment-specific requirements without treating every problematic detection as a brand-new development task.

In practice, that means:

• Translate for the platform you run. All Sigma rules on the platform are already translated into all supported SIEM languages and formats, so you can pick up the query for your stack and deploy it right away. For anything custom, or for your own Sigma rules, use the Translation workspace in Prime Architect to convert them into the native query language of your SIEM, EDR, XDR, or data lake. Sigma stays the source, so a change made once can be translated again instead of edited by hand in each platform.
• Map tables, fields, and values to your schema. Custom Field Mapping lets you define profiles that map your non-standard tables, fields, and values to the defaults. Create a profile once, then apply it each time you deploy a rule or send a query.
• Add filters that fit your environment. Filters add conditions to the detection logic before deployment to include or exclude specific users, hosts, or other sets of items. They keep known-benign activity from turning a good rule into a noisy one, without rewriting the rule itself.
• Save deployment settings as presets. Presets store parameters such as query period, severity, and rule status, so deployments stay consistent.
• Validate, optimize, and fine-tune. The Translation workspace also validates and optimizes detection content. It doesn’t replace review: check every field against the destination schema, and look closely at anything flagged, especially correlation logic and platform-specific functions. When a change goes beyond mapping and filters, edit the code directly, translate it again, and save it to your custom repository as an update or a new rule.
• Research and adjust with the AI-assisted workspace. Use it to research the behavior a rule targets and work through changes to its logic. Engineers stay in control and review every change before it ships.

Identify coverage gaps

Detection validation should also answer what is not being detected. Data Audit in Prime Hunt provides coverage analysis based on both available telemetry and detection content. This helps teams distinguish between gaps caused by insufficient visibility and gaps caused by missing or unsuitable detection rules. That distinction informs the next engineering action: collect more data, tune an existing detection, or identify and develop additional detection content.

Continue validating over time

Detection effectiveness changes as environments and detection content evolve. Recurring validation with Prime Hunt lets teams reassess detections against current data rather than relying on an initial validation result indefinitely. This matters most in environments where logging configurations, data schemas, infrastructure, or detection content change frequently.

Evidence over assumption

A deployed rule is a claim. A rule that has been tested against real data is evidence. The difference is easy to overlook, because both look the same in a rule list and both stay quiet until an attack arrives.

SOC Prime helps teams close that gap. It starts with clear detection requirements and an honest look at available telemetry, tests detections against your own data, and gives you the tools to fix what doesn’t fit. Coverage analysis then shows whether the remaining gaps call for more data, better tuning, or new content, and recurring validation keeps the answer current as your environment changes. Start with the rules that matter most, and find out which ones would really fire.

The post A Deployed Rule Is Not a Working Rule: How to Tell the Difference appeared first on SOC Prime.

MITRE ATT&CK detection coverage is the ratio of adversary techniques your SOC can detect, validated against the technique set your threat model prioritizes, on the current framework version.

A coverage percentage means nothing without its denominator and proof method. Validated coverage counts techniques where a deployed detection rule fires against its required data source, divided by the techniques your SOC has prioritized, on ATT&CK v19 (released 2026-04-28). Every gap between that definition and the number on your slide is where the measurement breaks down. This page gives the method, the failure modes, and the questions that separate a vendor’s library figure from the coverage you actually run.

How do I measure my organization’s MITRE ATT&CK detection coverage?

Five steps, each measured per tactic, on ATT&CK v19:

1. Inventory your deployed detection rules.

2. Map each rule to ATT&CK technique IDs it covers.

3. Confirm the required log source for each mapped technique is collected and passing its contract gates: freshness, null-rate, and field-semantics. A source that flows but fails its contract does not count.

4. Prove each rule fires against a real or simulated test event. Tools: Atomic Red Team, MITRE Caldera, AttackIQ.

5. Compute the ratio per tactic.

Step 3 is where most programs quietly lose ground: a log source can be technically ingested while its null-rate or schema drift makes the detections above it unreliable.

Step 4 matters because a rule that has never fired might never fire, whether from a logic error, a parser change, or a renamed field. Tools like ATT&CK Navigator, or a coverage-audit product like Prime Hunt, support the mapping and validation.

Count a technique that spans two tactics once per tactic, which is ATT&CK Navigator‘s default. This keeps percentages comparable across sources.

What does an ATT&CK coverage percentage actually count?

It counts techniques, not sub-techniques or procedures, and each carries different data dependencies.

T1078 (Valid Accounts) needs identity and authentication telemetry. Its cloud sub-technique T1078.004 (Cloud Accounts) adds cloud control-plane logs joined to the identity provider. A rule written against generic authentication logs alone leaves T1078.004 uncovered, so it covers only part of Valid Accounts.

A defensible program measures against its prioritized technique set, states the denominator, and calls the difference.

What’s the difference between a detection content vendor’s claimed ATT&CK coverage and the coverage actually deployed and validated in my environment?

Four independent measurements exist. They are not interchangeable, and only the last one describes what your SOC detects.

Coverage-analytics tools like CardinalOps and Prime Hunt reconcile claimed mappings against your live Splunk, Elastic, or Microsoft Sentinel environment, where the library-to-validated gap becomes visible.

Which ATT&CK techniques can I not detect because of the logs I am not collecting?

Detection depends on data. Without the required data source collected, no detection fires, regardless of how many rules you own.

Map each prioritized technique to the data components its ATT&CK detection strategy uses (ATT&CK v19.2; version 18 replaced per-technique data sources with detection strategies, analytics, and data components), then reconcile against what your environment actually collects. A technique with no collected source scores zero.

Rank missing sources by the coverage each adds, weighed against ingest volume, licensing, parser effort, retention cost, and SLO reliability.

Prime Hunt runs a data audit that maps the log sources you actually collect to ATT&CK and lists the techniques with no telemetry behind them.

Contact Sales

How do I find and close gaps in my MITRE ATT&CK detection coverage?

Close a gap by deploying a rule and proving it fires against a collected source. Adding a rule to a catalog does not close a gap.

1. Build a heatmap on ATT&CK v19 using ATT&CK Navigator.

2. Prioritize by threat model and which data sources already pass their gates.

3. Source or author the rule.

4. Validate it fires end to end using Atomic Red Team, MITRE Caldera, or AttackIQ.

5. Re-measure.

What changes when ATT&CK releases a new version?

The denominator changes. Recompute.

ATT&CK v19 (initially released April 28, 2026) split the former Defense Evasion tactic into two new tactics, Stealth and Defense Impairment. A percentage computed before that split cannot compare to one after, because the taxonomy changed, not only technique counts.

Re-map to the new structure, recompute per tactic, and publish the delta. Do not relabel the old number.

How should I report ATT&CK detection coverage to our board?

Report validated coverage, not library size. Three metrics belong in the board package:

Give the board three questions for any vendor: what is the coverage denominator, which log sources does it assume are collected, and which ATT&CK version is it computed on.

How long should it take my SOC to have a detection in production after a new attack technique goes public?

Measure time-to-coverage: from technique or procedure publication (t0) to a detection deployed and proven to fire in production (t1).

Track median and P90 by technique class, since a commodity technique and a novel procedure carry different windows. Set the target based on your own program maturity. A published vendor turnaround time describes that vendor’s pipeline, not yours; SOC Prime’s published figure is a 24-hour SLA for detection content against emerging threats.

Where this does not hold

A coverage percentage cannot demonstrate detection effectiveness when any of its inputs are unknown: whether each source passes its gates, whether each rule has fired, whether the denominator is a real threat-model set. A number that cannot confirm all three describes a catalog, not a defended environment.

Coverage measurement checklist

• Rules inventoried and mapped to ATT&CK technique IDs (v19).

• Required data source for each mapped technique collected and passing freshness, null-rate, and field-semantics gates.

• Each rule proven to fire against a real or simulated execution.

• Denominator: techniques prioritized for your threat model.

• Coverage computed per tactic, each cross-tactic technique counted once per tactic.

• Missing sources ranked by coverage added against ingest volume, licensing tier, parser effort, retention cost, and SLO reliability.

• Board report shows validated coverage per source, gaps with owners, and time-to-coverage.

• Coverage recomputed and the delta published on every ATT&CK version change.

Related reading

• Attack Chains: See the Full Story Behind Every Threat (August 2026)
• MITRE Attack Flow v3.0.0 (October 2025)
• Uncoder AI Automates MITRE ATT&CK Tagging in Sigma Rules (April 2025)

The post Measuring MITRE ATT&CK detection coverage: what the percentage counts and what it hides appeared first on SOC Prime.