Threat intelligence: a managed indicator lifecycle, not a raw feed dump

Cernity ships a managed threat-intelligence lifecycle: it ingests indicators from external feeds, normalizes and scores them, matches them live against observed traffic, and can replay them retrospectively against the observation history. The point is not to dump a feed into a detector — it is to keep provenance, trust, and expiry attached to every indicator so a match is something an analyst can actually reason about.

This capability is shipped as part of the middle tier. As with every other layer, which indicators match in your deployment still depends on the feeds you configure, the fields your sensors collect, and the services you run.

Where indicators come from

Cernity ingests indicators from three feed families:

Each ingested indicator keeps its provenance — which feed it came from and when — so a match can always be traced back to its source rather than appearing as an anonymous verdict.

The lifecycle: normalize, score, expire, suppress

Ingestion is the start, not the whole story. Every indicator moves through a managed lifecycle:

• Normalize — feed-specific formats become one internal indicator model, so an IP from MISP and an IP from a TAXII feed are compared on the same terms.
• Score — indicators carry a score, not a flat present/absent flag.
• Expire — indicators age out, so a stale feed entry does not match forever.
• Suppress — an indicator can be suppressed without deleting it, keeping the record while removing it from live matching.

TLP handling and per-feed source-trust

Two controls govern how much weight an indicator carries:

• TLP (Traffic Light Protocol) handling is preserved on the indicator, so sharing and handling constraints travel with it.
• Per-feed source-trust ranks feeds against each other. A low-trust feed cannot override a high-trust indicator — trust is resolved per feed, so a noisy or unvetted source cannot outrank a curated one for the same indicator.

Live matching against observed traffic

The threat-intel service matches active indicators against the observed traffic live, across:

• IP
• domain
• URL
• JA3 (TLS client fingerprint)
• JA4 (TLS client fingerprint)
• certificate

When traffic matches, the matched indicator and its provenance are attached to the finding — so the analyst sees not just that it matched but which indicator, from which feed, at what score and TLP. A match is a lead the investigation tests, not a confirmed verdict; see the analyst workflow.

Retrospective hunting

Indicators change after traffic has already been seen. Retrospective hunting replays indicators against the stored observation history, so an indicator learned today can find traffic that was observed yesterday. Each retrospective match records two timestamps:

• when the traffic was observed, and
• when the indicator was learned.

Keeping both separate is deliberate: it lets an analyst reason about the gap between exposure and detection rather than collapsing them into a single “now” that hides it.

Boundaries and roadmap

• File-hash and URL hunting are roadmap, pending a file-evidence source. Live URL matching ships (above); retrospective hunting on file hashes and URLs does not — Cernity does not yet carry the file-evidence needed to replay those reliably. Do not treat file-hash hunting as available.
• Threat-intel matching only sees the fields the traffic actually exposed. Encrypted traffic that reveals a JA3/JA4 or certificate can match on those; it does not expose a URL it never carried in the clear.
• A match inherits the quality of its feed. Provenance, TLP, source-trust, and expiry exist so you can weigh that, not so you can skip it.

See detection coverage for where threat-intel sits among the detection layers, the capability overview for how it fits the shipped platform, and how Cernity works for where matching enters the pipeline.

← All documentation