Pillar one · the Correlation Engine

The crown jewel: a correlation engine that shows its reasoning.

Most platforms correlate with one rule and a threshold. Seculogik runs nine independent strategies on every alert, each looking from a different angle, and lets them vote on one verdict. The result is a small number of cases that each carry a readable explanation of why they exist — above whatever detection stack you already run, and without replacing it.

9
Strategies
every alert judged from nine angles
1
Verdict per alert
open, join, escalate, quarantine or suppress — and say why
72
Detection packs
MITRE-mapped, importable from a screen
23
Vendor connectors
plus open-source stacks, webhooks and custom connectors
1 box
Self-hosted
your infrastructure, no per-GB meter
Nine lenses on every alert

Reorder them. Switch them off. Read what each one said.

Manual correlation is where a SOC's week goes: a vendor-commissioned survey (Microsoft/Omdia, State of the SOC 2026) found two thirds of SOCs lose at least a fifth of their capacity to it. Seculogik's strategies do that work as an ordered list you control — like firewall rules. Only the client-attribution guard is fixed at the front, because binding one client's alert to another's case is the one mistake no analyst should ever have to undo.

00

Client attribution

First, always. Is this alert confidently attributed to one client? If not, it waits in a quarantine queue for a person — it is never guessed, and nothing else runs on it until that is settled.

01

Shared entities

The alert touches a host, a user, an address or a file that already sits in an open campaign, so it joins that campaign. Shared infrastructure — a CDN edge, a jump host everyone uses — does not count on its own.

02

Attack progression

Order matters. Execution, then evasion, then credential theft, then lateral movement is an attacker at work. The same alerts arriving backwards are replay or tagging noise, and score nothing.

03

Cross-source agreement

The same entity seen by two different sources in a short window — your EDR, your identity provider, your firewall — is corroboration, and corroboration escalates.

04

Slow-burn risk

A user whose risk has been quietly accumulating over the day deserves a case even when today's alert, taken alone, is low.

05

Known storylines

When the cluster of tactics and entities matches a recognised attack narrative — phishing to account takeover, execution to ransomware — the case is compacted into that one story and arrives as a sentence.

06

Attacker clustering

The same attacker artefacts across several cases for one client, climbing the kill chain over days, is one adversary — and is escalated as one.

07

Benign-pattern suppression

Known-benign activity is suppressed from a catalogue of patterns — and when it fires, the pattern is named in the decision trace. “Suppressed” is never “disappeared”.

Σ

Learning from your analysts

Strategy weights can learn from your analysts' verdicts, per client, within limits you can see. A false positive blamed on a broken source adjusts nothing — that is a fix to file, not a lesson to learn. Off until you switch it on.

The verdict

One verdict. Every factor kept. Shown in the case.

The strategies vote; the engine weighs what each one saw — how confident it was, how much evidence backed it, how many different kinds of detection agreed, and how sure the client attribution is — and settles on one of five outcomes. Every case keeps that breakdown in its decision trace, next to a counterfactual: what would have had to differ for the verdict to change. An analyst, an auditor or your client can read it a year later.

open
Enough evidence on its own to open a case nobody else owns.
join
Belongs to an active campaign, either as a peer or as flagged context.
escalate
The chain reached a strong escalator: lateral movement, exfiltration, impact.
quarantine
Client attribution too weak to bind. Waits for a person; never guessed.
suppress
A benign pattern dominates. Named, logged, reversible.
What the decision trace tells your analyst
  • Which strategies fired — and what each one saw.
  • What weighed most — the signals that carried the verdict, in plain words.
  • Why this severity — including the burst it absorbed and the stage it reached.
  • What would have changed it — the counterfactual, so a review is a conversation, not an argument.
  • What was suppressed — by name, so nothing quietly vanishes.

→ kept with the case · readable by an analyst, an auditor or your client

Burst absorption hundreds × failed logon · low Correlation absorbs the burst rates the whole nothing lost on restart 1 case severity: high
Aggregation

