What did the sensor actually observe? What did Cernity infer? Follow seven saved test scenarios, compare the records, and learn what to investigate before calling something a threat.
BEFORE YOU BEGIN
A log entry is not automatically an alert.
A flow event describes a connection. An alert records a rule match. A finding is a detection system's assessment. A SIEM document is the stored record of any of those things.
Derived findings, including revisions and unsuccessful enrichment.
This benchmark retained raw baseline telemetry for comparison. In your deployment, raw Suricata logs appear in the SIEM only if you configure that ingestion path. Cernity's findings forwarder does not forward all raw EVE records.
A connection is a fact. A beacon is an interpretation.
A test host repeatedly contacts the same destination. A single connection looks ordinary; the regular spacing across connections is the behavior being evaluated.
Saved run: final-beaconCompletion: reconciled
SURICATA → SIEM
20 flow records · 0 alerts for this pair
Selected flow record · original exported document body
These are complete selected document bodies from saved SIEM exports, pretty-printed without changing values. The escaped entities string is preserved exactly as a string. Search-result wrappers such as an Elasticsearch _index or _id were not retained in these exports and are not reconstructed here.
All 3 matching Cernity documents are included in the download, including distinct IDs and revisions.
WHAT CERNITY ADDED
Cernity calculated the pattern across flows. The selected finding describes 20 connections with a five-second interval and zero measured jitter. It is one of three beacon findings as the window developed, not the only finding in this run.
Read the records
event_type: flow
Suricata is describing a connection, not raising an alert. A stored flow record is still useful evidence.
src_ip / dest_ip / dest_port
10.0.0.5 contacted 203.0.113.66 on port 443. The port alone does not establish HTTPS, benign traffic, or encryption.
flow.bytes_toserver: 253
This selected connection sent 253 counted bytes toward the server. This is not the byte total for all 20 connections.
interval_s: 5 / jitter_s: 0
Cernity measured regularity across connections. Jitter describes variation in spacing; zero means the measured intervals were uniform.
category: c2 / mitre: T1071
The detector categorized the behavior as a command-and-control lead and mapped it to Application Layer Protocol. A label is not proof of an attacker.
confidence: 1 / evidence_refs: []
This is an emitted detector score, not a calibrated 100% probability. No packet evidence references are attached to this finding.
What this does not establish
The complete baseline has 17 engine-liveness control alerts on other activity, so “zero alerts” applies to this IP pair only. The complete Cernity export contains eight documents, including five background suspicious-user-agent findings. Replay shifted the capture clock; compare flow.start using the recorded replay offset, not SIEM ingestion timestamps. The selected source record’s top-level timestamp differs from flow.start; both are preserved rather than silently corrected.
This test deliberately installed a custom Suricata signature, SID 9000003. Suricata already recognized the test traffic. The question is whether Cernity preserves the evidence and consolidates repeated detections.
Saved run: preservation3Completion: reconciled
SURICATA → SIEM
45 matching signature alerts
Selected alert record · original exported document body
These are complete selected document bodies from saved SIEM exports, pretty-printed without changing values. The escaped entities string is preserved exactly as a string. Search-result wrappers such as an Elasticsearch _index or _id were not retained in these exports and are not reconstructed here.
All 2 matching Cernity documents are included in the download, including distinct IDs and revisions.
WHAT CERNITY ADDED
The selected alert and finding retain the same signature, flow ID, and Community ID. Cernity adds a stable finding identity and lifecycle. This is consolidation of an existing detection, not a threat that Suricata missed.
Read the records
alert.signature_id: 9000003
The identifier of the custom benchmark rule. It is not a count of alerts or a generally deployed detection rule.
alert.action: allowed
This alert does not say that this rule blocked the traffic. It does not mean the activity was approved or safe.
flow_id / community_id
These match across the selected records, providing a concrete connection-level pivot back to Suricata. The destination port is present in Suricata but absent from the selected Cernity entities.
finding_id / revision: 2
Both Cernity documents share the same identity. Revision 2 is an update, not a second incident. An append-only search can display both documents.
state: FINAL / enrichment_state: TIMEOUT
The finding was finalized for delivery, but the requested enrichment did not complete. FINAL does not mean a threat was confirmed by an analyst.
severity: 1 versus 9
These values use different scoring conventions. Suricata rule priority and Cernity’s 1–10 severity are not directly comparable.
What this does not establish
The actual document reduction for this signature is 45 to 2. A latest-revision view could show one finding, but that UI behavior was not measured. The whole Cernity run contains six documents. Revision 1 has PENDING enrichment; revision 2 has TIMEOUT and empty evidence_refs. Successful packet, GeoIP, or reputation enrichment is not demonstrated.
The saved traffic shows 172.31.0.5 contacting twelve internal hosts. An individual Suricata record describes one connection attempt; the behavior becomes visible when you group those records by source.
Saved run: factorial-scanCompletion: reconciled
SURICATA → SIEM
48 flows · 12 destinations · 0 alerts
Selected flow record · original exported document body
These are complete selected document bodies from saved SIEM exports, pretty-printed without changing values. The escaped entities string is preserved exactly as a string. Search-result wrappers such as an Elasticsearch _index or _id were not retained in these exports and are not reconstructed here.
All 2 matching Cernity documents are included in the download, including distinct IDs and revisions.
WHAT CERNITY ADDED
Cernity emits lateral_movement and rdp_fanout leads. The displayed lateral_movement record summarizes internal_targets: 12. It does not include a list of all twelve target addresses.
Read the records
dest_port: 3389
The selected flow targets the usual Remote Desktop port. A port number is a useful clue, not proof of successful RDP authentication.
flow.state / packet counters
Read these to distinguish attempted connections from more developed sessions. Contacting a host is not the same as logging into it.
internal_targets: 12
This is a count of distinct internal destinations, not twelve confirmed compromised machines.
detector_id: lateral_movement
This is the detector’s name. The exported evidence supports a fan-out lead, not a demonstrated remote execution chain.
mitre: T1021
Remote Services is an investigation category. Validate it against protocol and endpoint evidence.
What this does not establish
The saved run is reconciled, but its frozen label file incorrectly describes a benign-control scenario. The records establish observed fan-out and detector output; they do not establish attack recall. The two findings can describe overlapping behavior, not two separate attacks.
The test host sends data to the same destination over several connections. Suricata records the individual transfers and stream anomalies. Cernity aggregates the transferred bytes and labels the pattern for investigation.
These are complete selected document bodies from saved SIEM exports, pretty-printed without changing values. The escaped entities string is preserved exactly as a string. Search-result wrappers such as an Elasticsearch _index or _id were not retained in these exports and are not reconstructed here.
The eleven flows total 5,933,840 bytes to the server, matching the Cernity finding. The extra value is the cross-flow aggregation and interpretation. Cernity has not discovered new packet facts or demonstrated that sensitive data was stolen.
Read the records
flow.bytes_toserver
A per-flow directional byte counter. Sum matching flow records once; do not also add flow counters embedded in alert records.
entities: bytes = 5933840
The aggregate is approximately 5.93 MB in decimal units. It is not a verified file size or a measure of sensitive content.
connections: 11
The number of connections included in this finding, not the number of users, files, or incidents.
category: exfil / confidence: 0.22
The detector produced an exfiltration lead with this score. Neither the label nor the score establishes unauthorized transfer.
mitre: TA0010
This is the Exfiltration tactic, a broad goal. It is not a specific ATT&CK technique identifier.
What this does not establish
The run ended at inputs_drained, not full reconciliation. These positive records are present, but final queue size and complete-run absence claims are not supported. The 44 alerts on this pair are stream anomalies; baseline alerting was not silent. Empty evidence_refs does not provide direct links to every contributing flow.
The same transfer experiment includes a pair declared benign in the test scenario: an authorized concentrated transfer with callbacks to 198.51.100.50. It provides a counterexample to treating detector labels as ground truth.
These are complete selected document bodies from saved SIEM exports, pretty-printed without changing values. The escaped entities string is preserved exactly as a string. Search-result wrappers such as an Elasticsearch _index or _id were not retained in these exports and are not reconstructed here.
Cernity produced two C2 beacon leads for this benign control. The selected finding reports an interval of 6.7 seconds, jitter of 2.2 seconds, and confidence 0.907. Additional analysis can produce misleading leads as well as useful ones.
Read the records
category: c2
The detector’s interpretation conflicts with the scenario’s declared benign activity. Preserve both facts.
interval_s: 6.7 / jitter_s: 2.2
Regularity can occur in authorized software and transfer retries as well as malicious callbacks.
confidence: 0.907
A high detector score is not equivalent to a 90.7% chance of compromise.
13 connections
The selected beacon includes thirteen connections. It does not mean thirteen separate alerts or thirteen attackers.
No low_slow_exfil record in this snapshot
One detector staying quiet does not prevent another detector from raising a false lead on the same traffic.
What this does not establish
This is an observed unfavorable result from a declared benign control, not a measured population false-positive rate. The run is only inputs_drained. The absence of a low_slow_exfil record applies to the saved snapshot.
The DNS query is visible. The finding is much narrower.
A historical synthetic DNS-tunnel test generated long query names. The baseline export retained DNS requests and flow records; Cernity emitted one dns_tunnel finding for the client.
Saved run: synthetic-dns-tunnelCompletion: not established in legacy bundle
SURICATA → SIEM
200 baseline records · 0 alerts in this export
Selected dns record · original exported document body
These are complete selected document bodies from saved SIEM exports, pretty-printed without changing values. The escaped entities string is preserved exactly as a string. Search-result wrappers such as an Elasticsearch _index or _id were not retained in these exports and are not reconstructed here.
All 1 matching Cernity documents are included in the download, including distinct IDs and revisions.
WHAT CERNITY ADDED
Cernity adds a DNS-tunnel interpretation with ATT&CK T1071.004. The delivered finding contains the client IP but not the queried names, entropy measurements, resolver address, or the selected Community ID. The raw DNS record therefore remains necessary for detailed investigation.
Read the records
dns.queries[].rrname
The actual queried name is visible on the Suricata side. Its unusual appearance is a clue, not by itself proof of encoded stolen data.
dest_ip: 8.8.8.8 / dest_port: 53
This selected request targets a DNS resolver. Do not label the resolver as the attacker-controlled authoritative server.
dns.type: request / dns.version: 3
This is a request in the DNS v3 format, not proof that the lookup received a successful answer.
entities: role client
The Cernity document scopes its lead to the client. There is no destination entity or query-level evidence list here.
mitre: T1071.004
The detector mapped the lead to DNS as an application-layer command-and-control technique. That classification still needs validation.
What this does not establish
This is a legacy export without the newer hash manifest or qualified completion metadata. The baseline/source records were rechecked for equality apart from ingestion timestamps, but its assurance is lower than the primary cases. The 200 records are 100 DNS events and 100 flow records, not 200 alerts. No complete-run recall or precise cross-clock alignment claim is made.
A historical test combined DNS and flow activity. The selected Suricata request asks for cdn.evil.example; Cernity produced a domain-level beacon finding for 10.0.0.5, naming evil.example and four rotating IP addresses.
Saved run: synthetic-fqdn-beaconCompletion: not established in legacy bundle
SURICATA → SIEM
124 baseline records · 0 alerts in this export
Selected dns record · original exported document body
These are complete selected document bodies from saved SIEM exports, pretty-printed without changing values. The escaped entities string is preserved exactly as a string. Search-result wrappers such as an Elasticsearch _index or _id were not retained in these exports and are not reconstructed here.
All 1 matching Cernity documents are included in the download, including distinct IDs and revisions.
WHAT CERNITY ADDED
Cernity supplies a domain-level interpretation that can connect activity across addresses. The finding reports the parent-domain value evil.example and rotating_ips: 4; it does not include the four addresses or the individual supporting DNS answers.
Read the records
dns.queries[].rrname: cdn.evil.example
This is the observed query in the selected baseline record. The name belongs to a synthetic example, not a live malicious domain claim.
entities: domain / role c2
Cernity reports evil.example as its domain entity. This differs from the complete queried hostname; preserve that distinction when pivoting.
rotating_ips: 4
The finding summarizes a count. It does not enumerate the addresses or prove they are all controlled by an attacker.
evidence_refs: []
There are no attached references to the contributing DNS or flow records in this document.
What this does not establish
This legacy bundle has no newer export manifest or qualified completion/replay metadata. The baseline contains 72 DNS and 52 flow records; counts describe the whole saved baseline, not just this hostname. Domain rotation can be normal. The record demonstrates emitted output, not general detection accuracy or complete attribution.
Everything above is a saved synthetic replay. The two records below are the opposite: verbatim documents from the live Elasticsearch cluster (ndr-findings-*), findings Cernity delivered from the real sensor. Suricata emits two bare IPs; Cernity's stored finding carries GeoIP/ASN, reverse DNS, and a VirusTotal reputation lookup keyed by the endpoint.
Live enrichment coverage at capture: GeoIP/ASN and reverse-DNS on 10,000+ findings each, VirusTotal on 8,068. Every VirusTotal result so far is benign — shown as the automated lookup it is, not a caught-bad story.
LIVE SIEM 01 / See enrichment on a real C2-category finding
Suricata gives you two IPs. Cernity hands the SIEM who, where, and reputation.
A real long-lived beacon-shaped flow from the homelab: 163 connections over 20,879s from 192.168.222.15 to 44.231.237.105. Suricata logged the flow. This is the finding Cernity delivered to the live SIEM for it.
Live index: ndr-findings-2026.09.17Document: long_connection_cumulative-547219036-2982676
This is a complete, verbatim document pulled from the live Elasticsearch SIEM (ndr-findings-*) — the real _index and _id are retained so any value traces back to the exact stored record. The escaped entities string is preserved exactly. Nothing was synthesized.
Cernity-added reputation lookup. Here it comes back clean — which is itself signal: it lets the analyst deprioritize a benign AWS destination instead of chasing it.
What this does not establish
Enrichment does not change the detection — it contextualizes it. A clean VirusTotal result (as here) is not proof of innocence, only that no engine has flagged the IP. Enrichment values are point-in-time lookups cached at delivery.
LIVE SIEM 02 / See enrichment on an nDPI-risk finding (IPv6)
An nDPI risk flag, enriched with who owns the far end.
A real nDPI-risk finding: Suricata's nDPI engine flagged 'Susp DNS Traffic' (risk score 460, Medium) toward an IPv6 endpoint. This is the finding Cernity delivered to the live SIEM.
Live index: ndr-findings-2026.09.17Document: ndpi_risk-5639833716-2982677
SURICATA ALONERaw Suricata/nDPI: an IPv6 address + a risk flag→CERNITY FINDING · IN THE SIEMCernity finding: + GeoIP/ASN/org · + reverse-DNS (IPv6)
THE ENRICHMENT CERNITY ADDED
Fields Suricata does not emit — keyed by the endpoint IP
This is a complete, verbatim document pulled from the live Elasticsearch SIEM (ndr-findings-*) — the real _index and _id are retained so any value traces back to the exact stored record. The escaped entities string is preserved exactly. Nothing was synthesized.
The base detection promotes Suricata's own nDPI flow-risk into a finding. Confidence 0.6 — a lead, deliberately not a high-certainty verdict.
geo.<ipv6> = US / asn 20001 / Charter Communications Inc
Cernity-added. Resolves the IPv6 endpoint to a US residential ISP (Charter/Spectrum) — very different triage than a datacenter or foreign ASN.
intel.rdns.<ipv6> = syn-...res6.spectrum.com
Cernity-added reverse-DNS on an IPv6 address — a Spectrum residential PTR, consistent with the ASN.
What this does not establish
This finding carries no VirusTotal block (not all findings trigger every enrichment). nDPI risk is a heuristic score, not a confirmed threat — the enrichment tells you where the endpoint lives, not whether the traffic was malicious.
An enabled add-on is not proof of a delivered field. This inventory separates captured output from source-supported capabilities and identifies the records still needed to demonstrate each integration.
15 saved bundles inspected.
No nonempty geo, intel, iocs, or summary objects were present in those finding exports. No nDPI, fingerprint-rarity, or SLIPS detector findings were found. This describes the available evidence, not every possible Cernity deployment.
A compatible sensor integration can add ndpi metadata to its EVE flow. Baseline ingestion must retain that object to expose it in the SIEM.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The behavioral source builds detector_id: ndpi_risk, category: malware, and an entities entry with type: ndpi_risk and the matched risk values. This is a separate analytic, not automatic copying of the complete ndpi object into every finding.
Required configuration
A compatible Suricata/nDPI integration; real EVE output in the expected shape; the behavioral consumer; a candidate that passes lifecycle and delivery policy.
Evidence limitation
The reviewed lifecycle treats standalone nDPI risk as metadata rather than automatic packet-capture confirmation. No ndpi_risk document appears in the available saved exports.
What a complete demonstration needs
Capture a source flow containing ndpi, the resulting candidate and final revision, and the stored SIEM body. Include an authorized application with a risk flag to demonstrate how false leads are handled.
With supported fingerprint generation and handshake visibility, raw TLS events can contain tls.ja3 and tls.ja4. Those fields are useful in a baseline SIEM without Cernity too.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The protocol detector prefers JA4 and falls back to JA3 for its ja4_rarity path. Relevant candidate entities can include a ja3 or ja4 value, the source IP, SNI, and Community ID. The detector name alone does not prove the underlying fingerprint was JA4.
Required configuration
TLS logger, enabled supported fingerprint computation, captured handshake, protocol-detector state and warm-up, and delivery rather than suppression.
Evidence limitation
Fingerprint rarity is not malware identification. An output field can exist in a candidate yet never reach the analyst if the finding is suppressed. No corresponding delivered fingerprint record was present in the available bundles.
What a complete demonstration needs
Retain a real TLS input, the observed fingerprint, the preceding warm-up context, the final lifecycle decision, and the retrieved SIEM record. Test both expected software and a declared anomalous client.
The two legacy examples retain actual DNS v3 request bodies, queried names, resolver addresses, flow IDs, and Community IDs.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The saved dns_tunnel finding includes a client IP and T1071.004; the saved beacon_fqdn finding includes a domain and rotating_ips. Neither preserves all raw DNS evidence inside the finding.
Required configuration
Visible queries and relevant answers; compatible EVE format; DNS/behavioral consumers and state. Encrypted DNS contents are not automatically visible.
Evidence limitation
These older bundles lack the newer export manifests and qualified completion metadata. Their source/baseline equality was checked locally. Passive DNS observations are not reverse-DNS enrichment.
What a complete demonstration needs
Read the actual records above. For a new benchmark, retain paired answers, input manifests, replay mapping, completion accounting, and original SIEM documents.
An ordinary flow records an IP address. Passive DNS query logs may show names previously observed, but they are not a PTR lookup of that IP.
CERNITY → SIEM · SOURCE-REVIEWED PATH
On a successful lookup, finding-service can add intel.rdns keyed by the IP address. The returned hostname is the resolver result, not proof that the named service or organization owns the traffic.
Required configuration
INTEL_RDNS enabled in the actual container, resolver access, an IP entity, and a successful PTR result. The reviewed code allows internal-address lookups through its configured resolver too.
Evidence limitation
A missing field can mean disabled enrichment, no PTR result, a lookup failure, or downstream field loss. The saved SIEM exports contain no nonempty intel block.
What a complete demonstration needs
Use a permitted address with a controlled PTR record and retrieve the resulting SIEM document. Also record a no-PTR case. Do not append a manually looked-up hostname to a historical finding and call it original output.
A flow carries addresses; location or network-owner enrichment in the baseline would depend on that SIEM’s own ingest pipeline.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The source can add geo keyed by global IP, with country, asn, and as_org when the corresponding database lookup succeeds.
Required configuration
Compatible local MaxMind-format databases, actual file mounts, GEOIP_DB and GEOIP_ASN_DB passed into finding-service, and an eligible globally routable IP entity.
Evidence limitation
The synthetic documentation addresses in the primary cases are unsuitable positive tests for global-address GeoIP enrichment. Location is not attribution, and ASN ownership is not proof of malicious operation.
What a complete demonstration needs
Capture the database version, eligible address, successful lookup, and received SIEM body. Do not invent a country or ASN for a documentation address.
A DNS or SNI observation reports a name, not its registration date.
CERNITY → SIEM · SOURCE-REVIEWED PATH
Successful RDAP enrichment can attach intel.domains entries with age_days and nrd. This is distinct from how recently your sensor first saw a domain.
Required configuration
A domain or SNI entity, INTEL_RDAP passed to finding-service, registry data and outbound access. INTEL_NRD_DAYS controls the classification threshold when passed through.
Evidence limitation
The reviewed registrable-domain helper takes the last two labels; it is not a public-suffix-aware parser. Multi-label suffixes can produce the wrong lookup target. A young domain is not itself malicious.
What a complete demonstration needs
Retain the queried domain, registry response provenance, configuration, and the exact SIEM field. Include a multi-label-suffix and missing-registration-date control.
Raw JA3/JA4 values can be searched directly. A human-readable label is a separate lookup.
CERNITY → SIEM · SOURCE-REVIEWED PATH
intel.fingerprints maps a JA3/JA4 entity value to an operator-supplied label when the local map matches. The bundled map is not a maintained guarantee of malware attribution.
Required configuration
INTEL_FP_MAP, a readable mounted JSON map, the exact matching entity value, and final JSON delivery.
Evidence limitation
The operator’s label may be wrong, stale, or shared by benign clients. Generic fingerprint entities and all JA4+ variants are not automatically handled by this JA3/JA4-specific function.
What a complete demonstration needs
Record the map version and source, the exact fingerprint and label, and the received SIEM document. Keep the label’s origin visible.
Your baseline SIEM may already have reputation enrichment. That must be disclosed in any comparison.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The reviewed code can add intel.reputation for GreyNoise fields and intel.virustotal for vendor-count statistics. Those are separate provider outputs, not a single Cernity verdict.
Required configuration
The corresponding API credentials passed into finding-service, allowed external access, a global IP entity, and a successful provider response.
Evidence limitation
Provider absence or failure can leave the fields absent. A count of vendors is not calibrated certainty. Current subscriptions and rate limits are external dependencies.
What a complete demonstration needs
Retrieve actual provider-backed fields from the SIEM, preserving provider identity and observation context while excluding credentials from exported evidence.
Suricata flow and other selected EVE topics feed the central eve-bridge, which writes input for SLIPS. There is no SLIPS output in the baseline unless separately installed there.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The adapter maps a SLIPS alert into slips_ml or slips_intel, with entities describing the originating module, threat level, and description. The IP roles are attacker/victim in this adapter, unlike src/dst in many other detectors.
Required configuration
Compatible upstream runtime and command, Redis, input/output volumes, enabled bridge topics, broker authentication, the adapter, and a finalized finding delivered to the SIEM.
Evidence limitation
The reviewed overlay omits secure-bus credentials for its bridge and adapter. Unknown or missing module names fall through to slips_ml, so the label alone does not establish that a trained model generated the original evidence. The overlay is not a verified all-in-one installation.
What a complete demonstration needs
Capture the actual SLIPS alert, module/model provenance, mapped candidate, final finding and original SIEM body. Include a threat-intelligence lookup control to distinguish lookup agreement from model evidence.
Suricata EVE contains the fields its own parsers emitted. Optional central Zeek operates on a captured packet slice rather than inventing missing packets.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The Zeek worker constructs conn, TLS, certificate, HTTP, SSH, file, SMB, and Kerberos summaries when those logs exist. It can extract JA3, JA4, JA4S, JA4H, and JA4SSH indicators; JA4X is present only in certificate details in the reviewed summary code.
Required configuration
Working capture, object-store access, authenticated broker paths, compatible Zeek packages, valid packet evidence, and a finding delivery path that explicitly retains the desired fields.
Evidence limitation
The reviewed apply_enrichment_result function merges evidence_refs and enrichment status, but not the worker’s summary or iocs objects into the final finding. The saved signature example instead shows TIMEOUT. It would be incorrect to display a fabricated fully enriched SIEM finding.
What a complete demonstration needs
After resolving the delivery gap, retrieve a successful enriched revision from the SIEM and compare its actual fields against the Zeek result and referenced capture. Until then, source capability is not delivered-field proof.
Suricata fileinfo may contain file state, gaps, size, and hashes if logging and visibility permit. That is not the same as a central scan of the file bytes.
CERNITY → SIEM · SOURCE-REVIEWED PATH
Optional services can create file-related findings from hash matching or content rules. The exact detector, hash, match, completeness, and evidence reference must be inspected in a delivered record.
Required configuration
Completeness-aware file metadata for whole-file matching; extracted bytes, transport, object access, rules, and running services for YARA.
Evidence limitation
A partial file hash cannot establish identity of a complete malware artifact. No file/YARA finding was present in the available historical SIEM exports.
What a complete demonstration needs
Use approved benign test artifacts and an explicit test rule. Retain file completeness, hash, rule version, scan output, and stored SIEM document; include a truncated-file control.
Separate raw events or alerts remain separate unless the baseline SIEM correlates them. Existing SIEM analytics must be included in a fair evaluation.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The source includes derived incident/corroboration candidates that reference contributing detections. SOAR integration is another output path, not evidence that containment took place.
Required configuration
Running correlation/response services, their state and storage dependencies, authenticated inputs, compatible entity identities, and configured delivery or playbooks.
Evidence limitation
A generated correlation label does not prove independent evidence, attack success, or response execution. A SIEM finding and a successfully executed response need separate receipts.
What a complete demonstration needs
Show the contributing findings, correlation candidate, final SIEM document, and a separately captured response audit when response is claimed.
Threat-intelligence matching and server fingerprints
No captured threat_intel finding
SURICATA → SIEM
Suricata can expose IPs, certificate hashes, and client/server fingerprints when available. Rules or existing SIEM intelligence may already match some indicators.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The threat-intel service builds threat_intel candidates from configured indicator matches. Its source also supports an operator-supplied C2 server-fingerprint list for observed JA3S, JA4S, or JARM values.
Required configuration
Successfully loaded feeds or local lists, actual observable input values, authenticated consumers, and a finalized delivered finding.
Evidence limitation
A consumer for a JARM value is not an active JARM scanner and does not mean stock Suricata produces JARM. Feed matching is distinct from reverse DNS and reputation enrichment. No threat_intel finding was present in the saved exports.
What a complete demonstration needs
Use controlled indicators with documented provenance and retain the matched source field, list version, candidate, final finding, and original stored SIEM record. Disclose equivalent baseline matching.
Suricata stats report counters where supported; anomaly events and stream-anomaly alerts report parser or protocol conditions. These are distinct event types.
CERNITY → SIEM · SOURCE-REVIEWED PATH
The coverage detector can produce coverage_degraded candidates from supported loss or parser-visibility counters. The anomaly detector can promote selected anomaly conditions.
Required configuration
Stats and anomaly loggers, required fields, correctly routed topics, running consumers, and final delivery.
Evidence limitation
A missing stats stream does not itself demonstrate healthy collection. Packet-capture APIs differ in their available counters. Stream anomalies are shown in the transfer examples, but no delivered coverage finding appears in these saved exports.
What a complete demonstration needs
Retain original counters and known test visibility conditions, the resulting finding, and the received SIEM record. Separate a collection fault from a malicious-traffic claim.
A SIEM can retain raw events and support searches over them. Retention scope and query capability are part of the baseline configuration.
CERNITY → SIEM · SOURCE-REVIEWED PATH
Optional central storage, asset resolution, and reconstruction services support retained telemetry and investigation views. A timeline or asset-store result is not automatically embedded in every SIEM finding.
Required configuration
Deployed storage, authenticated consumers, schema initialization, retention policy, available identity observations, and an explicit analyst access path.
Evidence limitation
Installing ClickHouse or MinIO does not prove that every source event is retained or that reconstructed context reaches the SOC. No complete asset/timeline SIEM attachment is demonstrated by the saved finding exports.
What a complete demonstration needs
Retrieve the retained records and a scoped reconstruction result, then show the actual SIEM linkage if one is claimed. Verify missing data and access boundaries separately.
These descriptions are not substitute SIEM records.
No mocked JSON is presented as successful optional integration output. The missing demonstrations require a configured test deployment and retrieval from its actual receiving SIEM. See the evidence collection procedure →
METHOD & PROVENANCE
Where these records came from.
What was checked
The selected records come from saved pipeline exports. During preparation of this page, every listed export-file SHA-256 in the five primary cases was checked against its bundle manifest. The two older DNS cases lack those manifests and are labeled as lower assurance. Baseline records were compared with source EVE as multisets, ignoring only the SIEM-added @timestamp.
Counts were recalculated for the specified source, destination, and detector. The selected document bodies retain their original fields and values; the short panels select fields and decode entities only.
What remains private
The complete captures, reports, and evidence bundles are not published here. Downloads contain selected synthetic record bodies, all matching Cernity findings, scoped counts, replay offsets, and source export hashes. They are not the full input dataset.
The hashes document provenance and local verification. Without the original bundles, a visitor cannot independently reproduce every full-run count from these downloads alone.
Completion and clocks
reconciled is the saved harness's completed accounting state. inputs_drained means the inputs had drained but full lifecycle and delivery reconciliation was not established. A finding with state: FINAL can still have enrichment_state: TIMEOUT; those are separate concerns.
Replay re-anchors old capture timestamps. Each download preserves its recorded offset. For a source flow, compare flow.start + replay_offset_seconds with the replayed observation window. Do not use @timestamp ingestion values to calculate original connection intervals.
What these comparisons can support
The saved records show additional pattern analysis and signature consolidation, alongside false leads and incomplete enrichment. They do not establish general precision, recall, throughput, analyst workload reduction, operating cost, or superiority to equivalent SIEM analytics. A configured SIEM could derive similar patterns from raw telemetry.