Ask what the baseline
compares you against.
Every NDR says it does “baselining”. Almost none of them will tell you what their baseline actually compares you against. These five changes are what ours does — and two of them exist because we went looking for ways our own detector could be wrong, and found them.
Per-entity baselines / Capped risk families / Reported blind spots
Catching more.
And lying less.
Catching more is the half everyone sells. Lying less is the harder half, and it is the one that decides whether a detector survives contact with a SOC: a detector that cries wolf gets muted, and a muted detector may as well not exist.
The mechanism, in the documentationMORE Behavior that used to produce nothing now produces a finding.
LESS One behavior can no longer cast five independent votes.
HONEST A discounted confidence, a capped family and a recovered period each say so on the record.
A fingerprint book per machine,
not one for the building.
When software opens an encrypted connection, the shape of its handshake is a fingerprint. The whole question is what you compare that fingerprint against.
JA4 HANDSHAKE FINGERPRINTS · SCORED PER SOURCE ENTITY · FLEET AS CONTEXT
One fingerprint set for the whole deployment.
A fingerprint counted as novel only if nothing anywhere had ever presented it. So a workstation that suddenly started speaking a Go or Python TLS stack — where some server elsewhere already used that stack — produced nothing at all. That is the actual behavioral tell, and it was invisible.
A fingerprint shared by both browsers and malware was permanently trusted. And the warm-up was so small and so short-lived that the baseline never matured, so it re-alerted on the same benign fingerprints on a rolling daily cycle.
The machine is the baseline. The fleet is context.
Novelty is scored per source entity. Fleet rarity counts how many distinct entities have presented a fingerprint, not how many events — so the fleet informs the verdict instead of erasing it.
Standalone “new to this machine” is deliberately informational, not a command-and-control verdict: a browser point-release, a new VPN client and a software rollout all look exactly like it. It escalates only with a corroborating signal, and a fingerprint that is a close variant of one the machine already speaks lowers the result, as evidence of a benign update.
A separate detector catches a machine presenting many distinct fingerprints in a short window — randomized impersonation, which per-fingerprint novelty cannot see by construction.
The blind spot we report instead of hiding.
A baseline is learn-only until it has both enough observations and enough elapsed time. A newly seen or low-traffic machine therefore produces no fingerprint finding at all: its baseline reports “still learning” rather than guessing. That is a real blind spot on exactly the machines most likely to be newly planted, and it is reported as a learning state rather than hidden behind silence. A JA4 does not identify a program, device, person, malware family or adversary, and we do not claim that it does.
One burglar, five witnesses,
one alarm.
Several shipped detectors watch the same underlying behavior from different angles. Add their scores together and one behavior gets ranked as if it were many.
FAMILIES: FINGERPRINT · TEMPORAL · DESTINATION · VOLUME · DNS · SIGNATURE
Five descriptions of one behavior, summed.
A periodic callback keyed by destination IP, and the same callback keyed by resolved domain. Two overlapping long-connection measures. A high-connection-count measure over the same series. Several DNS measures over one query stream. Client and server handshake rarity on one handshake.
The risk score added all of them as if they were independent evidence, so one behavior could post five contributions and trip the incident threshold on its own.
Each family contributes once, and the cap is visible.
Detectors are grouped into signal families — fingerprint, temporal, destination, volume, DNS, signature — and each family’s contribution to an entity’s risk is capped. The property that buys: no single behavior, however many detectors describe it, can alone trip an incident, while two genuinely independent behaviors still can.
An incident reports the per-family breakdown, so an analyst sees which behavior was capped rather than only a smaller number. A detector that is not in the map keeps its old weight, so nothing silently lost influence.
The guard tells you
his camera was fogged.
Cernity already detected a sensor dropping packets at capture or gone blind to the application layer, and raised a separate health finding so “no findings” was never read as “no threat”. That was the hard half, and it was already right.
SENSOR VISIBILITY VERDICT · APPLIED WHERE A CANDIDATE BECOMES A FINDING
Full confidence from a fogged camera.
The health finding went out. But the findings produced during that degraded window also went out — at full confidence, as if the view had been perfect.
The verdict travels with every finding.
The service that measures sensor visibility publishes that verdict on every measurement, including recovery, and it is applied at the single point where every candidate becomes a finding.
Three honesty rules come with it. “Not measured” is not “healthy”: an unmeasured sensor’s findings are untouched, and a stale measurement decays to unknown rather than to good. Severity is never changed — only confidence — so degraded visibility can never quietly move a real finding out of delivery. And the original confidence, the factor applied and the reason codes are all kept on the finding, so nothing is silently rewritten.
Because the same service raises the health finding and publishes the quality verdict, confidence can only ever be discounted for a sensor that is simultaneously raising a health alert. A broken sensor cannot be made to look secure.
A dripping tap
with some drips missing.
Malware that phones home on a schedule is caught by measuring the gaps between connections and checking they are regular, using outlier-robust statistics. Then the laptop goes to sleep.
PRIMARY: ROBUST INTERVAL STATISTICS · FALLBACK: BINNED AUTOCORRELATION
A skipped beat read as irregularity.
The interval measure degrades when callbacks go missing — a laptop asleep, a dropped packet, a network outage — because a skipped beat turns one gap into twice the period, and a distribution measure reads that as irregularity rather than as a gap.
A one-in-three drop rate alone was enough to push the score below its own firing threshold. The beacon was still beating; the measure had stopped hearing it.
Ask whether the beats line up with themselves.
When the gap measure does not fire, periodicity is re-checked a different way: by autocorrelating a binned event series — asking whether the connections line up with themselves one beat later.
A missed beat is then a missing sample rather than a wrong interval, and the beats that did arrive still line up. The finding records which method found it and the period it recovered.
What autocorrelation does not do.
It finds a dominant period. It does not prove command-and-control — schedulers, update checks and health probes are periodic too, which is why this stays a fallback behind the primary measure rather than a detector of its own. It is also not a general answer to jitter: randomizing each sleep interval walks the beacon’s phase out of step with itself, so past roughly fifty percent per-interval jitter the correlation decays along with it, and the robust interval statistics often serve that case better. The jitter problem is not solved.
The receipt bug that was
inventing data theft.
Suricata reports a connection’s byte count as a running total — “100 MB so far”, then “500 MB so far”, then “900 MB so far”. Cernity was adding those together.
LATEST CUMULATIVE VALUE PER CONNECTION IDENTITY · SUMMED AT THE THRESHOLD
900 MB counted as 1,500.
A connection that moved 900 MB could be counted as 1,500. And because the message bus delivers at least once, a service restart re-read records it had already counted and added them a second time.
Cernity flags a large enough outbound transfer as possible exfiltration. So ordinary backup traffic got inflated past that line and a false “someone is taking your data” finding was manufactured — and the duplicate-suppression then worked perfectly, which made it worse: the result was one clean, confident, entirely wrong alert. That is the worst shape a false positive can take.
Store the latest total. Sum it at the threshold.
The accumulating counters are gone. Each connection’s latest running total is stored against that connection’s own identity, and the total is summed when the threshold is checked. Reading the same record twice changes nothing, and a later running total simply replaces the earlier one.
Where the number of connections to a single destination exceeds its ceiling, the total is reported as a floor with the count of omitted updates attached — never silently truncated.
The part a datasheet
leaves out.
Stated here because it is the differentiator, not the disclaimer. A baseline you cannot interrogate is a baseline you cannot defend in an investigation.
What these five changes do not establish
- A handshake fingerprint does not identify a program, device, person, malware family or adversary. It describes the shape of a handshake, and that is all it is used for.
- A per-entity baseline is learn-only until it is ready, so a newly seen or low-traffic machine produces no fingerprint finding at all and its baseline reports “still learning”. Silence there is missing coverage, not a clean result.
- A recovered period is not proof of command-and-control. Schedulers, update checks and health probes are periodic too, and heavy per-interval jitter still defeats the correlation.
- Capping a signal family lowers how much one behavior can contribute to risk. It does not measure precision, recall or false-positive rate — those come from analyst dispositions, reported separately.
- Visibility-weighted confidence changes confidence only, never severity. It does not make a degraded sensor’s coverage complete, and it never reinterprets an unmeasured sensor as a healthy one.
- A reported floor is a floor. When the per-destination ceiling binds, the total is published with the count of omitted updates attached rather than presented as the truth.