Open-source SIEM compared

Which SIEM fits which team scenario

This table matches common team situations to the platform that usually fits best, with the reason and the condition that would change the choice. Read each row against your own estate, staffing and hardware, then confirm the conditions with the vendor before committing. The main takeaway is that agent-based endpoint coverage, network packet capture and log search each point to a different platform.

How Wazuh, Security Onion and Graylog store and move data

Capability and license across the open-source options

This table compares six platforms on license, endpoint and network coverage, and storage, release and paid tier. Check the license column first: SSPL-1.0 and Elastic-2.0 are source-available and not OSI approved, while GPL-2.0, Apache-2.0 and AGPLv3 are OSI-approved options. Coverage cells show what each platform collects out of the box, so gaps are easy to spot.

Each option in brief, with its license

The six options below cover three different jobs: full SIEM and endpoint platforms, a network-centric monitoring distribution, and the search backend that some of them run on. Licenses differ more than the feature lists suggest, so read the license line before the feature line on each card.

What each license and paid tier allows and costs

What running each SIEM costs in people and hardware

How to choose and pilot the right open-source SIEM

This sequence moves a team from a coverage list to a documented decision, so the platform chosen matches its endpoint, network and log needs, its license rules and its hardware, and its upgrade path is written down before commitment.

1. Define coverage across endpoints, network and logs

   The security lead and the platform owner list the sources the SIEM must cover: endpoint agents on Linux, Windows or macOS, network traffic from sensors, and application or firewall logs. Note which sources need agents and which can be reached through syslog or API collection. The step closes with a one-page coverage matrix that maps each source to a candidate platform. Wazuh covers endpoints through agents and agentless devices through syslog, Security Onion centers on network sensors with Suricata and Zeek, and Graylog centers on log inputs such as syslog, GELF and Beats.

2. Write down license and managed-service rules

   Legal and procurement staff record the license terms the organization must meet, including whether OSI-approved open source is a requirement, whether source-available terms are acceptable, and whether the organization plans to offer the platform as a managed service to others. Check each candidate against its license: Graylog Open is under SSPL-1.0, Security Onion is under Elastic-2.0, and Wazuh server and agent are under GPL-2.0 with an OpenSSL exception. The step closes with a signed-off license note that names the paid edition, if any, required for each needed feature.

3. Size hardware against published minimums

   The platform owner compares expected daily ingest, retention period and network volume with each vendor's published minimums. Security Onion lists 4 cores, 24 GB RAM and 200 GB storage for a standalone node and suggests 32 GB RAM or more when monitoring even a small amount of traffic. Graylog's architecture guidance advises sizing storage as daily ingest times retention days times 120 percent. The step closes with a sizing sheet that states the assumed ingest rate and retention, labeled as the organization's own estimate, and that a vendor or partner should confirm before procurement.

4. Pilot one data source and one detection use case

   The team deploys the shortlisted platform in a non-production environment, connects one data source such as a single server group or one sensor, and builds one detection use case, for example a failed-login alert mapped to a control the organization must evidence. The pilot runs long enough to show whether alerts arrive, whether they are tuned, and whether the operator can find the events they need. The step closes with a written pilot report listing setup effort in staff hours, alert quality, and any gaps found, so the next decision rests on observed results rather than the vendor's feature list.

5. Check paid tier features you depend on

   Compare the pilot's required features with the paid editions. In Graylog, index archiving, correlation, reporting and prebuilt Illuminate detection content sit in Graylog Enterprise or Graylog Security, not Graylog Open. In Elastic's self-managed subscriptions, the detection engine and case management sit under the Platinum tier, which is no longer sold to new customers, while SAML or OpenID Connect single sign-on and endpoint malware prevention sit under Enterprise. In Security Onion, OIDC single sign-on, FIPS and STIG hardening and the API are in Security Onion Pro. The owner asks each vendor for a written quote tied to the exact features and the data volume, since Graylog's listed paid editions require a minimum of 10 GB per day or 100 Graylog Compute Units.

6. Confirm the upgrade path and end-of-life dates

   The platform owner records the release line in use and its support window before committing. Security Onion 2.4 reached end of life on October 1, 2026, so a team starting on 2.4 must plan a move to 3.x, and 2.4 installations on Oracle Linux 9 can upgrade to 3 only after full packet capture moves from Stenographer to Suricata, while other distributions need a fresh install. Wazuh 4.14.9 is the current 4.x release, and a Wazuh 5.0.0 release candidate was published on October 5, 2026, so teams should not treat 5.0 as production-ready without confirming its final release status. The step closes with a documented upgrade plan that names the owner, the test environment and the review date.

