User Guide

Getting Started

This page walks a client or delivery partner through commissioning a SiegePoint Verify subscription: choosing what to test, how to run it, authorizing the work, connecting read-only telemetry, and setting a re-run cadence. Verify does not grade how far an attacker gets — it grades whether your monitoring saw each attack and how fast. Expect your first run to produce a ranked blind-spot backlog, not a score; later runs prove the fixes held.

What Verify measures

Verify belongs to the Breach & Attack Simulation category. It fires real, safe techniques from the SiegePoint ATT&CK-mapped library at your production environment, then checks whether your monitoring produced a defensive outcome. Each fired technique resolves to the highest rung it reached on the Detection Ladder:

Every technique is also stamped with two timers: MTTD (execution to first alert) and MTTR (alert to first response). A rung tells you whether your stack saw the attack; the timer tells you how fast. They are always reported as a pair. For the full model, see the Detection Ladder and /verify-architecture-guide.html.

Before you commission

Have three things settled with your delivery partner (an MSSP, MDR provider, or consultancy running Verify as a white-labeled OEM service):

• The surfaces in scope — which hosts, accounts, and platforms Verify may touch. Scope and platform are enforced by an allowlist that fails closed.
• Who your SOC is — in-house, outsourced to an MSSP, or a mix. This decides whether you need multi-party authorization.
• Which telemetry systems hold your detections — SIEM, EDR, and/or XDR — and who administers them, since Verify reads from them.

Commissioning steps

1. Pick a coverage set. Choose the ATT&CK techniques Verify will fire, scoped to the surfaces you care about. The output is a coverage map over ATT&CK, so the set defines exactly what "covered" will mean. The matrix version is pinned per run — coverage percentages are only comparable against the same pinned version.
2. Choose a mode. Select how the exercise runs (see the table below). Your SOC arrangement drives this: if your SOC is outsourced, prefer Multi-party so the provider consents and is itself part of the test.
3. Sign authorization. Verify inherits the full SiegePoint Authorization Gate: a signed authorization_ref, a named approver, and a window. Because Verify fires at production, this is mandatory. Multi-party engagements require both the client and the MSSP to consent, recorded in a shared tamper-evident audit.
4. Connect your telemetry. Attach read-only connectors In build to your SIEM, EDR, or XDR so the Observation plane can pull events and alerts, and accept push-confirmations from your SOC. Verify never writes to, tunes, or silences your controls — it only reads. Connector credentials are held by reference, never stored inline.
5. Pick a cadence. Detection coverage is perishable — rules get retired, tools get swapped, staff turn over, and the ATT&CK matrix moves — so Verify is a subscription. Choose a monthly or quarterly re-run; each report shows the delta and the MTTD/MTTR trend against prior runs.

Choosing a mode

How Verify stays safe on production

Verify runs only the safe, reversible subset of each technique — benign markers, read-only or self-cleaning actions, hard caps — enough to emit the signal a defender should catch, never enough to cause impact. It fires at production on purpose: a lab cannot tell you whether your SOC is awake. Anything above passive execution requires the named approver and window from the gate.

Reading your first report

The deliverable is a backlog, not a grade. From the coverage map, each report derives:

• Coverage % — the share of the set graded at or above a bar you choose (for example, "detected" = D2 or higher). Meaningful only against the pinned ATT&CK matrix version. Prevention, detection-visibility, and response are reported as separate rates, so a silently blocked technique (D4 with no alert) never inflates the "detected" number.
• Ladder distribution — a histogram of how techniques landed across D0 through D4.
• Blind-spot list — every D0 and D1, ranked, each mapped to the log source that would close it. This is the prioritized detection-engineering backlog and the real payload: for example, "here are the 11 techniques your stack is blind to, ranked, each mapped to the log source that would fix it."
• MTTD / MTTR trend — speed of detection and response, tracked across re-runs.

Two rules govern how findings are reported. Execution is confirmed before grading: a technique that did not actually run is marked inconclusive, never D0. And silence is a real finding — a technique that ran with no attributable signal is D0 Blind, not an error.

What Verify does not claim

Build status

Where to next

Read the Detection Ladder for the grading model in full, the Verify architecture guide for the five-plane design and the signal-attribution core, and the SiegePoint user guide for how the shared attack platform and Authorization Gate operate.