SiegePoint Verify is the defensive inversion of the SiegePoint attack platform. It runs the same authorized technique library, through the same engine and the same authorization gate — but instead of grading how deep an attacker gets, it grades whether the client's monitoring saw the attack, how deeply, and how fast. This guide is the system architecture: the grading ladder, the five planes, and the signal-attribution engine that makes a coverage claim defensible rather than anecdotal.
Scope: System architecture — not detection-evasion tradecraftCategory: Breach & Attack Simulation / control validationRevised: 2026-07-08
Verified Cited against a primary / authoritative sourceSiegePoint design Our own instrument — informed by, not quoted from, the sources
Status — design stage. SiegePoint Verify inverts the already-shipped SiegePoint attack platform. The pieces it reuses — the Authorization Gate and the Mangonel execution engine — are built and live. Verify's new Observation and Scoring planes (the telemetry connectors, the D0–D4 grading, and the signal-attribution engine) are in build. Where this guide describes those new planes in the present tense, it states how they are designed to work, not a running system.
Section 01The inversion — same engine, opposite protagonist
A penetration test answers "could an attacker get in?" Detection validation answers a different, equally important question: "if an attacker did exactly that, would we notice?" The two share every moving part except the scoreboard. SiegePoint Verify reuses the attack platform wholesale and inverts only what is being measured.
Same inputs
One library, one gate
The same ATT&CK-mapped technique modules, the same Mangonel engine, the same Authorization Gate. Nothing new is built to attack; the offensive platform is the substrate.
→
Inverted scoreboard
Grade the defender
Each technique is scored not by the attacker's surrender rung but by the defender's response on the Detection Ladder (§02) — did the SOC log it, alert, respond, or block?
→
Inverted control flow
Loop, don't halt
An attack run halts at the first objective. A Verify run has no objective to reach — it fires the whole coverage set, grading every technique independently, even the ones that were caught.
This places SiegePoint Verify in the category the industry calls Breach & Attack Simulation (BAS) or continuous security-control validation1 — the automated, repeatable cousin of the purple-team exercise. Where a purple team is a manual, point-in-time collaboration between red and blue, Verify is the same idea rendered as an instrument: scheduled, scored on a fixed ladder, and trended over time.
Figure 1 — The Verify loop: same ladder, inverted; grade the defender's response to every technique.
The intellectual anchor is MITRE's own ATT&CK Evaluations, which grade a defensive product's ability to produce detections in escalating categories (telemetry → general → tactic → technique).2 Verify borrows that "grade the detection, not the exploit" stance and operationalizes it against the client's actual production stack rather than a vendor lab — adding response, prevention, and timing.
Section 02The Detection Ladder (D0–D4)
SiegePoint's attack side grades a control's failure on the Surrender Ladder (S0–S4, from reachable to objective). Verify grades the defence's success on a mirror ladder — five rungs from "saw nothing" to "stopped it cold." A single fired technique resolves to exactly one rung: the highest defensive outcome it produced. But the rung is only one axis — prevention, detection-visibility, and response are partly independent, so the run also records the sub-states behind each rung and reports them as separate rates (§06), never as a single blended coverage number.
D0Blind
Executed; zero telemetry. Nothing recorded it — a total gap.
D1Logged
Telemetry captured, but no alert fired. The data exists; the rule does not.
D2Alerted
A detection rule fired — an analyst-visible alert was raised.
D3Responded
A human or SOAR playbook engaged the alert within the window.
D4Prevented
A control emitted a block/deny event that stopped the action — graded from that positive signal, not from an absence.
The ladder is a deliberate inversion of the attack ladder: where the attacker climbs toward compromise, the defender climbs toward control. The two describe the same event from opposite chairs, so they line up rung for rung.
Attacker side (Surrender)
Defender side (Detection)
What it means for the client
S4 · Objective reached
D0 · Blind
Worst case: the attacker won and no one saw it. The blind spot to fix first.
S3 · Actioned
D1 · Logged
You have the forensic breadcrumb but would only find it after the fact, in a hunt.
S2 · Surrendered
D2 · Alerted
The SOC gets a chance to act — detection works; response is the open question.
S1 · Susceptible
D3 · Responded
Detection and response fired; measured now by how fast (MTTR).
S0 · Reachable
D4 · Prevented
Best case: a control emitted a block/deny event and stopped it — but that is not, on its own, proof the SOC saw it (see §06).
The rung answers whether. Two timers answer how fast: MTTD (mean time to detect — execution to first alert) and MTTR (mean time to respond — alert to first response action). These are common industry operational metrics rather than terms coined in any single standard; the detect-and-respond lifecycle they sit inside is the one described in NIST SP 800-61.4 Verify records them per-technique instead of per-incident — and treats them as undefined, not zero, for any outcome that produced no alert (D0, D1, and a D4 that blocked silently).
A rung without a timer is half an answer. A technique caught at D2 with an MTTD of 30 seconds and one caught at D2 with an MTTD of 6 hours are the same rung and profoundly different risks. The report always shows the pair — rung and time-to.
Section 03Five planes, one gate
The attack platform is described as five planes with a single gate between capability and consequence. Verify keeps that shape and adds the plane that makes it defensive: an Observation plane, in build, designed to ingest the client's own telemetry. The gate is unchanged — the Authorization Gate and the Mangonel engine are the reused, already-live substrate, and Verify fires only real, authorized techniques, so it is bound by the exact same control.
Plane
Responsibility
Reused / new
1 · Consent
The Authorization Gate + multi-party consent (client and, where monitored, the MSSP). No run advances without a signed authorization on file.
Reused
2 · Execution
The Mangonel engine dispatches each technique through the gate. For Verify it runs the safe, marked subset — enough to produce telemetry, never enough to cause impact.
Reused
3 · Observation
Connectors pull events/alerts from the client's SIEM / EDR / XDR (and accept SOC push-confirmations). The attribution engine ties an observed signal back to the technique that caused it.
New
4 · Scoring
Grades each execution on D0–D4, stamps MTTD/MTTR, and aggregates the run into coverage, blind spots, and trend.
New
5 · Reporting
Renders the coverage report — gap list, ladder distribution, timing — white-labeled for the delivering partner.
Adapted
The Observation plane is designed to be read-only into the client's world: it queries detection telemetry and receives confirmations, and by design never writes to, tunes, or silences the client's controls. Verify measures the SOC — it does not operate it. That boundary is what lets the same platform test an MSSP without becoming the MSSP.
Section 04Signal attribution — how Verify knows
This is the section that separates a defensible coverage claim from a coincidence — and it is the core of the in-build Scoring plane. The hard problem is attribution: when an alert appears, was it caused by our fired technique, or by unrelated background noise? Claiming "detected" on a nearby-in-time alert is how a validation tool lies to its customer. By design, Verify refuses to grade above D0 without a positive tie-back.
Every dispatched technique is designed to be stamped with a unique, benign execution marker — a correlation identifier woven into whatever the technique naturally emits (a distinctive process name or command-line token, a canary hostname or account, a tagged user-agent, a synthetic file name). The marker is harmless and does nothing; its only job is to be the fingerprint the client's telemetry can carry. Marker injection is only feasible where the detectable observable is an attacker-controllable field; where it is not (process lineage, fixed-schema EDR events, network-flow shape), attribution falls back to the weaker expected-signal map, and the report surfaces the split between hard-marker and expected-signal grades as a confidence indicator on the coverage number.
Figure 2 — Attribution requires a positive tie-back inside a clock-normalized window — never mere temporal proximity.
Five rules keep the grade honest:
Execution is a precondition — except for prevention. The engine confirms the technique actually ran before any detection grade is assigned; a technique that failed to execute is marked inconclusive, never D0 Blind, because there was nothing to detect. Prevention (D4) is the deliberate carve-out: a blocked technique legitimately never ran to completion, so D4 is graded not from execution but from a positive block/deny event the control emits, correlated to the run's marker or expected-signal map. That is also how the engine tells "prevented" apart from "silently failed for an unrelated reason" (wrong target, tool crash): the former carries a control-generated block signal, the latter carries none and is graded inconclusive, not D4.
Attribution is by marker, not by proximity. A grade above D0 requires the observed signal to carry the technique's marker, or to match its pre-declared expected-signal map. "An alert fired around then" is not evidence — it is exactly the false positive that inflates a coverage score. Because the expected-signal fallback is weaker, it is constrained to run-scoped context a coincidental event cannot satisfy (originating host, process lineage, the run's session/run-id, and the run's benign artifact paths) and is flagged as lower-confidence than a hard-marker grade.
The deadline bounds the timer, not the existence of detection. The window runs from execution (t₀) to a technique-specific deadline (t₀+Δ), with source clocks normalized and a published grace band so skew between the engine, the SIEM, and the EDR cannot fabricate or hide a hit. A real, attributed detection that fires after Δ is still a detection: it is graded D2/D3 with an out-of-window flag and its true MTTD, never demoted to D0.
Silence is a finding, not an error. If the window closes with no attributable signal at all — not merely no signal within Δ — the technique is graded D0 Blind, the single most valuable output of the whole exercise.
Every grade carries its attribution basis. Hard-marker vs. expected-signal, in-window vs. out-of-window, and the detected/total denominator behind any aggregate travel with the number — so a coverage figure can be audited rather than merely trusted.
The failure mode to design against is coverage inflation — a tool that counts unrelated alerts as detections and reports 90% coverage the client does not have. Marker-based attribution plus an execution precondition is the guardrail; it is why Verify would rather under-claim (grade inconclusive) than over-claim.
Section 05Safe execution & the reused gate
Verify is built to fire real techniques at production — that is the whole point; a lab does not tell you whether your SOC is awake. Firing real techniques at production means Verify inherits, without exception, the same Authorization Gate that already governs an attack engagement.
Gate control (reused)
How it binds a Verify run
Signed authorization
A run cannot dispatch without an authorization_ref on the engagement — the same field the attack engine checks.
Scope + platform allowlist
Techniques fire only against hosts under a subscribed, allowlisted apex; anything off-scope is refused, fail-closed.
Rung ceiling
Verify subscribes at a low ceiling by design — it needs the rung that emits a signal, not the rung that causes harm. Destructive tactics stay off.
Named approval + window
Any technique above the passive band requires a named approver and runs only inside the authorized window.
Because the goal is to trip telemetry rather than to break anything, Verify runs the safe, reversible subset of the library: benign markers, read-only or self-cleaning actions, and hard caps. A technique earns its place in the Verify set only if it produces the same detectable signature as its real counterpart while remaining non-destructive.
Test modes — who is told what
Mode
Who knows the window
What it measures
Blind
No one on the blue side
Real-world detection & response as it would actually happen — the truest signal, highest coordination cost.
Coordinated
SOC knows the window
Tooling and rule efficacy with the human variable held constant — faster, ideal for tuning.
Multi-party
Client + MSSP both consent
An outsourced SOC is itself under test; both parties authorize, and the audit trail is shared and tamper-evident.
The MSSP is a subject, not just a channel. When a client's monitoring is outsourced, a Verify run grades the provider's detection. That is commercially sensitive, so multi-party consent and a shared, tamper-evident audit log (§08) are mandatory — the result must be defensible to the party being measured.
Section 06Coverage & scoring model
A run's output is not a pass/fail; it is a coverage map over the ATT&CK matrix.3 Each fired technique contributes one graded cell, and the aggregate answers three questions: how much of the expected attacker behavior would we see, where are the blind spots, and are we getting better over time?
ATT&CK technique (example set)
Grade
MTTD
Read
Valid Accounts T1078
D0 Blind
—
Priority gap — no telemetry on anomalous logon.
Network Service Discovery T1046
D1 Logged
—
Data present; write the detection rule.
Exploit Public-Facing App T1190
D2 Alerted
3m 40s
Detection works; response not yet observed.
Ingress Tool Transfer T1105
D4 Prevented
18s
EDR blocked and logged — strongest outcome.
From the graded cells the Scoring plane derives:
Per-axis rates, not one number — prevention, detection-visibility, and response are reported separately, because they are partly orthogonal. A technique can be silently prevented (D4) with no alert; folding that into a single "coverage" figure would overstate what the SOC can actually see.
Coverage % (per chosen bar) — the share of the run's techniques graded at or above a client-chosen bar (e.g. "detected" = D2+). A D4-without-D2 (blocked but never alerted) does not count toward a "detected" bar — silent prevention is real defense but zero SOC visibility, and scoring it as detection is the sharpest way to inflate the number. Meaningful only against a pinned matrix version (§08), and only at the technique level — a green technique reflects the specific procedure fired, not every variant of it.
Ladder distribution — the histogram across D0–D4. Two clients at 70% coverage are different if one is mostly D2 and the other mostly D4.
Blind-spot list — every D0/D1 technique, ranked — the prioritized detection-engineering backlog and the report's real payload.
MTTD/MTTR trend — per technique across re-runs, so a subscription shows whether tuning actually moved the needle; every aggregate is published with its denominator (n detected / n total) so a shrinking coverage set cannot masquerade as faster detection.
Prevention, detection, and response are orthogonal axes, so Verify never collapses them into one score. A prevented technique still records whether it was also logged and alerted; a silent block (D4, no D2) is reported under prevention and excluded from the detection-visibility rate — because if that control is ever bypassed, a SOC that never saw the technique is blind to it.
The deliverable is a backlog, not a grade. "You are 62% covered" is a headline; "here are the eleven techniques your stack is blind to, in priority order, mapped to the log source that would fix each" is the product. Verify is built to produce the second.
Section 07Productization — OEM & subscription
A penetration test is point-in-time by nature; detection coverage is not. Rules get retired, tools get swapped, staff turn over, and the ATT&CK matrix itself moves — so a coverage number is a perishable good. That single fact makes Verify structurally a subscription, not a one-off, and shapes how it is sold.
Recurring by construction. Detection drifts, so Verify re-runs on a cadence (monthly / quarterly) and reports the delta. The value is the trend line, which only a subscription can draw.
OEM engine, branded report. The Mangonel engine and the grading model are the substrate; the partner firm — an MSSP, MDR, or consultancy — delivers a white-labeled coverage report to their own client. The engine is the OEM part; the report is the product.
Multi-tenant, isolated. Each client is a scoped tenant with its own engagement, connectors, and coverage history — the same per-tenant isolation the client portal already enforces.
Land-and-expand. A first run's blind-spot list is the natural sales motion for detection-engineering work — and the next run proves the fix. The instrument sells the remediation and then validates it.
Verify and the attack service are two ends of one platform: a pentest tells the client where an attacker could get in; Verify tells them, continuously, whether they would see it. Sold together, they cover both halves of the assume-breach posture on a single engine and a single bill.
Section 08Data model, integrity & version pinning
Verify persists onto the same single, normalized SiegePoint database as the attack platform — reusing the engagement, subscription, methodology, run, and audit structures — and adds the entities detection validation needs. Everything is one referential graph, foreign-key enforced.
Entity
Holds
Attaches to
validation_run
One scheduled Verify pass over a coverage set: mode, window, matrix version.
engagement · subscription
technique_execution
One fired technique: marker, executed-at, execution-confirmed flag.
validation_run · methodology
detection_signal
One observed defender event tied back by marker: source (SIEM/EDR/XDR/SOC), kind (log/alert/response/block), observed-at.
technique_execution
coverage_grade
The resolved rung (D0–D4), MTTD, MTTR, and status per execution.
technique_execution
connector
A tenant's read-only integration to a SIEM/EDR/XDR — endpoint, auth reference, query template.
engagement (tenant)
Three integrity properties carry over from, or are sharpened for, Verify:
Tamper-evident audit. The platform's HMAC-chained, head-anchored action log records every dispatch, query, and grade. When an MSSP is the subject (§05), that shared log is what makes the coverage result defensible to the party being measured.
Matrix version pinning. Coverage % is only comparable against a fixed ATT&CK version; techniques and IDs move between releases.3 Every validation_run pins the matrix version so a trend line compares like with like — and when the technique denominator shifts across versions (IDs split, merged, or deprecated), the trend holds the denominator constant or presents a version mapping, so a denominator change never reads as a change in posture.
Connector credentials held outside the record. A connector stores a reference to its auth, never the secret inline — the same secrets-outside-the-database discipline used for the audit key.
What Verify does not claim. A green coverage score is evidence the tested techniques were seen under test conditions — not a guarantee of detection against a novel or deliberately evasive adversary. It measures the controls you have against the behaviors you chose to fire. Stated plainly in every report; never oversold.