Why the correlation engine is our crown jewel
A correlation engine owes you four things — a case that explains itself, deduplication that absorbs a burst without losing an alert, a triage queue that ranks on what a case has become rather than on how it started, and, if you serve several customers, a wall between them that cannot be crossed. What each one means for your SOC, whatever detection stack you already run.
Integration scope: Seculogik uses a source-agnostic architecture to ingest security alerts and events through its own data map. Wazuh and OpenSearch are the first integrations. Other named sources describe planned connector targets; their availability must be confirmed for each evaluation.
The missing layer in a SOC is not more data. It is decision — and this is the chapter where that layer gets built. CardinalOps analysed live production SIEM configurations in 2025 and found that enterprise SIEMs had detections for only 21% of MITRE ATT&CK techniques while the data already ingested could cover 90%, and that 13% of the rules that did exist were silently broken.
The data is there. Almost none of it becomes something a person can decide on. Detection coverage is a real problem, and it is not the one solved here: close that gap and you have more alerts to triage, not fewer. Collecting the data was never the hard part. Turning what fires into a case worth opening is.
That gap is where Seculogik's correlation engine lives. Give it a week of your alerts, from the stack you already run, and it gives you back a small number of cases that explain themselves, keep their shape through the busiest five minutes of your month, and reach your analysts in the order that matters. Alerts → cases → decisions. It is why we call it the crown jewel rather than a feature.
It sits above whatever detection stack you already have — open-source SIEM and data stacks such as ClickHouse, Elastic / ELK, OpenSearch and Wazuh; market platforms such as Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne, Cortex XDR, Fortinet, Okta, Entra ID, AWS and Azure; and anything else through a custom connector we build on request, or a generic webhook you map once in the universal data map.
Nothing you already own has to move, and nothing you already own stops working if you take us out — which is the only honest test of vendor lock-in. It does not replace your log store or compete with your sensors. It decides what they are telling you.
It owes the analyst an explanation
Most correlation is one rule and a threshold, and the case it produces says "rule X matched". That is a label, not an explanation: it names the rule that fired, not the business impact of what it caught. An analyst cannot defend a label to your board, your auditor or your regulator.
Seculogik puts every alert through nine independent checks and lets them vote. Seven of the questions they ask read like this.
- Is this host, user or address already part of something active?
- Is an attack genuinely progressing?
- Do two different tools independently report the same thing?
- Is a quiet user's risk accumulating week after week?
- Does this match a recognised attack pattern such as phishing to account takeover, or endpoint execution to ransomware?
- Is the same attacker turning up again across your estate?
- Is this a pattern we can name as benign and hold back?
One check can be fooled. Nine, each asking a different question of the same alert, rarely are — and when they disagree, the analyst sees the disagreement, not a confidence score with nothing behind it.
The verdict those checks reach is written down with the case: which signals mattered, how the verdict was reached, and what would have had to change for the outcome to differ. The next shift picks the case up without a verbal handover, and a CISO can open the same case a year later and read why it existed. The engine is fitted to your estate rather than shipped as one fixed opinion. That is what we mean by an engine that shows its work.
If you serve several customers, it owes each one a wall — MSSP edition
This section is about the MSSP edition only. In the Free and Client editions there is exactly one organisation — yours — so there is nothing to separate and nothing here to pay for. Read on if you run a managed SOC, or a group that has to keep subsidiaries apart.
One client equals one case space. Always. For a provider that is the difference between a multi-client platform and a shared inbox. For a group it is the same wall between subsidiaries, business units, regions or an OT site that must never see corporate cases. The same file hash, hostname, public address and technique seen at two clients produce two cases, identical evidence or not — because the alternative is a security product that tells client A about client B's incident.
That boundary is enforced at several independent layers, and any one of them would hold on its own — from the moment an alert arrives, through every question the engine asks of the data, to the verdict it writes down. An alert the engine cannot attribute with confidence waits in a quarantine queue for a person rather than being guessed into somebody's estate. One client's cases are not merely locked away from another client's users; they are invisible, so even their existence does not leak.
The engine is fitted to each estate. This boundary is not — it is the one thing we never make configurable. And it is what lets you put your own brand on the front of it.
It owes the operator a burst that is not a data loss
Every SOC has seen it: one rule on one source fires hundreds of times in a few minutes — a brute-force run, a misconfigured agent, a scanner sweep. That is alert fatigue arriving in one lump, and it is where naive deduplication breaks down: the case that comes out the other side undercounts the attack, and nobody can say by how much.
Seculogik absorbs the burst instead. Hundreds of low-severity repeats become one case, rated for what the volume actually means, with every repeat counted — including the ones that arrive while a component is restarting. Nothing is lost. Noise suppression that drops the evidence along with the noise is deletion by another name.
That holds however the alerts reach us, and whatever they come from — an open-source stack, a market platform, or a source we built the connector for because you asked: pushed from an endpoint platform, pulled by connector from a cloud service, or passively tailed from the SIEM you already run. A burst never costs you alerts.
It owes the queue a sense of proportion
Severity is not the only thing that makes a case urgent; volume is the other, and triage ordered on severity alone misses it. Hundreds of failed logons are individually low, and a queue that rates the resulting case "low" because its parts were low has hidden a brute-force attack in plain sight.
That lever is yours. You decide when sheer volume makes a case more serious, and the case carries that reason with it, so the tier 1 working the queue can see why a low-severity signal arrived at the top. Kill-chain position advances with the evidence too: a case that started as a foothold and reached impact is ranked as impact, not as where it began. Your backlog ranks on what the case has become, not on what it first looked like.
What we claim, and what we do not
We claim what we opened with: a week of your alerts becomes a small number of cases that explain themselves, keep their shape through your busiest five minutes, and rank on what they have become. We claim the verdicts are still readable long after the analyst who worked them has moved on. And if you choose, the engine takes your analysts' verdicts into account when it decides what matters most in your estate — it never does so until you turn it on.
We publish no accuracy or false-positive-reduction percentage of our own, because no credible cross-vendor benchmark exists yet and a number nobody can check is worth less than none. We are pre-GA: no customers to point at, no qualification, no third-party penetration test report, no SLA. That is why the offer we opened with is a week of your own alerts rather than a number of ours.
We do not claim an autonomous SOC. The engine ranks and explains; a person decides. Human-in-the-loop is the design here, not a stage we are working to remove.
Nine checks, one verdict, no lost bursts, a queue with a sense of proportion. The Correlation Engine and Seculogik are the Client edition itself, not an add-on to it — they are what turns on the day you move up from Free. Alerts → cases → decisions.
The next chapter is what your analysts meet after the verdict: an AI analyst that lists its hypotheses and its evidence before it commits, and is fact-checked against the case's own alerts in front of the team. That is SIROC, our Advanced AI module. See how SIROC reasons.