Open-Source SIEM Showdown: Wazuh vs. Security Onion vs. Elastic Security
A practical comparison of Wazuh, Security Onion and Elastic Security — deployment effort, hardware needs, alert quality and community support for small teams on tight budgets.
Three platforms come up every time a small team asks how to centralise logs without buying a commercial SIEM: Wazuh, Security Onion and Elastic Security. They overlap enough to be compared, but they started from different problems — endpoints, networks, and search at scale — and that history shows in how much work each one demands before it earns its keep. Here is what they ask of you, and where a tight hardware budget hurts most.
Three tools, three starting points
Wazuh is agent-first. You install an agent on Windows, Linux and macOS hosts, and it ships file integrity monitoring, log collection, vulnerability detection based on installed packages, configuration assessment and a rule set mapped to MITRE ATT&CK. A single-node install bundles an OpenSearch-based indexer, the Wazuh server and a dashboard.
Security Onion is network-first. It is a Debian-based distribution that packages Zeek, Suricata, Stenographer and Elastic or OpenSearch search, plus investigation tooling: Hunt, Cases, Playbook and Sigma-based detections. You run it standalone or as a distributed grid of manager, search and sensor nodes.
Elastic Security is the SIEM layer inside the Elastic Stack. Data arrives through Elastic Agent or Beats, gets normalised into the Elastic Common Schema, and is then queried by detection rules, timelines and cases. Elasticsearch and Kibana moved to AGPL in 2024, but the licensing overall is a mix and some capabilities still sit behind paid tiers.
Deployment effort: an afternoon versus a fortnight
Wazuh is the quickest route to a working install. Its script or packages get a single node running on a clean VM in well under an hour, and agent rollout rides on whatever you already use — Ansible, Group Policy, your configuration management tool. The real work comes afterwards: writing decoders for awkward log formats, raising thresholds on chatty rules, and excluding directories that fire a file integrity alert every time a package updates.
Security Onion's installer is guided and well documented, but the network side is the true cost. Seeing traffic means a SPAN port on a switch or a network TAP — a change request and a maintenance window, not a checkbox. Distributed deployments are Salt-managed and they do work, but treat them as an infrastructure project with its own timeline.
Elastic Security asks for the most assembly. You either pay for Elastic Cloud or run your own cluster, which makes heap sizing, index templates, ingest pipelines and lifecycle policies your problem. Prebuilt detection rules produce signal quickly once data lands cleanly, but getting it into ECS shape is the bulk of the effort.
Hardware and storage on a small budget
All three punish under-provisioned memory before they punish anything else. A few rules that apply regardless of which one you pick:
- Split the index/search node from the collector once you pass a handful of data sources. One box is fine for a lab, not for production.
- Size disk for retention, not peak ingest. Decide how many days you need searchable — thirty is a common starting point — then work backwards.
- Keep index shards in the tens of gigabytes. Hundreds of tiny daily shards slow searches and waste heap.
- Leave headroom. A node sitting at 90 percent memory is one bad query away from failing during an incident.
For a genuinely small environment — a dozen servers and a firewall — 4 vCPU, 16 GB of RAM and a few hundred gigabytes of fast disk is a sensible start for an all-in-one Wazuh deployment. Security Onion publishes minimum specifications; read them before you buy hardware, because the sensor side wants CPU cores to keep up with Suricata and Zeek. Elastic sizing follows ingest volume almost directly, so measure a week of real logs before committing to a cluster shape.
Alert quality: where each one earns trust
Wazuh's default rule set is broad and generous. That is good for coverage and hard on the on-call rota. Expect to spend your first weeks cutting noise: cap repeated authentication failures, disable file integrity monitoring on log directories, and group alerts so a single noisy process does not generate forty events. What survives is genuinely useful, and the ATT&CK mapping helps when you have to explain an alert to someone outside the team.
Security Onion's strength is network detection. Suricata with the Emerging Threats rules, plus Sigma detections and Zeek's protocol logs, gives an honest picture of what crosses the wire — but only for traffic you can actually see. If most of it is encrypted, you will lean far more on metadata and endpoint sources than on signatures.
Elastic's prebuilt rules are the best-curated default set of the three, and its investigation timeline is pleasant to work in. The catch is data quality: rules depend on fields being mapped correctly, so a log source parsed carelessly produces silence rather than errors. Machine-learning detections sit behind paid tiers.
Community, documentation and the long haul
Wazuh has an active GitHub project, thorough documentation, busy community channels and an optional paid support path. Security Onion's docs are among the best in open-source security, and its forum is small but responsive — a real advantage when you are stuck on a networking problem at 11pm. Elastic has by far the largest community, though much online advice assumes Elastic Cloud or a commercial licence, and major version upgrades have historically needed planning.
Which one fits your team?
- Pick Wazuh if endpoint and server visibility matter most, you have no network tap, and you want value within a week.
- Pick Security Onion if a SPAN port or TAP already exists and network intrusion detection is the priority.
- Pick Elastic Security if you have data engineering capacity, several log sources to correlate, and want freedom in how you search and visualise long term.
A practical way to start
Stand up the leading candidate in a lab VM, feed it two or three real sources — a Windows domain controller, a Linux web server, your firewall — and let it run for a week without tuning. Count the alerts you would actually act on, not the features on the brochure. If you can, run the same data through a second option before deciding. The tool that produces a short, believable list beats the one with the longer feature page, and any of these three will do the job once you commit to tuning it. Document every rule you switch off, keep retention honest, and revisit the choice when your log volume changes.
Photo: panumas nikhomkhai / Pexels
