> ## Content Index
> Fetch the complete content index at: https://theattacksurface.blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Deployed Is Not Detected: The Detection Coverage Illusion
- URL: https://theattacksurface.blog/deployed-is-not-detected/
- Published: 2026-07-30T16:13:02.000Z
- Updated: 2026-07-30T16:13:02.000Z
- Description: Most coverage maps measure whether a rule was deployed, not whether it has ever fired. A rule sitting on top of a missing log source cannot trigger, yet it still counts as coverage. Here is how to tell real detection from the assumption of it.
- Author: Kish Galappatti
- Tags: Detection Engineering, Security Operations, Analysis

Somewhere in your detection engineering program is a coverage map, a heatmap of ATT&CK techniques shaded green where you have a rule and red where you do not. Maybe you have a "coverage" score to go along with it. It is what you show leadership, the metric that turns "are we covered" into a number. It looks great but for most teams it's measuring the wrong thing. Because green on that map means a rule was written and deployed, not that the rule has ever fired.

A detection rule can be deployed and still be completely inert: its required log source was never onboarded, it was disabled during an incident and never turned back on, or it has simply never matched anything because the logic is wrong. On a deployment-based coverage map, all three of those look identical to a rule that fires cleanly every day. The map says green. But the defense is not there.

## Three signals, and only one of them is real

When you ask "is this technique covered," there are three different signals that might answer, and they mean very different things.

**Theoretical coverage** means a rule concept exists for the technique, in your platform's library, in a public ruleset, somewhere. It says nothing about whether you have deployed it.

**Deployment status** means the rule is installed in your stack. It says nothing about whether it fires.

**Firing behavior** means the deployed rule actually triggers, in production, on real telemetry. It is the only one of the three that reflects reality.

Most programs run their coverage story on the first two signals, because they are cheap to read. You can enumerate your deployed rules in an afternoon. The third signal is harder, it requires joining your rule inventory to what your SIEM actually did, and that is exactly why it is the one worth having. A coverage map built on deployment is a map of intentions. A coverage map built on firing is a map of your defenses.

## The failure mode with a name: deployed-blind

Call it **deployed-blind**: a rule is installed and enabled, but the log source it depends on is missing, misrouted, or stale, so the rule physically cannot fire. Someone did the work. The rule exists. The detection does not, because the data never arrives.

A deployed-blind technique scores identically to a clean-firing one on any map that counts rules rather than firings. That is the most dangerous kind of wrong, because it is confident. The whole point of measuring firing behavior is to drive a deployed-blind technique's coverage *below* an uncovered one, because a blind spot you believe you have covered is worse than a blind spot you know about.

## A better vocabulary than green and red

Two colors cannot carry this. The operationally distinct states of a detection are:

- **Detected**: deployed, enabled, log source healthy, fires cleanly, low false-positive rate. The only state that is actually coverage.
- **Deployed-noisy**: fires, but with a false-positive rate high enough that no analyst trusts it. Coverage on paper, alert fatigue in practice.
- **Deployed-untested**: deployed with healthy logs, but has never once fired. Maybe the logic is wrong, maybe the behavior is genuinely rare. You do not know, and "you do not know" is the honest score.
- **Deployed-blind**: deployed, but a required log source is missing or stale, so it *cannot* fire. A fixable telemetry gap.
- **Deployed-disabled**: the rule exists and is switched off. Not coverage, no matter how good the logic is.
- **Library-only**: a rule template exists somewhere, but nothing is deployed to your stack.
- **Gap**: no rule and no template. A true, honest blind spot.

The distinction that matters most on this list is between **deployed-blind** and **gap**, because a deployment map collapses them into the same red cell when their remediation is completely different. Deployed-blind is a data-onboarding problem: the rule is fine, fix the log source and it lights up. Gap is a detection-engineering problem: you need to write something. Mislabeling a missing log source as a missing rule sends the wrong team after the wrong fix.

## Coverage is a distribution, not a checkbox

Even "it fires" is not a single bit. A rule that has fired cleanly three times and a rule that has fired cleanly three thousand times are both, technically, firing, but your confidence in them should not be equal. Detection coverage is better understood as a probability with an uncertainty attached, and that uncertainty should shrink as evidence accumulates and widen when evidence is thin or contradictory.

This matters operationally in two ways. First, a technique you have seen fire only once or twice is not yet coverage you should bet on; it is a promising signal awaiting confirmation, and your risk picture should say so rather than flipping the cell to a confident green. Second, false positives are evidence *against* trust, not just noise to tune away. A rule that fires constantly but is wrong most of the time is not partial coverage; it is a rule your analysts have already learned to ignore, which is worse than no rule because it consumes attention while providing nothing.

The practical version of this is simple: stop treating coverage as a checkbox that is either ticked or not, and start treating it as a claim with a confidence level that your firing evidence either supports or undermines.

## One more distinction: detecting is not blocking

It is easy, once you start taking firing seriously, to over-credit it. Detecting a technique and stopping it are different events. A rule that fires reliably tells you the activity is *visible*; it does not tell you the activity was *prevented*. Plenty of real intrusions generated telemetry that fired a rule that no one actioned in time. Keep the two terms separate in your risk model. Firing data measures whether you would see it. Whether seeing it leads to stopping it is a separate question about your response, and conflating the two flatters both.

## What to actually do

- **Measure firing, not deployment.** Join your rule inventory to what your SIEM actually did, and let that, not a list of installed rules, drive your coverage view. This is the single highest-leverage change, and it is mostly plumbing you already have.
- **Treat deployed-blind and deployed-disabled as gaps, loudly.** They are the illusory-coverage cells. Surface them as *below* uncovered, because a false green is more dangerous than an honest red.
- **Separate the telemetry problem from the detection problem.** Deployed-blind needs a log source, not a new rule. Route it to the team that can actually fix it.
- **Validate with evidence, not assertion.** A vendor or a ruleset telling you a technique is covered is a claim; running the technique and watching whether anything fires is proof. This is what [adversary emulation](https://attack.mitre.org/?ref=theattacksurface.blog) tooling like [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team?ref=theattacksurface.blog) is for, and it is the only way to move a cell from deployed-untested to detected honestly. I made the same argument from the attacker's side in [the Patchmageddon piece](https://theattacksurface.blog/patchmageddon-tornado-warning/): in a world where the warning arrives with the attack, the difference between an assertion of coverage and evidence of it is most of your risk.
- **Re-derive coverage continuously.** Firing behavior drifts as log sources break, rules get disabled, and infrastructure changes. A coverage map is perishable the same way a [vulnerability-relevance judgment is](https://theattacksurface.blog/relevant-to-your-industry-is-a-myth/); wire it to your telemetry, not to a quarterly review.

None of this requires a new platform. It requires refusing to let "deployed" stand in for "detected" on the one artifact your whole program treats as ground truth. A coverage map built on deployment is an assumption wearing a measurement's clothes. The moment you feed it real firing evidence, it starts telling you where you are actually blind, which is the only version of the map worth showing anyone.

---

*This post is the practitioner-facing version of a research whitepaper I wrote for AEGIS Labs,* [*Empirical Detection Posteriors: Closing the Loop from SIEM Firings to Breach Probability*](https://github.com/kgalappatti-aegis/aegis-labs/blob/main/detection-posteriors/Adversarix%5FEmpirical%5FDetection%5FPosteriors%5FWhitepaper.pdf?ref=theattacksurface.blog)*, which formalizes the firing buckets and the per-technique detection posterior as a Beta distribution sampled inside a Monte Carlo breach simulation.*