User Guide

Reading Your Coverage Report

Your Verify coverage report is not a grade — it is a ranked backlog of the attacker behaviors your monitoring did not see, each mapped to the log source or rule that would close it. This page explains every number on the report and how to read them in order.

What a Verify report is

Verify is detection-validation. It reuses the SiegePoint attack platform but inverts the scoreboard: instead of grading how deep an attacker gets, it grades whether your monitoring saw each technique — and it loops the whole coverage set rather than halting at the first objective. The output is a coverage map over ATT&CK, not a pass/fail. From that map, the report derives four things, and they are meant to be read in this order:

1. Coverage % — one headline number, only meaningful against a pinned matrix version.
2. The D0–D4 ladder distribution — where your outcomes sit across the detection ladder.
3. The blind-spot list — the ranked backlog, and the real payload of the report.
4. The MTTD/MTTR trend — how fast you see and respond, tracked across re-runs.

1. Coverage %

Coverage % is the share of fired techniques graded at or above a bar you choose. A common bar is detected = D2 or higher (an alert actually fired), but you set it. Prevention, detection-visibility, and response are reported as separate rates: a technique that was silently prevented (D4 with no alert) counts toward prevention but not toward a "detected" bar, so the detection number is never inflated by controls that blocked without ever alerting. The number is only interpretable against a pinned ATT&CK matrix version, which is stamped on the run. When the matrix moves — new techniques, retired ones — the denominator moves with it, so a coverage figure without its pinned version is meaningless. Always read the version stamp next to the percentage.

2. The D0–D4 ladder distribution

Every fired technique resolves to the highest defensive outcome it produced, on the Detection Ladder. The report shows the histogram across all five rungs.

Read the shape, not just the top of the ladder. A pile-up at D1 Logged is a different problem than a pile-up at D0 Blind: D1 means the evidence is already in your SIEM and a detection rule would surface it, while D0 means you are not collecting the signal at all. The two demand different fixes, which is why the blind-spot list separates them. For the full definition of each rung, see the Detection Ladder.

Alongside every rung sit two timers, always shown as a pair: MTTD (execution to first alert) and MTTR (alert to first response). The rung tells you whether you saw the technique; the timer tells you how fast. A D2 that took hours to alert is a very different posture than a D2 that alerted in seconds.

3. The blind-spot list — the backlog, not a grade

This is the real payload. The blind-spot list ranks every technique graded D0 or D1 — every place your stack is either blind or merely logging without alerting. Each entry is mapped to the log source or detection rule that would fix it. The deliverable reads like this:

Here are the 11 techniques your stack is blind to, ranked, each mapped to the log source that would close the gap.

That framing is deliberate. Detection coverage is perishable — rules get retired, tools get swapped, staff turn over, and the ATT&CK matrix itself moves — so Verify delivers a prioritized detection-engineering backlog you can work down, not a certificate you file away. Treat the list as your work queue: start at the top, close the gap, and the next re-run confirms the change.

How to trust a D0

A grade above D0 requires a positive tie-back: the observed signal must carry the technique's unique benign execution marker — a distinctive process or command token, a canary host or account, a tagged user-agent, a synthetic filename — or match the technique's pre-declared expected-signal map, inside a bounded, clock-normalized time window with a grace band. This is the soundness core of the report, and it enforces three rules:

• Execution is confirmed before grading. A technique that did not actually run is marked inconclusive — never D0. Silence only counts as blind if we know the attack fired.
• Attribution is by marker, not by proximity. "An alert fired around that time" is coverage inflation and is explicitly not credited. Only a signal that carries the marker earns a rung above D0.
• Silence is a finding. A confirmed execution with no attributable signal is D0 Blind — a real result, not an error.

4. MTTD / MTTR trend across re-runs

Detection coverage decays, so Verify is structurally a subscription: monthly or quarterly re-runs, with each report showing the delta and trend against prior runs rather than a fresh isolated snapshot. The trend view tracks Coverage %, the ladder distribution, and the MTTD/MTTR timers over time. MTTD and MTTR are undefined — not zero — for outcomes with no alert (D0, D1, and any D4 that blocked silently), and every average is shown with its denominator (how many techniques it was computed over), so a shrinking coverage set cannot masquerade as faster detection. Read it to answer the questions a single run cannot: is the backlog shrinking, are your alert-to-response times improving, and did a tooling change quietly reopen a gap you had closed? A green run followed by a regression is the signal a subscription is designed to catch.

Reading the report in order

1. Confirm the pinned matrix version and the run mode (Blind, Coordinated, or Multi-party) — they set what the numbers mean.
2. Note the Coverage % as a headline, then move past it.
3. Read the ladder distribution for shape: how much is Blind (D0) versus merely Logged (D1).
4. Work the blind-spot list top-down — each entry names the log source or rule that closes it.
5. Check the MTTD/MTTR trend to see whether prior fixes held and where response is slow.

Your run's mode changes how to read it. Coordinated runs hold the human constant and measure your tooling and rules — ideal after you have made changes and want to confirm them. Blind runs give the truest signal because the blue side was not told. Multi-party runs make an outsourced SOC itself the subject. The mode is stamped on the run.

The honest limit

This limit is stated in every report by design. It is why the deliverable is framed as a backlog you keep working rather than a score you achieve once. For how Verify fires real techniques safely against production, and how the read-only observation plane pulls signal from your SIEM/EDR/XDR without ever writing to or tuning your controls, see /verify-architecture-guide.html. For the rest of the guide, see the SiegePoint user guide.