Detection coverage, and where its boundaries are
Cernity is a middle-tier NDR: it adds central analytics and finding delivery on top of Suricata telemetry. This page describes the detection coverage that ships and where its boundaries are. Which layers produce findings in your deployment still depends on the fields your sensors collect, the services you run, and your configuration.
What Suricata already provides
Suricata tracks state, parses protocols, applies signatures and other rule conditions, and emits useful telemetry — classifications, priorities, connection metadata, and flow-correlation identifiers. Cernity does not replace that; it consolidates Suricata’s alerts into findings and adds detection layers Suricata does not perform on its own.
Manifest-derived detection catalog
The generated detection table is the source of truth for detector inventory, status, and declared ATT&CK techniques. It renders one row per detector from the vendored manifest payload rather than maintaining a second inventory here.
experimental is not a shipped guarantee; shipped does not imply verified_e2e.
Technique mappings do not guarantee that every instance will be detected. The current payload
lists input records but does not declare evidence produced; the table makes that absence explicit.
Roadmap capabilities remain unavailable until their status changes in the authoritative source.
ATT&CK coverage and detection quality
Coverage is only meaningful if you can see it, so Cernity surfaces two views over detection itself in Vantage.
An ATT&CK coverage view maps detectors to MITRE ATT&CK techniques: which techniques have a detector, fleet-wide coverage, and per-tenant observed firings, with gaps highlighted so a technique nobody is detecting does not hide behind one that is. Coverage means a detector exists for the technique — not that every instance of it will be caught in your traffic.
A production detection-quality view reports, per detector, a precision and
false-positive rate derived from real analyst dispositions, plus a separate advisory
allowlist rate. These are computed from the tuning loop
— the same disposition.v1 decisions analysts already make — so quality reflects what your analysts
actually judged, not a vendor benchmark. It is operating telemetry about a detector’s behavior in
your deployment, not a guarantee that any detector will hit a particular precision.
What raw Suricata does not do, that the pipeline does
- Consolidation & dedup. Related detections consolidate into deduplicated findings with explicit evidence, instead of flooding the SIEM with duplicates.
- Cross-detector correlation onto an entity, and asset resolution through the asset-service.
- Per-entity baselines, not one global allowlist. A TLS client fingerprint (JA4) is judged against that source entity’s own history, with how many distinct entities in the fleet have ever presented it as context. A fingerprint that is ordinary somewhere in the fleet is still a change on the host that never spoke it before. Fingerprint evidence alone is deliberately informational: a new fingerprint on an entity is what a browser update, a new VPN client or a software rollout looks like, so severity rises only with a corroborating signal, and a JA4 is never treated as identifying a program, device or adversary.
- Risk that does not double-count one behavior. Detectors are grouped into signal families (fingerprint, temporal, destination, volume, DNS, signature) and each family’s contribution to an entity’s risk is capped. Several of the shipped detectors read the same underlying series — a periodic callback keyed by IP and by domain, overlapping long-connection measures, several DNS measures over one query stream — and summing them would rank one behavior as if it were many independent ones. An incident reports the per-family breakdown, so you can see which behavior was capped rather than only a smaller number.
- Beaconing survives missed callbacks. A beacon is scored first on the regularity of its inter-arrival intervals using outlier-robust statistics. That measure degrades when callbacks go missing — a host asleep, a dropped packet, a network outage — because a skipped beat reads as one interval at twice the period rather than as a gap. So when the interval measure does not fire, periodicity is re-checked by autocorrelating a binned event series, where a missed beat is a missing sample instead of a wrong interval. The finding records which method found it and the recovered period. This finds a dominant period — it does not prove command-and-control, since schedulers, update checks and health probes are periodic too, which is why it stays a fallback rather than its own detector. It is also not a general answer to heavy jitter: randomizing each sleep walks the beacon’s phase, and past roughly ±50% per-interval jitter the correlation decays with it.
- Aggregates are replay-safe. Outbound-byte totals, connection counts and cumulative session time are derived by summing each flow’s latest cumulative value keyed by flow identity, rather than accumulating a counter. Suricata’s flow byte and age counters are cumulative per flow, and the bus delivers at least once — so an accumulating counter double-counted a redelivered record or a second interim record for the same flow, and an inflated total could push benign traffic over a transfer threshold and manufacture a finding. Per-flow identities are capped per pair; when that cap binds, the total is reported as a floor with the refused-write count attached, never silently truncated.
Finding lifecycle states (e.g. CANDIDATE → FINAL), monotonic revisions, and a
severity/threat gate that suppresses low-value findings while retaining them for correlation and
audit are roadmap, not shipped guarantees.
See how Cernity works for the full flow and the capability overview for how these fit together.
What your existing stack still owns
- The physical or virtual traffic mirror and its coverage.
- Suricata operation, parser configuration, rules, and packet-loss monitoring.
- SIEM ingestion, retention, field parsing, analyst searches, and case management.
- Asset ownership, identity, endpoint evidence, and the business context needed to assess intent.
A per-entity baseline has a cost you should plan for: JA4 novelty is learn-only until an entity’s baseline is ready, which requires both a minimum number of observations and a minimum elapsed span. A newly seen or low-traffic entity therefore produces no JA4 finding, by design — not because it is clean. The baseline expires after a period of inactivity rather than on a fixed schedule, so a host that keeps talking keeps its baseline. Both thresholds are configurable.
Cernity does not make TLS contents visible without the necessary observation or decryption arrangement, prove that every absence is benign, or establish compromise from a category label. An absence claim needs a defined search scope and a functioning collection path — which the fleet health telemetry helps you confirm.
Not shipped yet
File-hash and URL retrospective hunting (pending a file-evidence source), YARA/file productization, and cloud/flow-log sensors are roadmap, distinct from the shipped detection layers above. What does ship is the threat-intel lifecycle, live matching across IP / domain / URL / JA3 / JA4 / certificate, and retrospective hunting on IP / domain / JA3 / JA4 / certificate — see threat intelligence. Retrospective hunting on URL and file hashes does not ship; it stays roadmap with the file-evidence items above, even though live URL matching ships. Do not treat the roadmap items as available.
How to evaluate it fairly
Compare identical source input with explicit rules, settings, and SIEM parsing. Count raw records, alerts, documents, revisions, and finding identities separately. Include benign controls, missing enrichment, suppression, and delivery failures. The practical question is whether the added findings and context improve your analysts’ decisions at an acceptable operating cost — see the published records for demonstrated mechanisms and their limitations.