Security Operations
System9 runs security operations on the same governed substrate as the rest of the platform, rather than shipping telemetry to a separate analytics product and losing the identity, classification, and audit context on the way. A security event is governed data: catalogued, classified under the same ladder, and recorded on the same tamper-evident ledger as everything else.
This section documents the streaming and correlation surface. It is scoped deliberately, and the scope is stated on every page.
The pipeline
Figure: the security-operations pipeline. Events are normalized to an open event schema (OCSF), correlated with open, portable rules (Sigma), and written to the tamper-evident activity ledger; the aggregator's inbound and outbound paths sit behind a fail-closed gate (amber, dashed).
Table equivalent
| Stage | What it is | Scope note |
|---|---|---|
| Ingest | Security events emitted by platform services | Governed like all data |
| Normalize | Mapped to OCSF, an open event schema | Not a closed, proprietary format |
| Correlate | Matched with Sigma, open portable rules | No detection catalogue is published |
| Aggregate | Inbound/outbound aggregation | Behind a fail-closed gate |
| Record | Written to the activity ledger | Same tamper-evident chain as every governed action |
In this area
- Threat detection. OCSF events and Sigma rules, and the honest boundary around UEBA and DLP.
- Incident response, response actions written to the record, and the cross-domain enforcement roadmap.
The shape of it
- Open on the wire. Events are normalized to OCSF and detections expressed as Sigma, so the platform is not a closed detection black box.
- Governed like all data. A security event is subject to the same classification ladder and the same governed reads as any other record.
- On the tamper-evident record. Correlation and response actions are written to the activity ledger alongside every other governed action.