Open-Source SIEM Compared: Wazuh, Graylog, Elastic and Security Onion

Open-Source SIEM Compared: Wazuh, Graylog, Elastic and Security Onion

The short answer: Wazuh if you need agent-based endpoint telemetry with compliance mappings out of the box. Graylog if your problem is log collection and search at volume, not detection. Elastic/OpenSearch if you already run the stack and have engineers who can keep it running. Security Onion if network traffic is where your evidence lives. None of them is free once you count the operator, and choosing wrong costs more than any licence.

Every compliance framework an auditor will put in front of you — ISO/IEC 27001:2022, SOC 2, PCI DSS v4.0.1, RBI, CERT-In, MAS TRM — requires that security-relevant events are logged, retained and reviewed. None of them names a product. That gap is where most organisations stall: the requirement is unambiguous, the commercial SIEM quotes arrive priced per gigabyte ingested, and the project dies in procurement. Open-source SIEM is the usual escape route, and it works — but only if you pick on operational reality rather than feature tables.

What you are actually choosing between

These four tools are routinely listed together and they do not do the same job. Two are detection platforms, one is a log-management platform that can detect, and one is a network-security monitoring distribution. Reading them as interchangeable is the most common and most expensive mistake.

Wazuh

Wazuh is an agent on every host reporting back to a manager, with an indexer and dashboard behind it. The agent is what distinguishes it: file integrity monitoring, security configuration assessment against CIS benchmarks, vulnerability detection from installed-package inventory, rootkit checks, and command and process auditing all come from the same agent you already had to deploy.

For compliance work this matters more than the detection quality. An auditor asking how you evidence file integrity monitoring or configuration baselining is asking for something Wazuh produces as a report, not something you have to build. Wazuh ships with rule groups tagged against PCI DSS, HIPAA, NIST 800-53 and GDPR, which is a genuine head start — though the tags are a starting point, not an assessment, and treating them as one is how organisations arrive at an audit with mappings nobody validated.

Where it hurts. The indexer is the part that bites. Index lifecycle management, shard sizing and disk headroom are not optional and are not configured for you; a Wazuh deployment that falls over usually fell over on storage. Rule tuning is real work — a default installation is noisy, and the first four to six weeks are spent suppressing what does not matter in your environment. Agentless coverage of network appliances is possible via syslog but is not where the product is strongest.

Choose it when your estate is servers, laptops and containers, your evidence needs are endpoint-shaped, and you want compliance reporting without building it.

Graylog

Graylog is a log-management platform first. Ingestion, parsing, routing, stream-based processing, retention tiers and fast search are its strengths, and its handling of high-volume syslog from network devices, firewalls and appliances is better than Wazuh’s. The open-source edition covers collection, search and alerting; the security-specific detection content and investigation workflow sit in the commercial tiers.

Where it hurts. There is no Graylog endpoint agent. You will pair it with Beats, or with Wazuh agents, or with your existing EDR — which means Graylog rarely ends up being the whole answer. Detection rules are largely yours to write; if nobody on the team is going to author and maintain them, you have bought a very good search engine and no detection.

Choose it when the pressing problem is that logs are scattered across devices and nobody can search them, and detection maturity is the next phase rather than this one.

Elastic / OpenSearch

Both descend from the same codebase and both are credible SIEM substrates. Elastic’s security solution is the more complete product; OpenSearch’s Security Analytics is the Apache-2.0 path and the natural choice if you are already running managed OpenSearch. Either way you get the best search and visualisation of the four, and detection content that can be as good as the engineering you put into it.

Where it hurts. This is the option that most often becomes a second full-time job. Cluster sizing, hot-warm-cold tiering, shard strategy, ingest pipeline maintenance, mapping conflicts and version upgrades are ongoing engineering, not setup. Organisations that choose Elastic to avoid a licence and then staff it with nobody end up with a cluster in yellow status and six months of unsearchable data.

Choose it when you already run the stack for something else, or you have platform engineers with capacity and want maximum control over detection logic.

Security Onion

Security Onion is a distribution rather than a single tool: Zeek for protocol-level network metadata, Suricata for signature-based intrusion detection, full packet capture, and an analyst interface over the top, with host log collection alongside. Where an investigation needs to answer what actually crossed the wire, nothing else on this list is close.

Where it hurts. It needs network visibility — a tap, a SPAN port, or cloud traffic mirroring — and packet capture consumes storage at a rate that surprises people the first time. In an estate that is entirely SaaS and cloud-native, there may be very little traffic to see. It is also the most specialist of the four to run well.

Choose it when you have on-premise or hybrid infrastructure, network-level evidence matters to your regulator or your incident response, and you have somewhere to put the packets.

