Open source SIEM: what it gives you, and what you still build yourself

If you are choosing an open source SIEM, or already running one, the honest summary is this: collection and storage are solved, and decision is not. OpenSearch, Elastic, ClickHouse and Wazuh will take your logs, keep them on hardware you control, and fire rules against them without charging you per gigabyte to read your own data. What none of them ships is the layer that turns those rules firing into a short list of cases, each with a verdict, a clock and an owner. That part is still yours to build, and it is the part that takes the year.

This is not an argument for replacing your stack. We think you should keep it. It is an argument for being clear-eyed about the boundary — what the open tooling is genuinely excellent at, and what sits above it that you will otherwise assemble out of a ticket queue, a spreadsheet and somebody's memory of what was decided last Thursday.

What an open source SIEM already solves

Three things, and they are the expensive three to get wrong.

Collection. Agents, parsers, shippers, a schema that survives contact with a real estate. Getting Windows event logs, Linux audit records, firewall syslog and cloud audit trails into one place, reliably, is genuinely hard engineering, and the open projects have done it.

Storage. Your indices sit on your disks. Retention is a capacity decision rather than a licence negotiation, which is the whole reason teams go this way. Gartner has been blunt about SIEM buyers growing frustrated by SIEM cost bloat, and an open store is the most direct answer to it. A meter puts the retention window back inside the licence negotiation, and that is vendor lock-in whatever the exit clause says.

Rule execution. A detection-rule language, a scheduler, a way to say "tell me when this happens", and a search interface for the threat hunting you end up doing by hand.

Each stack is good at a different slice of that:

None of that is faint praise. Collection and storage are the layers most commercial vendors charge the most for, and you have them.

What you still build yourself

Here is the list, in the order teams usually discover it:

• Detection engineering — content mapped to a framework, and coverage that keeps working as your estate changes.
• Correlation across sources, so an identity alert and an endpoint alert about the same laptop become one thing.
• Case lifecycle — triage, escalation to tier 2, ownership, status, a history of who decided what.
• SLA clocks, and a backlog ranked on business impact rather than on arrival time.
• Reporting and evidence an auditor, a board or a regulator will accept.
• Governance — roles, tamper-evident audit, and a record of decisions that outlives the analyst who made them.

Every one of those is buildable. The question is whether building them is what you want your security engineers doing for the next four quarters.

Detection content is the first thing you own, and the first thing that rots

CardinalOps read live production SIEM configuration metadata for its 2025 State of SIEM Detection Risk and found that enterprise SIEMs had detections for 21% of MITRE ATT&CK techniques while the data already being ingested could cover 90% — and that 13% of the rules that did exist were silently broken. Broken quietly, which is the part that matters: a rule that no longer fires looks exactly like a technique nobody is using.

That gap is not caused by the tooling being open. It is caused by detection engineering being a standing job that nobody has time for, and the open stacks hand you that job on day one. If you go this route, budget for it explicitly: someone owns detection coverage, someone tests that each rule still fires, and both of those are recurring.

Seculogik ships 72 MITRE-mapped detection packs you import from a screen, which is a floor rather than a substitute for that work — but a fresh estate starts with real coverage instead of a blank rule set.

Correlation across sources is the work that eats the week

A rule fires on one event. A campaign is many events, across an endpoint tool, an identity provider and a firewall, over days. Joining them is the tier 1 analyst's week, and it is done by hand: three tabs, a hostname copied between them, a mental model that does not survive the shift handover.

Microsoft and Omdia's State of the SOC 2026 — vendor-commissioned, so read it as a directional figure rather than a law — reports that two thirds of SOC teams lose about a fifth of their weekly capacity to manual correlation. A fifth of the week, on work that is mechanical.

This is the layer an open source SIEM deliberately does not occupy, and the one we built. Seculogik's correlation engine puts every alert through nine independent checks — the entities involved, how far the attack has progressed, whether more than one source agrees, whether it matches a recognised attack pattern such as phishing to account takeover or execution to ransomware — and they must agree on one verdict.

Deduplication falls out of the same pass — hundreds of low-severity repeats become one appropriately rated case rather than hundreds of rows. We wrote up how that works, and what a correlation engine owes you, here.

Case lifecycle is where the project quietly becomes a product

This is the part most teams underestimate, because a ticket queue looks like it already covers it.

It does not. A case needs a qualification distinct from someone opening the tab, an owner with capacity rather than whoever is on-call, a clock that starts at the right moment, and a decision trace that answers "why did we call this a false positive?" six months later, when the analyst who closed it has changed jobs. Bolting that onto a ticket system means building a workflow engine, an assignment policy, an SLA calculator and an audit trail — and then maintaining them.

The Verdict Layer is exactly that layer: a decision queue that says what to open next, computed deterministically from the facts of each case, with SLA clocks, capacity-based assignment, and a readable trace of what mattered and what would have changed the verdict.

Reporting is the deadline you cannot move

An open stack gives you dashboards. A dashboard is not a document a risk committee reads, it is not a statement of posture anyone can defend in a meeting, and it is not evidence for a regulator.

Under NIS2 you owe an early warning within 24 hours and a notification within 72; under DORA the clock for financial entities starts at classification and runs four hours. Both assume you can say, in writing, what you knew and when you decided it. Scorecards for NIST CSF, ISO 27001, GDPR, DORA and NIS2, and evidence packs that state their own methodology and coverage, are the SOC Reporting module in Seculogik. Built from scratch on an open stack, they are a project of their own.

Keep the stack. Add the layer that decides.

The conclusion is not "replace it". Your log store stays yours, your sensors stay yours, and there is no second ingest bill — the pricing model is per deployment, per year, with no meter on volume, endpoints or seats.

Seculogik sits above whatever you already run: open stacks such as OpenSearch, Elastic, ClickHouse and Wazuh, market platforms such as Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne, Cortex XDR, Fortinet, Okta and Entra ID — 23 market-platform connectors in all — plus push webhooks, and a connector we build if yours is missing.

Two things we will not tell you. We do not sell an autonomous SOC; Gartner's formal position is that there will never be one, and we agree with it. And we are pre-GA: no customers to name yet, no ANSSI or CSPN qualification, no third-party pentest report, no SLA. If any of those is a requirement, say so early and we will tell you plainly where we are.

If your stack is Wazuh, the free edition runs on it at no cost, with real cases and a real queue — that story is here. If it is anything else, the fastest way to find out whether the decision layer is worth having is to point it at a week of your own alerts. Book a demo and we will do exactly that.