Why the correlation engine is our crown jewel
A correlation engine owes an analyst three things — a case that explains itself, a client boundary that cannot be crossed, and bursts that never become lost alerts. What each one means for your SOC, whatever detection stack you already run.
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. That is not a collection problem; it is the discipline of turning what fires into a case worth opening.
That gap is where Seculogik's correlation engine lives, and it is why we call it the crown jewel rather than a feature. It sits above whatever detection stack you already run — open-source SIEM and data stacks such as Wazuh, OpenSearch, Elastic and ClickHouse; 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. 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, and an analyst cannot defend a label to a client, a board or a regulator.
Seculogik looks at every alert from nine independent angles and lets them vote. One lens asks whether the host, user, address or file is already part of an active campaign — and knows that a shared gateway or a jump server is a weak link, because gluing unrelated incidents together on a common address is how false stories get told. One reads attack progression and rewards a chain that moves forward through the kill chain rather than a replay or a tagging artefact. One looks for the same entity reported by two different sources in a short window. One tracks slow-burn risk, so a user whose accumulated risk keeps climbing earns a case even when every individual alert looked minor. One matches the cluster against recognised attack storylines — phishing to account takeover, exploit to foothold, endpoint execution to ransomware, compromised identity to cloud privilege abuse — so the case reads as a story rather than a list. One follows the same artefact across several cases for one client over days. And one suppresses known benign patterns, naming the pattern so the analyst can see why something was held back.
The verdict those lenses reach is written down with the case: which signals mattered, how much each one weighed, and what would have had to change for the outcome to differ. A CISO can open a case a year later and read why it existed. Every lens can be tuned or switched off to fit your estate — except the client boundary, which is never optional. That is what we mean by an engine that shows its work.
It owes the MSSP a wall
One client equals one case space. Always. 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. Every alert is attributed to a client before anything else happens, and an alert the engine cannot attribute with confidence waits in a quarantine queue for a person rather than being guessed into somebody's estate. Every correlation query is bound to the client it serves. Attribution is checked before any lens is allowed to reason, and weak attribution stops them cold. And a verdict that would bind two clients together is refused outright. A client's cases are not merely locked away from another client's users; they are invisible, so even their existence does not leak. For an MSSP that is the difference between a multi-client platform and a shared inbox — 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 thousands of times in a few minutes — a brute-force run, a misconfigured agent, a scanner sweep. The naive design counts each alert as it arrives and quietly loses the ones that land while a component is restarting. The analyst sees a case that undercounts the attack and never learns 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 mid-restart. Nothing is discarded until the resulting case is safely recorded; if a component dies in the middle, the burst is picked up again rather than dropped. That holds however the alerts reach us: pushed from an endpoint platform, pulled by connector from a cloud tenant, or passively tailed from the SIEM you already run. A burst costs you a retry, never the alerts.
It owes the queue a sense of proportion
Severity is not the only thing that makes a case urgent; volume is the other. 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.
Aggregation rules give you that lever. A rule you write governs how alerts bind into a case and what happens once they do — raise the severity when the volume crosses a line you set — and the case records which rule governed it, so a reviewer can see why a low-severity signal arrived at the top of the queue. 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 decision queue ranks on what the case has become, not on what it first looked like.
What we claim, and what we do not
We claim that a week of your alerts, from the stack you already run, comes out the other side as a small number of cases that explain themselves, respect your client boundaries, and survive the busiest five minutes of your month. We claim the verdicts are still readable long after the analyst who worked them has moved on. And if you choose, the engine learns from your analysts' verdicts which lenses deserve more weight in your estate — it never does so until you say so.
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 do not claim an autonomous SOC; the engine ranks and explains, and a person decides.
Nine lenses, one verdict, a wall between clients, no lost bursts. That is the crown jewel, and it is the first thing we would like to show you — thirty minutes, on your own telemetry.