What Cernity ships: the capability overview
Cernity is a self-hosted, middle-tier NDR. Stock Suricata sensors emit EVE over a Kafka-compatible bus to central services — a normalizer, a set of detectors (behavioral, DNS, protocol, east-west, OT, anomaly, threat-intel), a finding-service, correlation, and an asset-service — which produce deduplicated findings carrying explicit evidence. Findings export to your existing SIEM, and analysts work in Cernity Vantage, the native console. It is multi-tenant and needs no mandatory cloud control plane.
This page is the overview of what is shipped today. Where a capability is verified end to end in a full deployment versus present in code, we say so. Roadmap items are listed as roadmap at the bottom — they are not available yet.
1. Fleet management & sensor health
A central sensor registry records each sensor’s identity, tenant, site, tags, groups,
declared capabilities, versions, and last-seen time. Sensors send sensor-health.v1 heartbeats
carrying CPU and memory, capture drops, EVE rates, ingest backlog, disk, connectivity, running
versions, and clock offset. A read-only fleet API lists the fleet and flags clock skew
so a drifting sensor cannot silently corrupt time-ordered evidence.
The registry and health telemetry are the operational backbone: they tell the SOC which sensors are healthy, which are dropping packets, and which are out of sync. See fleet management for the registry model, heartbeat fields, and the API.
2. Canonical evidence plane
Every source is normalized into one observation.v1 record, exposed as a unified view over
typed records — connection, DNS, TLS, and HTTP. Each record carries capability flags that
declare exactly what its source supports, so an evidence-poor source never fabricates a field it
did not actually observe. A read-only evidence query API lets you pivot from a finding to its
underlying normalized observations by entity, time window, or record type.
The baseline is Suricata-derived plus central derivations; continuous Zeek is an optional mode, not a prerequisite. See the evidence plane for capability flags and the query API.
3. Retroactive packet capture
A bounded, budgeted pre-trigger rolling packet buffer runs on the sensor. Paired with
capture-request.v2, it lets packets from before and around a finding be preserved after the
fact — you do not have to have known in advance that a flow would matter. Preserved packets are
stored under tenant-safe object keys with authenticated, audited retrieval.
This is shipped in code. Live end-to-end preservation is verified in a full deployment; the mechanism and its budget controls are described in the evidence plane.
4. Native, explainable anomaly detection
Cernity ships an explainable outbound-bytes anomaly detector. It scores an entity against two baselines: the entity’s own rolling baseline and a deterministic peer-cohort baseline. Every anomaly finding carries its explanation — the features that fired it, both baselines, the cohort it was compared against, and the model and version — never a bare score. It uses robust statistics first, not opaque ML. See explainable anomaly detection.
5. Cernity Vantage — the analyst workspace
Vantage is a queue-centric native console: an investigation queue with triage tiers
(threat, lead, low-signal, observation, allowlisted), a benign allowlist, an Overview
health and telemetry dashboard, a findings browser, raw-EVE pivots, and fleet-health and
evidence-pivot views. Analyst dispositions and allowlist decisions feed a tuning loop
(disposition.v1 → feedback-service → anomaly ground-truth, false-positive suppression, and an
ignore-list) — every entry owner-attributed, justified, expiring, and audited, and offered as a
suggestion, never an automatic silent change. See
the analyst workflow with the console screenshots.
6. Trust & deployment posture
Multi-tenant isolation runs across the APIs and stores; packet objects use tenant-safe keys; findings export to your existing SIEM (keep-your-SIEM); the whole system is self-hosted with no mandatory cloud control plane.
7. Threat intelligence — a managed indicator lifecycle
Cernity ships a managed threat-intelligence lifecycle, not a raw feed dump. It ingests indicators from STIX/TAXII 2.1, MISP, and HTTP(S) feeds (abuse.ch built in), then normalizes, scores, expires, and suppresses them with preserved provenance, TLP handling, and per-feed source-trust — a low-trust feed cannot override a high-trust indicator. Live matching across IP / domain / URL / JA3 / JA4 / certificate attaches the matched indicator and its provenance to a finding. Retrospective hunting replays indicators against the observation history and records both when the traffic was observed and when the indicator was learned. File-hash and URL hunting remain roadmap (pending a file-evidence source). See threat intelligence.
8. Detection coverage & quality
Vantage surfaces two operational views over detection itself. An ATT&CK coverage view shows which techniques have detectors, fleet-wide coverage plus per-tenant observed firings, with gaps highlighted. A production detection-quality view computes per-detector precision and false-positive rate from analyst dispositions, alongside a separate advisory allowlist rate. These describe what the platform measures from real analyst decisions — they are operating telemetry, not a guarantee of any particular detection rate. See detection coverage.
9. Case management
Analysts work multi-finding investigations as cases in Vantage: ownership and assignment, an explicit status lifecycle (new → investigating → resolved → closed), analyst notes, and the ability to link multiple findings and entities into one case. The whole thing is fully audited, so who did what and when is always recoverable. See the analyst workflow.
Detection catalog
See the manifest-derived detection table for detector inventory, status,
ATT&CK mappings, and the available evidence metadata. Detector coverage is maintained in the
manifest rather than a separate list of claims here. A shipped detector is not automatically
verified_e2e, and experimental work is not a shipped guarantee. See
coverage boundaries for deployment limitations.
Roadmap — not available yet
These are planned and are not claimed as shipped:
- File-hash and URL retrospective hunting (pending a file-evidence source).
- YARA and file-inspection productization.
- Cloud and flow-log sensors.
- Remote policy rollout and coordinated upgrades/rollback.
- Verified producer identity and secure-bus hardening.
- Full entity temporal-timeline durability.
- Natural-language query.
Honest boundaries
- A shipped capability still depends on the fields your sensors collect, the services you run, and your configuration — see capability dependencies.
- Retroactive PCAP is shipped in code; live end-to-end preservation is verified in a full deployment, not asserted for every environment.
- TLS logging is not decryption. Cernity exposes what the traffic reveals, not payload it cannot see.