Hundreds of low alerts are one high case — and a restart loses none of them.

Every detection stack has a rule that fires thousands of times in minutes. Seculogik absorbs the burst before it reaches your analysts: repeats of the same low-severity signal become one case, rated on what the burst adds up to — so a brute-force attempt that arrives as five hundred “low” events is filed as what it is, not as five hundred nuisances, and not as one more “low”.

Aggregation rules are yours to set: what counts as a burst, per source and per client, and how the resulting case is rated. And the buffer is built to be interrupted — if a component restarts mid-burst, the alerts it was holding are re-driven, not dropped. You pay for a retry, never with evidence.

The same absorption applies whether the burst comes from an open-source stack, a market platform or a custom connector. Correlation happens above the source.

The kill chain that actually moves

A case that reached ransomware never still reads “exploit”.

A case's kill-chain position advances with the evidence: it always reflects the furthest stage any of its alerts reached, never the first one that happened to arrive. The decision queue ranks on it, so the case that matters rises to the top of your analysts' morning — and stays there as it worsens.

Reconsomeone is looking
Initial accessthey are in
Executionthey are running code
Persistence / evasionthey intend to stay
Credential accessthey hold keys
Lateral movementthey are spreading · strong escalator
Exfiltration / impactthey are taking or breaking
Storylines

Attacks the engine recognises by their shape.

  • Phishing → account takeover — a lure, a stolen credential, a mailbox read, data on its way out. One case, one sentence.
  • Public-app exploit → server foothold — a service abused, code executed, persistence planted, a channel home.
  • Endpoint execution → ransomware — execution, evasion, credential theft, spread, impact. Escalated as soon as the shape is clear.
  • Compromised identity → cloud privilege abuse — a stolen login turning into rights it should never have had.
  • Sanctioned activity — a storyline that actively suppresses, so an approved admin session or a scheduled test does not become an incident.
Named for the behaviour, never the vendor

The same story reads the same, whatever saw it.

Seculogik describes an attack by what the adversary is doing — forcing a door, hiding behind a legitimate process, tunnelling out, crawling the directory, locking files — rather than by which sensor noticed. So a storyline reads identically whether its alerts came from an open-source stack (Wazuh, OpenSearch, Elastic / ELK, ClickHouse), a market platform (Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne, Cortex XDR, Fortinet, Okta, Entra ID, AWS, Azure…) or a connector we built for you. Every pattern maps to MITRE ATT&CK, and 72 shipped, MITRE-mapped detection packs give you content to start from, importable from a screen.

See the whole Decision Center →
Multi-client, enforced

One client = one case space. Always. No exceptions.

The same file hash, hostname, public address and technique seen in two clients produce two cases — byte-identical evidence or not. For an MSSP that is not a preference; it is the promise your contracts rest on. Several independent controls enforce it, and any one of them alone would hold.

1

Attribute before you correlate

Every alert is attributed to a client before any strategy sees it, with a confidence the engine can act on. An alert that cannot be attributed with confidence goes to a quarantine queue for a person — it is never guessed into somebody's case space.

2

Scoped at every step

Correlation only ever looks inside one client's data. That is not a filter someone can forget to apply; it is how every lookup the engine makes is built, and it is checked on every release.

3

The guard runs first

The client-attribution guard sits ahead of every other strategy and stops them cold on weak attribution — so no later lens can merge across a boundary the first one refused.

4

The engine refuses

A verdict that would bind two clients into one case is refused outright, not written and cleaned up later. And from one client's side, another client's cases simply do not exist — not even as something forbidden.

Proof on your data

Replay a week of your alerts through the engine.

Thirty minutes, on your own telemetry. We connect to the stack you already run — an open-source SIEM such as Wazuh, OpenSearch or Elastic, a market platform such as Splunk, Sentinel, CrowdStrike or Defender, or an export from any of them — run the nine strategies, and walk you through the cases with their decision traces. You keep the report.