User Guide
Connecting Your Telemetry
Before Verify can grade whether your monitoring saw an attack, it has to observe what your stack recorded. This page explains what Verify connects to, the strict read-only boundary that keeps it a measurement and never an operation, and how a fired technique is tied back to an observed signal so a grade is defensible rather than a guess.
In build Verify connectors, scoring, and reporting are being scaffolded. The client portal is Live at siegepoint.apintelligence.ai/portal, and the underlying attack engine is built and self-tested, but the observation plane described here is intended behavior, not yet a running integration. Everything below tells you how it is designed to work so you can plan the connection.
What Verify observes, and what it will never touch
Verify sits on the Observation plane — the third of five planes it runs through, between Execution and Scoring. Its job on this plane is narrow and one-directional: pull events and alerts out of your SIEM, EDR, or XDR, and accept push-confirmations from your SOC. That is the entire footprint.
The boundary is deliberate and absolute. Verify measures the SOC; it does not operate it. It never writes to, tunes, or silences your controls. It does not create rules, close alerts, quarantine hosts, or push configuration. If Verify could change your defenses, its own measurement would be contaminated — a coverage report is only meaningful if the thing being graded is exactly the stack you run every day. Read-only is not a courtesy setting; it is what makes the result trustworthy.
Think of it as a light meter, not a light switch. Verify reads how much your monitoring lit up when a technique fired. It has no wiring to the switch.
Two ways Verify can see
You can connect telemetry in either direction, or both. Neither requires Verify to reach into your controls.
1. Read-only connectors (Verify pulls)
A connector is a per-tenant, read-only integration into your SIEM, EDR, or XDR. Verify queries it for the events and alerts produced during a validation window and reads them back. The connector's credential is held by reference, not inline — Verify stores a pointer to a secret, not the secret itself embedded in a record — so the authorization to read your telemetry can be rotated or revoked without touching Verify's data. Each connector is isolated to its own tenant; nothing crosses between clients.
2. SOC push-confirmations (your side pushes)
Where a direct read-only pull is not available or not wanted, your SOC can push confirmations to Verify instead: "we saw this, we alerted at this time, we responded here." This keeps you in control of what leaves your environment while still giving Verify the signals it needs to grade. Push-confirmations and connector pulls are graded the same way and can be mixed.
Connector types and build status
The following integration surfaces are defined for the Observation plane. Status reflects the current build honestly — the observation plane is being scaffolded and no connector is Live yet.
| Integration | What it provides | Direction | Status |
|---|---|---|---|
| SIEM connector | Log events and correlated alerts from your central log platform | Verify pulls (read-only) | In build |
| EDR connector | Endpoint telemetry, detections, and prevention/block events | Verify pulls (read-only) | In build |
| XDR connector | Cross-surface detections and correlated response actions | Verify pulls (read-only) | In build |
| SOC push-confirmation | Analyst- or SOAR-sourced confirmations of log / alert / response / block | Your SOC pushes | In build |
Each observed item is recorded as a detection signal with its source, its kind — a log, an alert, a response, or a block — and the time it was observed. Those signals are the raw material the Scoring plane grades against the Detection Ladder.
How a signal becomes a defensible grade
The reason Verify can say "your SOC saw this" rather than "something alerted around then" is signal attribution. This is the soundness core of the whole service, and it is worth understanding before you connect anything.
Every technique Verify fires carries a unique, benign execution marker woven into what that technique naturally emits — a distinctive process or command token, a canary host or account, a tagged user-agent, a synthetic filename. A grade above D0 requires a positive tie-back: the observed signal your connector returned must carry that marker, or match the technique's pre-declared expected-signal map, inside a bounded, clock-normalized time window.
The two timers stamped per technique — MTTD (execution to first alert) and MTTR (alert to first response) — are also derived from attributed signals. A rung says whether your SOC saw it; the timer says how fast. They are always reported as a pair. See the Detection Ladder for how the rungs and timers work together.
Why the connection is read-only and by reference
Two design choices on this plane protect both the integrity of your result and the security of your environment:
- Read-only into your world. Verify inherits the same fail-closed Authorization Gate the attack side uses, and the observation plane has no write path at all. It cannot alter the controls it is grading.
- Auth held by reference. Connector credentials live as references, not as secrets copied into Verify's records. You can rotate or revoke access independently, and a Verify data export never carries your live telemetry credentials.
The connector integration itself is per-client isolated in a multi-tenant design, and all activity is written to the same tamper-evident, HMAC-chained audit trail used across the SiegePoint platform, so the record of what was read and when is itself verifiable.
Coordination modes affect what you connect
How you run a validation changes who knows the window is open, but not the read-only boundary:
- Blind — your blue team is not told the window. Truest signal, highest coordination cost. Push-confirmations here come after the fact.
- Coordinated — your SOC knows the window, which measures tooling and rules with the human held constant. This is the mode best suited to tuning, and where live push-confirmation is most natural.
- Multi-party — both you and your MSSP consent, because the outsourced SOC is itself the subject. Connectors and confirmations may come from both sides, over a shared tamper-evident audit.
An honest limit to keep in view
A strong coverage result is evidence that the tested techniques were seen under test conditions. It is not a guarantee against a novel or deliberately evasive adversary. Verify measures the controls you have against the behaviors you chose to fire — no connector, however complete, changes that. This limit is stated in every report, and it is why coverage is re-run on a subscription cadence rather than certified once.
For the full five-plane model and the data entities behind connectors, signals, and grades, see /verify-architecture-guide.html. For the broader platform, see the SiegePoint user guide.