The decision, in the order the questions actually arrive

1. Where does the evidence your auditor wants live? Endpoints and servers point at Wazuh. Network devices and appliances point at Graylog. Packets point at Security Onion. Application and platform logs you already ship point at Elastic/OpenSearch.
2. How much are you ingesting per day, and for how long must you keep it? PCI DSS v4.0.1 requires twelve months of audit log history with the most recent three months immediately available. CERT-In requires 180 days of logs maintained within India. Retention multiplied by daily volume is your storage bill, and storage is the cost that actually scales — not the licence.
3. Who reviews the alerts tomorrow morning? This is the question that decides the project. A SIEM nobody watches satisfies the logging control and fails the monitoring control.
4. Who operates the platform? Upgrades, index lifecycle, agent rollout, rule tuning, and the 2am disk-full page. If the answer is nobody, choose the option with the least operational surface, or choose to have it operated.

Question three is where most self-hosted SIEM projects fail. ISO/IEC 27001:2022 separates A.8.15 Logging from A.8.16 Monitoring activities precisely because collecting logs and watching them are different controls. SOC 2 does the same across CC7.2 and CC7.3. PCI DSS v4.0.1 goes further: requirement 10.4.1 mandates daily review of specified audit logs, and 10.4.1.1 requires that review to use automated mechanisms — a future-dated requirement that became mandatory on 31 March 2025 and is in force now. A stack with nobody behind it does not meet any of these.

What open source does and does not save you

The licence goes away. Nothing else does. Honest accounting of a self-hosted SIEM includes compute and storage for the indexer or cluster, storage growth over the full retention window, the engineer-days to deploy agents and tune rules out of their noisy default state, ongoing upgrade and patch effort, and the analyst time to triage what it produces. Commercial per-gigabyte pricing is unpopular because it is unpredictable, not because it is imaginary — it is the same costs, bundled and marked up.

The real economic argument for open source is different and stronger: you keep the data and the configuration. When the contract ends, the detection logic, the parsers, the dashboards and the historical index are still yours. That is what you are buying.

Two ways to get there

Praxis-Q delivers open-source SIEM under either model, and the choice is yours rather than ours.

Build and hand over. We design the architecture against your retention and volume requirements, deploy it, build the log-source inventory, tune the rules, map every detection to the controls it evidences, write the runbooks, and train your team to operate it. You own the stack, the data and the configuration outright. There is no ongoing dependency on us, which is the point.

We operate it. The same build, with our analysts running detection, triage and escalation around the clock under SOC-as-a-Service. The stack still belongs to you — the difference is who watches it at 3am and who produces the evidence pack when the auditor asks for ninety days of reviewed alerts.

Organisations frequently start with the second and move to the first as their own team matures. Because the platform is the same either way, that transition is a handover rather than a migration.

Where to go next

• For how these controls map to a specific framework: Wazuh mapped to ISO 27001, SOC 2 and PCI DSS controls.
• For what a SIEM actually costs to own: SIEM total cost of ownership.
• For the build-versus-outsource decision: SOC-as-a-Service vs an in-house SOC.
• For Indian banking and NBFC requirements: SIEM for the RBI cyber security framework and CERT-In six-hour reporting and log retention.
• For endpoint detection specifically: Endpoint Security and XDR.

Frequently asked questions

Is an open-source SIEM acceptable to an ISO 27001 or SOC 2 auditor?

Yes. No framework specifies a product. Auditors test whether events are logged, retained for the required period, protected from tampering, and reviewed — with evidence. A well-run Wazuh or Elastic deployment evidences that as well as any commercial platform. A neglected one fails, and so does a neglected commercial one.

Does Wazuh satisfy PCI DSS Requirement 10 on its own?

It covers a substantial part of it — log collection, file integrity monitoring, log protection and retention — but Requirement 10 also demands documented processes, time synchronisation, and daily review using automated mechanisms. The tool is necessary and not sufficient; the process around it is what gets assessed.

Can we start with one tool and add another later?

Commonly, yes, and it is often the right sequence: Wazuh for endpoint coverage first, Security Onion added when network visibility becomes necessary. Plan the log schema and retention tiers up front so the second deployment does not mean re-parsing everything.

How long does an implementation take?

Architecture and a working deployment in weeks; a tuned, low-noise, audit-ready deployment in months. The variable is not installation, it is the number of distinct log sources and how much tuning each needs. Anyone quoting a fixed timeline before seeing your log-source inventory is guessing.

What does it cost?

Scope is driven by daily ingest volume, retention period, agent count, the number of distinct log sources, whether you host it or we do, and whether you operate it or we do. Pricing is scoped per engagement — request a proposal.