How Do You Know Your Detection Actually Covers Ransomware?
A 100% MITRE ATT&CK coverage score can still hide blind spots. How to tell which detection rules are genuinely live, and the four questions to ask first.
How Do You Know Your Detection Actually Covers Ransomware?
When a board member asks "if ransomware hits us today, would we catch it?", the answer you hear most often is: "Yes — we've got EDR, we've got SIEM, we've got a firewall. It's all covered."
That isn't an answer. That's a list of things somebody bought.
The much harder question is how much is covered, and measured against what? Because "covered" as understood by the person signing the purchase order and "covered" as understood by the person staring at a console at 3 AM are two different words that happen to be spelled the same.
Why a coverage percentage misleads you
MITRE ATT&CK is the most direct way to answer this question, because it turns "are we defended?" into a grid you can tick or leave blank. (If ATT&CK itself is new to you, start with what MITRE ATT&CK actually is.)
But the moment that grid gets compressed into a single percentage, the number starts working against you — in at least three separate ways.
Trap 1 — having a rule is not the same as running a rule
This is the one you'll hit first. Most SIEMs ship with a large built-in rule catalog on day one, and the coverage report happily counts every entry in it.
The problem is that a rule only fires when logs feed it. A rule that needs endpoint telemetry, on a deployment where the EDR was never wired into the SIEM, is a beautifully written rule that is fast asleep. It counts as coverage on paper. It protects nothing.
Trap 2 — counting at the technique level flatters you
ATT&CK counts techniques. In the real world, each technique has several ways to pull it off.
Take disabling security tooling before encryption starts. An attacker can stop the service, edit the registry, or bring along a properly signed but vulnerable driver and use it to shut the EDR down. If your rule only catches the first of those, the grid still shows that technique as covered.
The percentage isn't lying. It's just far coarser than anyone reading the report assumes.
Trap 3 — covering the whole matrix isn't the same as covering ransomware
ATT&CK holds a lot of techniques, and ransomware doesn't use most of them. Chasing every cell to green spreads effort evenly across things that don't deserve equal weight.
Pick the path ransomware actually walks and go deep on that instead — how it gets in, how it escalates, how it moves sideways, how it kills defenses, and only then how it encrypts. One hole anywhere along that path and the matrix-wide number is worth nothing.
What this looks like when you're actually staring at it
The Detection Coverage page in zcrSIEM puts the goal in the subtitle: "Measure source and MITRE ATT&CK coverage to expose detection blind spots."
The screen sorts every rule in the catalog into three states. Live — a log source you're ingesting today feeds this rule. Ready — the rule is written, but the source it needs isn't connected yet. Uncovered — nothing in your planned sources would feed it at all.
That split is the whole point of the page, and it's also what the ATT&CK numbers on the same screen quietly depend on. A technique counts as covered as soon as a rule exists for it, whether or not the logs that rule needs are arriving; the live count is the subset whose rules are firing on today's logs. Those are two different figures, and the distance between them is your real gap — techniques that look finished on paper but sit dark in practice. Report only the covered figure to your executives and you have personally buried that gap under a number that sounded like good news.
The MITRE ATT&CK coverage by tactic chart on the right keeps those two ideas apart with colour. The dark portion of each bar is what's firing on today's logs; the pale portion is the rest. As bars, it's far easier to read than any count: a tactic that runs dark end to end is genuinely watched, one that stays pale the whole way has rules sitting there waiting on logs that never arrive.
Read those bars as a sentence and the uncomfortable ones are easy to spot. If Initial Access runs dark while Lateral Movement stays pale, then once somebody is inside, you're less likely to see them moving between machines than you were to see them arrive. For ransomware, that's the most expensive stage to miss.
And on the log source side
The Coverage by log source panel answers the other half: for each source, how many rules it would switch on, split by whether that source carries an Ingested tag today or is only planned. FortiGate, Palo Alto, Cisco ASA, Sangfor NGAF, Windows Active Directory and CrowdStrike Falcon each get a row, and the number beside a row is the count of rules riding on that one feed.
If CrowdStrike Falcon stops shipping logs today — a broken agent, a policy change somebody fat-fingered, an expired licence — every rule this page ties to that source goes quiet at the same moment. And unlike a noisy alert, silence doesn't announce itself. Watching for absent logs is its own piece of configuration; don't assume it's already switched on.
Seeing "rules bound to this source" as a per-row number turns out to matter more than it first sounds. It converts "a log source went down" from a routine IT ticket into a risk figure you can explain to a non-technical audience in one breath — and it's exactly why wiring EDR logs into the SIEM properly is worth finishing before you go shopping for more rules.
How to actually measure it — start with four questions
You don't need a programme for this. Answer these four first.
1. How many rules are running right now, not how many exist in the system? If those two numbers are far apart, the gap is debt you haven't paid.
2. If you slice ransomware into stages, which feed backs each one? Treat it as a stock-take, not a detection guide:
| Ransomware stage | The feed that would show it | Ingested today? |
|---|
| Initial access | mail gateway, perimeter firewall/VPN, proxy | ☐ |
| Credential theft and escalation | AD authentication logs | ☐ |
| Discovery and lateral movement | endpoint (EDR) + authentication | ☐ |
| Killing defenses, deleting backups | endpoint (EDR) | ☐ |
| Encryption | endpoint (EDR) | ☐ |
Any stage where you can't name the feed — or where you can name it and know it was never wired in — is the real blind spot. Not a gap in the ATT&CK grid.
For what individual rules should be looking for at each stage, that's already written up in detecting ransomware with SIEM. For how scattered events get stitched back into a single storyline, see reading an attack flow with MITRE ATT&CK.
3. If your single most important log source disappeared, how many rules would you lose? If you can't answer inside thirty seconds, nobody is measuring this.
4. When did you last run a real test against it? This one matters most, and no dashboard on earth can answer it for you.
What a coverage page can't tell you (and shouldn't pretend to)
A screen like this answers "do we have a rule, and is it running?" well. There are at least four things it doesn't answer.
It doesn't tell you whether a rule is tuned. A rule that fires two hundred times a day until the team mutes it is worth exactly as much as no rule at all. On the coverage page it still counts as Live, right alongside your best one.
It doesn't tell you whether the logs arriving are complete. The Ingested tag says logs are coming from that source. It doesn't promise every log type is switched on. A firewall sending traffic logs but no IPS logs still shows up as Ingested. Confirming that means going into the device config yourself — there's no shortcut.
It doesn't prove you'd actually catch it. Between "we have a rule that ought to catch this" and "we tested it and it caught it" lies a distance you can only cross by testing, not by reading a dashboard.
It doesn't tell you whether you'd catch it in time. Coverage is about seeing. Stopping something fast enough is a separate problem, and it belongs more to automation and to human drilling than to rules.
Put plainly: the Detection Coverage page lets you argue with data instead of with feelings, which is already worth having. It is not a certificate that you're safe, and no tool can issue you one of those.
Signs this article is about you
- You can't say offhand how many rules are actually running right now
- You onboarded a new log source recently and don't know which rules it switched on
- A log source has stopped sending data for days before anybody noticed
- Your executive report carries a coverage percentage and nobody can explain what the denominator is
- Nobody has ever tested whether the ransomware-side rules fire
Two or more of those and the highest-value work isn't buying more rules or more tooling — it's measuring what you already own, because right now nobody knows how much of it is switched on.
How zcrSIEM handles this
zcrSIEM separates "rules we have" from "rules that are running" on one screen: Live / Ready / Uncovered gives you rule status, coverage by log source tells you how many rules you'd lose if a given source failed, the ATT&CK by tactic chart shows which tactic the hole sits under, and there's a Create custom rule button for the cases the packaged rules don't reach.
What it won't do for you is decide which hole matters enough to fix first. That still takes someone who understands your own business.
If you want to know how much of your current stack genuinely covers you, have a look at plans and pricing. And if the question of hunting for what the rules still can't catch is where your head is, read on in AI threat hunting.
Get in touch
Want to know where your current detection has holes? Talk to our team — the consultation is free.
Sources
- MITRE ATT&CK, “Data Encrypted for Impact (T1486)” — technique definition and ransomware context: https://attack.mitre.org/techniques/T1486/ (accessed September 14, 2026)
- Data note: the coverage examples and figures are illustrative analysis, not customer telemetry or test results