Platform · 03 Detect
A purpose-built streaming engine evaluates every event as it arrives — and layers correlation, aggregation, and low-and-slow analysis on top, so the attacks that hide between events get caught too.
Detection is three stages in one engine, and the order matters: an event is matched, the thing it happened to is identified, and only then does it accumulate against that entity over time.
A stateless matcher holds your entire FDL library live and evaluates every event against the rules bound to its source. A pre-filter stage keeps that affordable, so the library can grow without the throughput falling over — and rules hot-reload, so deploying one does not mean restarting anything.
Between matching and correlating, each signal is resolved to the entity behind it — the user, the host, the address. This is the step that lets two rules written months apart against different vendors correlate at all, because they are joined on identity rather than on a shared field name.
Signals accumulate against an entity across several decaying time windows, and build into signal chains. Short windows catch the burst; long ones catch the patient attacker spreading activity thin to stay under a threshold. Several distinct conditions can escalate a chain into an alert.
What L2 escalates becomes the input to the investigation layer — which is a separate concern and gets its own page. Everything above this line is deterministic: rules you can read, windows you can reason about, and no model involved in deciding whether something matched.
Running it
Open correlation windows are written out on shutdown and restored on the next boot, so a deploy does not silently reset every long-running chain to zero.
If the engine comes back with correlated rules loaded and no usable state to restore, it warns that correlation is starting empty. A gap in coverage you know about is a scheduling problem; one you do not is a breach nobody caught.
The engine reports back per rule whether it is genuinely loaded and firing. "Deployed" in the console means the engine agreed, rather than a status field that was set optimistically when you clicked save.
One thing worth knowing before procurement asks. Detection itself needs no model — L1 and L2 are deterministic. The investigation layer does, and its provider support is narrower than the rest of the platform's: authoring and onboarding work with OpenAI, Gemini or Claude, while investigation currently runs on Anthropic or Gemini. If your organisation has standardised on OpenAI, you can ingest, author, detect and correlate — investigation is the piece that would need a second provider approved.
Every detection is mapped to ATT&CK tactics and techniques as it's created — no annual spreadsheet project. The coverage matrix answers the board-level question directly: what would we see, and where are the gaps?
