Architecture / custody record

PUBLIC BOUNDARY
PRIVATE IDENTITY
EVIDENCE PLANE
OPERATOR CONTROL

The system is a replay,
not a diagram.

Follow one incident from source event to operator decision.

live custody shell
CASE-2047 / REPLAY

$

> 04 source events

Inbound queue

ID signin.risk 12:04:11
EDR process.spawn 12:05:36
CLD role.change 12:07:02
MSG sender.match 12:09:44

source-native

Signed envelope

{

tenant_id: attached,

source_table: attached,

observed_at: attached,

raw_payload: attached,

}

signature verified

Evidence window / 15m

Identity--
Endpoint--
Cloud--
Message--

3 relationships agree

Operator case

.87

INC-2047

Identity, endpoint, and cloud agree.

recommended next move

Review evidence route

human approval required

EVT-2047.1 Receive
Custody ledger
evidence custody intact
owner / northstar
streaming

01

Live

PostgreSQL record layer, organization/domain creation, audit events, signed API identity, tenant-scoped realtime.

02

Implemented

Connector routes, telemetry envelopes, worker processing, graph rebuild, deterministic overnight hunts, breach-and-attack Test Fire, governed automation playbooks, and operational observability over the same telemetry.

03

Needs proof

ClickHouse and Neo4j should be validated under production-like tenant volume before being treated as default infrastructure.

System map

Move through the boundaries.

follow the boundary

$

> public route selected

SIGNED ENVELOPE tenant_id source observed_at raw_payload audit_id

Operating lifecycle

Identity to decision.

01

Qualify

Named business email, tenant owner, organization boundary

02

Authorize

Azure app registration, Sentinel workspace, Defender permissions

03

Ingest

Connector API validates source payloads and emits normalized envelopes

04

Process

Workers normalize, score, enrich, and write evidence; the same telemetry doubles as operational health

05

Prove

Overnight hunts leave a ledger and Test Fire scores which detectors actually fire on a simulated attack

06

Investigate

Console reads incidents, assets, telemetry, graph paths, and audit history

07

Approve

Response actions and playbook steps require role checks, evidence, and audit records

Data plane

A store for each job.

Active system of record

PostgreSQL

+ tenants
+ users
+ domains
+ assets
+ incidents
+ response_actions
+ audit_events

REST queries for current operational state

Scale telemetry path

ClickHouse

+ beacons.telemetry_events
+ source table
+ observed time
+ raw payload
+ normalized fields

High-volume event search and time-window analytics after deployment proof

Optional graph engine

Neo4j

+ User
+ Device
+ Process
+ File
+ Email
+ Cloud Resource
+ IP
+ Domain

Attack paths, neighbors, entity relationships, and NDR graph views when populated

Read and write paths

Every path stays traceable.

Primary contracts

POST /v1/telemetry

Persist normalized telemetry and merge graph entities

GET /v1/organizations/current

Resolve workspace setup and tenant context

POST /v1/organizations

Validate business email, create organization boundary, queue domain claim

GET /v1/ndr/graph

Read relationship graph, preferring Neo4j when populated

POST /v1/chaos/runs

Fire a breach-and-attack simulation and score which detectors actually fired

POST /v1/hunt-ledger/runs

Run deterministic overnight checks and record proof of work

POST /v1/automation/runs

Start a versioned playbook run, gated at approval before destructive steps

GET /v1/observability

Project the same telemetry as operational health without new collection

GET /api/beacons/[...path]

Console proxy route with session, tenant headers, and signed API identity

Telemetry envelope

{ tenant_id, source, source_table, event_type, observed_at, raw_payload, normalized_fields, entity_ids, severity, tags
} 

Every event keeps source provenance so an incident can be traced back to the system that produced it. Normalization adds shape without erasing the original evidence.

Connector model

Connector boundaries stay explicit.

Phase 1 focuses on Microsoft Sentinel incidents and alerts, Defender for Endpoint device/process/file/logon events, and Defender XDR evidence across identity, cloud apps, and email. UI state is not treated as proof of connector readiness; environment configuration and validation are.

Begin private onboarding

AZURE_TENANT_ID

Required for production connector validation

AZURE_CLIENT_ID

Required for production connector validation

AZURE_CLIENT_SECRET

Required for production connector validation

SENTINEL_SUBSCRIPTION_ID

Required for production connector validation

SENTINEL_RESOURCE_GROUP

Required for production connector validation

SENTINEL_WORKSPACE_NAME

Required for production connector validation

Production controls

Controls before claims.

Control plane rule

Every production claim should map to an enforced boundary, not a decorative badge.

01

Access

Company email, signed web-to-API identity, tenant-scoped API context, role-aware workflows.

02

Audit

Organization creation, connector authorization, response actions, and admin changes produce reviewable records.

03

Observability

Live views prefer real connector state. Demo data is labeled and intentionally separate from production posture.

04

Separation

Website analytics, console sessions, customer telemetry, metadata, and graph relationships remain distinct concerns.

Privacy controls

Your visit should be as controlled as your telemetry.

We use necessary cookies to keep the site working. Optional analytics help us understand which product pages are useful. Marketing cookies stay off unless you allow them.