7. Decide and document the platform choice

   The steering group reviews the coverage matrix, license note, sizing sheet, pilot report and upgrade plan, then records one platform choice and the reasons for rejecting the others. The record names the paid edition, if any, the support route, and the conditions that would trigger a re-evaluation, such as a license change, a new end-of-life notice or a major release. The step closes when the decision record is filed with the security governance documents and the implementation partner, if one is used, has a written scope that matches it.

When none of these three is the right first step

Questions buyers ask before hiring outside help

How a fixed-scope SIEM engagement is planned

The sequence turns a shortlist of open-source SIEM candidates into a written scope, a deployed and hardened platform inside your own infrastructure, and a handover your team can operate. Each step closes with a named output so you can check progress before the next one starts.

1. Confirm the monitoring requirements and candidate platforms

   DeployOpen's team and your security, IT and compliance leads agree which sources must be monitored, including endpoints, network sensors, cloud logs and applications, and which platforms are in the running. Licensing is confirmed at this stage, including whether Graylog Open (SSPL-1.0), Security Onion (Elastic-2.0) or Wazuh (GPL-2.0 for server and agent, Apache-2.0 for indexer and dashboard) fits your redistribution and procurement rules. The output is a requirements list with the candidate platforms and their license and edition questions recorded for your legal and procurement reviewers.

2. Size the environment and confirm hardware

   The team works from your expected event volume, retention periods and network traffic to estimate storage, memory and node counts against each vendor's published minimums. Where a platform has hardware floors, such as the Security Onion hardware requirements, the sizing confirms they are met for the chosen deployment type. The output is a sizing note that lists the nodes, storage and network interfaces you will provision, with the assumptions written out so you can challenge them.

3. Agree scope, deliverables and timelines in writing

   Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timelines are written down and signed before any work begins. The written scope states what is in and out, including integrations, custom detection content and documentation. DeployOpen does not publish a price list, so the quote follows directly from this written scope. The output is an agreed statement of work that both parties can point to when changes are requested.

4. Deploy the platform inside your infrastructure

   DeployOpen installs the chosen platform in your cloud accounts, data centers or air-gapped network using the vendor's supported install method, such as packages, Docker, OVA or offline media where applicable. For Security Onion this means choosing among the Import, Evaluation, Standalone and Distributed deployment types, with Distributed being the vendor's recommended production design. The output is a running environment with health checks passing and a deployment record that names versions and components.

5. Integrate log sources, agents and identity

   The team connects endpoints, network sensors, firewalls and applications, then configures single sign-on where your identity provider supports it. Each platform handles this differently: Graylog uses inputs, streams and processing pipelines, Wazuh uses agents and remote configuration, and Security Onion uses its Console and Fleet-based agents. Single sign-on tiers also differ by edition, which the team checks against your licensing decisions. The output is a source inventory showing each feed, its parser or decoder status and a test event confirming it arrives.

6. Customize detections and harden the platform

   DeployOpen tunes the rules that matter for your environment, such as Sigma rules, Wazuh rule sets mapped to MITRE ATT&CK, or Suricata and Sigma rules managed in the Security Onion Console, and suppresses known noise. Hardening follows your baseline, covering access control, transport encryption, backups and service accounts. Where you need an external reference such as a compliance framework mapping, DeployOpen prepares the evidence, but independent auditors and certification bodies issue any audit report or certification. The output is a tuned detection set with a change log and a hardening checklist signed off by your team.

7. Set up backup, upgrades and documentation

   The team configures backup and restore for the indexes, configuration stores and certificates, and tests a restore before handover. Upgrade paths are documented against the vendor's release and end-of-life notices, such as the Security Onion 2.4 to 3.0 path or Graylog's compatibility matrix for MongoDB and OpenSearch versions. Runbooks cover routine operations and escalation. The output is a tested restore record, an upgrade plan and an operations handbook that your staff can use without DeployOpen present.

8. Hand over and agree ongoing support

   DeployOpen walks your operators through dashboards, alert handling and runbooks, then confirms the handover checklist with your team. Ongoing support, upgrades and continuous testing are available as separate retainers, so the scope of any post-handover work is agreed in a new written document. Your team should ask for the retainer terms, response expectations and upgrade responsibilities in writing before signing. The output is a signed handover record and, if chosen, a retainer agreement that defines who maintains the platform after go-live.