Operator reference
Console documentation
This is the operator reference for the 1000 Beacons console: what each route is for, how work moves through the product, which permissions apply, and where a surface is finished versus scaffolded. Read it as a field manual for people who will actually open cases, approve actions, and configure tenants — not as marketing copy.
What 1000 Beacons is (and is not)
1000 Beacons is a security observability and operations console built first for organizations that already run Microsoft Sentinel and Microsoft Defender XDR. Connectors pull source-native telemetry and incidents into a tenant-scoped control plane. Events are stored as telemetry envelopes that keep both the raw vendor payload and a normalized shape. Detections, hunts, and correlation then produce findings that can open or enrich shared incidents. Operators investigate those cases, request containment when needed, and approve high-impact changes before anything reaches a production executor.
The product is deliberately not an autonomous SOC and not a second SIEM that replaces your Microsoft stack. It does not silently isolate endpoints, disable accounts, revoke sessions, or block egress because a model scored an event highly. Detection and Hunt Ledger may open cases and propose follow-up (today, typically a ticket). Automation may run enrich and condition steps, then pause at approval gates before any destructive action. Confidence and severity are separate fields: a high-severity, low-confidence signal must remain visibly uncertain.
If you are evaluating the console without live connectors, use Evaluation mode intentionally. It is labeled synthetic. Live mode that cannot reach the control plane shows empty or unavailable states — it does not invent a healthy tenant behind a failed API call.
How the console is organized
After authentication, the shell presents three navigation groups. Operate is the morning and shift queue: Command Center for pressure, Incidents for case work, Hunt Ledger for overnight hunting proof, Chaos Engineering for breach-and-attack proof that detectors actually fire, and Assets for entity inventory. Investigate is domain depth . NDR, EDR, Email, SaaS, Identity, Cloud, UEBA, Infrastructure Map, and Observability (operational health over the same telemetry) . all reading the same custody path rather than separate alert products. Configure is policy and tenant control: Detection Content, Detection Engineering, Integrations, Automation, Workspace, and Admin.
Global chrome (search, time range, notifications, user menu) sits above those destinations. Role baselines and workspace grants hide routes the principal cannot use. A Super Admin on the platform Access Review queue does not receive tenant SOC navigation at all; middleware redirects them away from Incidents, Hunt Ledger, telemetry, and Configure surfaces that require tenant membership.
| Group | Primary destinations | Question the group answers |
|---|---|---|
| Operate | Command Center, Incidents, Hunt Ledger, Chaos Engineering, Assets | What needs attention, what did we check overnight, do the detectors actually fire, what entities do we know? |
| Investigate | NDR, EDR, Email, SaaS, Identity, Cloud, UEBA, Infrastructure Map, Observability | What does this domain’s evidence say about this case or entity, and is the pipeline itself healthy? |
| Configure | Detection Content, Detection Engineering, Integrations, Automation, Workspace, Admin | What rules, connectors, playbooks, and tenant policy govern the console? |
The shared custody path (read this once)
Almost every Investigate and Operate surface is a specialized view over one path. Understanding that path prevents the false assumption that EDR “owns” a different alert lake than Identity or that Hunt Ledger invents a second SOAR product.
Source telemetry arrives through a connector or ingest path. The control plane stores a TelemetryEnvelope with tenant id, observed and ingested timestamps, source connector kind, source table, entity identifiers, severity, confidence, raw payload, normalized fields, and provenance (real, synthetic, replay, or test). Versioned detections and deterministic hunts produce findings that cite evidence event ids. Findings may open or attach to incidents. Response actions and Automation steps that change production state wait for an approval receipt before executors run.
- Ingest → envelope with raw + normalized + provenance
- Detect / hunt → findings with evidence event ids
- Correlate → shared incidents (cases)
- Respond → request → approve → execute → audit (optional rollback)
How to use this documentation set
Start here for orientation, then read Concepts (custody, Hunt Ledger vs Automation, approval, evaluation, RBAC) before diving into individual Operate or Configure pages. Each page names the console route when there is one, explains the job of the surface in prose, describes what you actually do there, lists permissions that matter, and ends with boundaries — including scaffolded Workspace sections and guide-first connectors.
When a page says a control is scaffold, interactive, or evaluation-local, believe it. Those honesty labels are part of the product contract with operators and auditors.