Wazuh vs Security Onion: which one fits your first SIEM investment
If your team must choose one self-hosted SIEM investment first, the question is where your most likely intrusions will be visible. Wazuh starts on the endpoint. Its agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and the Wazuh server analyzes their data with decoders and rules that ship with more than 3,000 built-in items mapped to MITRE ATT&CK. Wazuh also covers file integrity monitoring, vulnerability detection against the software inventory agents collect, and prebuilt dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53. The server and agents are GPL-2.0 with an OpenSSL linking exception, and the indexer and dashboard are Apache-2.0. Wazuh fits teams whose audit and breach questions center on servers, workstations and configuration drift, and whose compliance evidence must come from hosts.
Security Onion starts on the wire. It bundles Suricata, Zeek, Strelka, full packet capture and Elasticsearch in one Linux distribution, so it fits teams that need to reconstruct network activity, hunt across east-west traffic, or inspect what a compromised host sent out. Its license is the Elastic License 2.0, which is source-available rather than OSI open source and forbids offering the software as a managed service. The hardware bar is higher: a standalone node needs at least 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, the vendor suggests 32 GB RAM or more for even modest traffic, and only x86-64 is supported. Check your sensor placement and traffic volume with the vendor's hardware requirements before you commit.
The decision turns on three things. First, where your risk sits: if attackers are more likely to arrive through unpatched endpoints or drifted configurations, start with Wazuh; if your exposure is lateral movement through the network or data leaving segments you cannot instrument from hosts, start with Security Onion. Second, license tolerance: a GPL-2.0 server and agents may suit your legal review better than ELv2 terms, which matter most if you might resell or host the platform for others. Third, staffing: confirm who will tune rules, maintain sensors and run upgrades, because both platforms need ongoing operators, and Security Onion's distributed design adds more nodes to care for.
Which platform fits which environment
When most of the risk sits on hosts (Linux and Windows servers, workstations, and some macOS fleets), Wazuh is usually the better fit. Its agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and they collect the signals that matter at the host level: log data, file integrity, software inventory and configuration checks. The Wazuh server applies decoders and rules to that data, and the ruleset maps alerts to MITRE ATT&CK. This advantage matters most when your investigations start with "what changed on this host" rather than "what crossed the wire."
- Agent coverage: Wazuh agents report directly from endpoints, so you see process, file and configuration activity that a sensor on a span port cannot observe.
- Built-in content: The ruleset ships with over 3,000 rules and decoders, which reduces the number of detections your team must write before first use.
- Central management: The Wazuh server manages agent configuration and upgrades remotely, which matters when the fleet is large and changes often.
- Mixed fleets: OSSEC agents can report to a Wazuh server, so an existing host estate can move in stages.
Before you choose, confirm agent support for each operating system in your fleet, and ask whether your endpoint estate needs agent-based isolation or response tooling that sits outside Wazuh's scope.
When you need to see traffic between segments, north-south flows at the perimeter, or lateral movement that never touches a log file, Security Onion is the stronger fit. It bundles Suricata for intrusion detection, Zeek for network metadata, Strelka for file analysis and full packet capture in one distribution. Its Distributed design uses a manager node, search nodes and sensor nodes, so sensors can sit at the points where traffic is visible. This advantage matters when the questions are about packets, sessions and protocols, and the hosts involved cannot be instrumented.
- Wire visibility: Sensors see sessions and file transfers on monitored segments, including traffic between hosts that you may not be able to instrument.
- Placement planning: The Distributed design separates sensor placement from search capacity, so you can add sensors at new segment boundaries.
- OT and legacy hosts: Where agents cannot be installed on controllers or appliances, passive network monitoring may be the only option, although you must confirm protocol coverage for your specific industrial protocols.
- Packet retention: Full packet capture supports deep investigation, but it multiplies storage and sensor sizing needs.
Before you commit, confirm which segments need sensors, whether mirrored or tapped traffic is available there, and whether your network can carry the sensor traffic without impact.
Both platforms can run without internet access, but the work differs. Wazuh documents an offline installation guide and an offline vulnerability repository in place of its Cyber Threat Intelligence platform. Security Onion supports full installs on networks without internet access: the ISO carries packages and NIDS, YARA and Sigma rules, and the soup update tool applies newer ISO media in airgap mode. The better choice depends on whether your air-gapped risk is mostly host-level or network-level, and on how you plan to refresh content and software across the gap.
- Content refresh: Wazuh vulnerability data needs an offline repository you maintain, while Security Onion content arrives with new ISO media.
- Update path: Confirm how each platform's update path behaves across the gap, including the media, approvals and change windows your enclave requires.
- Host profile: An air-gapped estate of mostly servers favors Wazuh's agent model, while a segmented network with sensors favors Security Onion.
- Licensing for transfer: Security Onion's ELv2 terms and Wazuh's GPL-2.0 terms both allow internal use, but confirm the terms with your legal team if you plan to redistribute images inside a larger program.
Before you build, ask the vendor and your integrator to document the offline update process and test it on a copy of the target enclave.
With a small team, the operating load matters as much as the feature list. Security Onion's minimum standalone hardware is 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, and its documentation suggests 32 GB of RAM or more when monitoring even a small amount of traffic. Wazuh splits its work across the indexer, server, dashboard and agents, which means more components to size and patch but a narrower sensor footprint on each host. The right choice depends on whether your staff will spend time on sensor placement and packet storage or on endpoint policy and alert triage.
- Hardware floor: Security Onion needs x86-64 hardware and planning for sensor placement, which adds work for a team without network engineers.
- Component count: Wazuh's four components are simpler to explain to new staff, but the indexer and server still need capacity planning.
- Paid support: Security Onion Pro adds professional support on 1 to 5 year terms, which some small teams value for staffing gaps.
- Retainers: DeployOpen offers ongoing support and upgrades as retainers, which can cover the operating load without new hires.
Before you decide, ask who will patch, tune rules and triage alerts each week, and whether that person has time for sensor work.
Scenario-by-scenario fit between Wazuh and Security Onion
Each row names the scenario, the platform that fits it better, and the reason. Read the rows against your own estate: the answer changes with where your risk sits (hosts or wire), how much hardware you can dedicate, and whether you already run a search stack.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Endpoint-heavy estate (many Linux, Windows or macOS hosts) | Wazuh | Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX and provide file integrity monitoring, inventory and active response on each host. Security Onion's main sensors watch network traffic, so endpoint depth is weaker unless you add Elastic Agent coverage yourself. |
| Network blind spots (east-west traffic, unmanaged devices, no host agent possible) | Security Onion | Suricata, Zeek and full packet capture see traffic between hosts and from devices that cannot run an agent. Wazuh can collect syslog from agentless devices such as firewalls, but it does not inspect the wire the way a sensor does. |
| Compliance evidence from hosts (configuration, file integrity, vulnerability inventory) | Wazuh | Wazuh's dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, and its vulnerability detection correlates agent software inventory with CTI or offline vulnerability data. Confirm with your assessor which evidence formats they accept, since DeployOpen prepares evidence but does not issue assessment reports. |
| Air-gapped operation | Both can run offline, with different effort | Wazuh documents an offline installation guide and an offline vulnerability repository in place of its CTI platform. Security Onion ships an ISO with packages and NIDS, YARA and Sigma rules, and updates in airgap mode from newer ISO media. Confirm the update cadence you need for each rule set before choosing. |
| Hardware-constrained sites (small or shared hosts) | Wazuh, for agent-heavy coverage on modest servers | Security Onion's bare minimum for a standalone install is 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, with 32 GB or more suggested for even light traffic. A sensor needs 4 cores, 12 GB RAM and 2 NICs. Wazuh's footprint depends on the indexer and server sizing you choose, so ask for sizing for your endpoint count rather than assuming. |
| Team already running an OpenSearch or Elastic stack | Depends on the stack and the licence you accept | Security Onion depends on Elasticsearch and Elastic Agent, so it fits a team on the Elastic stack, but its Elastic License 2.0 bars offering it as a managed service. Wazuh's indexer is an OpenSearch fork under Apache-2.0, so a team on OpenSearch can often reuse operational skills. Confirm whether your existing cluster can host Wazuh's indexer or should stay separate. |
| Teams that must cover both hosts and the network | Run both, feeding one review process | Wazuh and Security Onion cover different telemetry, and the Wazuh documentation describes a Suricata integration for combining host and network alerts. Plan one triage workflow and confirm the integration path and version pairing for your release before deployment. |
How Wazuh and Security Onion are built and what that means for operations
Wazuh and Security Onion both split a SIEM into roles, but they depend on those roles in different ways. The cards below cover how each platform is assembled, what happens when a central node fails, and what to check before you size either one.
Wazuh's four components
Wazuh runs as an indexer that stores alerts, a server that decodes and analyzes agent data with rules, a dashboard for analysts, and agents on endpoints. Each role can be hosted separately, so the indexer, server and dashboard can be sized and patched on their own hosts. Ask your team which of these roles it will run on dedicated machines and which it will combine on one host.
Wazuh server clustering
The Wazuh server can run as a cluster to scale horizontally, and it manages agent configuration and upgrades remotely. This means a server cluster spreads agent connections across nodes, and the team keeps one place to push policy. Confirm how your cluster will be load balanced and how you will test failover before you commit to an endpoint count.
Security Onion deployment types
Security Onion offers Import, Evaluation, Standalone and Distributed deployments. Distributed, with a manager node, sensor nodes and search nodes, is the recommended design for production. Sensors capture traffic close to the network edge, while the manager and search nodes handle coordination and indexing. Decide early whether your sites justify separate sensors before you buy hardware for a single standalone box.
Manager outage on Security Onion
If the manager node goes down in a distributed Security Onion deployment, search nodes stop indexing because they cannot reach Redis. Receiver nodes can add pipeline redundancy and load balancing, but they do not remove the dependency on the manager. Plan monitoring of the manager as a critical service, and rehearse recovery so that log loss during an outage is a known, bounded risk.
Agents depend on the Wazuh server
Wazuh agents receive their configuration and updates from the Wazuh server, so a server outage stops policy changes and upgrades from reaching endpoints. Agents already installed keep collecting and forwarding events, which limits the blast radius of a short outage. Ask how your team will manage server availability, and test how long your endpoints run on their last applied configuration.
Hardware floors differ by role
Security Onion lists minimum hardware for a standalone node, a manager or search node, and a sensor, and it requires x86-64 processors. Wazuh sizes by endpoint count, storage per device type and indexer nodes, so its footprint grows with agents rather than with traffic volume. Ask your vendor or DeployOpen for a sizing review against your own traffic, endpoints and retention targets before purchasing hardware.
Side-by-side capability and licensing comparison
This table compares Wazuh and Security Onion on what each one sees, how it is licensed, what it stores and runs on, and which features need a paid edition. Read each row against your own environment, and treat any cell marked for confirmation as an open question for the vendor. The main takeaway is that Wazuh is built around endpoint agents and Security Onion around network sensors, so the agent and packet capture rows usually decide the fit.
| Capability | Wazuh | Security Onion |
|---|---|---|
| Primary visibility | Host telemetry from endpoints, including file integrity, logs and vulnerability data | Network traffic from Suricata and Zeek, with host logs ingested through Elastic Fleet agents |
| Agent model | Wazuh agents on Linux, Windows, macOS, Solaris, AIX and HP-UX; agentless syslog and API collection for devices like firewalls | Elastic Fleet agents for log collection; confirm whether any endpoint protection features are included |
| Network sensing and packet capture | Network visibility comes from a documented Suricata integration; confirm the deployment steps for your sensors | Suricata and Zeek on dedicated sensor nodes, with Suricata full packet capture since version 3.0 |
| Rule content and MITRE ATT&CK mapping | Over 3,000 built-in rules and decoders, with alerts mapped to MITRE ATT&CK | NIDS rules for Suricata, Sigma rules for ElastAlert and YARA rules for Strelka; confirm ATT&CK mapping |
| Compliance dashboards | Prebuilt dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53 | Not confirmed in the supplied sources; confirm which compliance views and reports your edition provides |
| SSO and paid features | Single sign-on is documented; confirm which edition and protocols apply to your deployment | Pro adds OIDC single sign-on, FIPS and STIG hardening, the API, notifications, Manager of Managers and reports |
| License and current release | GPL-2.0 with OpenSSL exception for server and agent; Apache-2.0 for indexer and dashboard; 4.14.9 released October 14, 2026 | Elastic License 2.0, not OSI approved; 3.3.0 hotfix 20260911 released September 11, 2026 |
| Search backend | Wazuh indexer, an open source fork of OpenSearch, stores alerts | Elasticsearch, bundled in the distribution |
| Offline installs | Offline installation guide and offline vulnerability repository for systems without internet access | Airgap ISO carries packages and NIDS, YARA and Sigma rules; updates via soup from newer ISO media |
What the GPL-2.0 and Elastic License 2.0 terms mean for each team
The Wazuh server and agent are licensed under GPL-2.0 with an OpenSSL linking exception, according to the Wazuh LICENSE file. For an internal security team, the GPL generally permits running the software in your own infrastructure without a license fee. The copyleft obligations apply when you distribute modified versions, so the practical questions are whether your organization will ship changed agent code to third parties and how it will supply source for those changes. Read the license text with counsel before you decide how you will handle custom decoders, rules or agent modifications.
- Internal use: Running the server and agents for your own endpoints does not by itself trigger the distribution obligations of the GPL.
- Modification: Changes you keep inside the organization are generally a different question from changes you distribute outside it. Confirm the position with counsel.
- Resale as a service: The GPL does not prohibit offering a managed service built on the software, but the terms for redistributing modified code still apply. Ask counsel how this applies to your model.
- Custom rules and decoders: Confirm with counsel whether your own rule and decoder files count as separate works or as modifications of the GPL-covered code.
Check the license text for the exact version you deploy, and confirm your internal distribution pattern with legal review before you rely on it.
The Wazuh indexer and dashboard are licensed under Apache-2.0, which is a different license from the server and agent. The indexer is an open source fork of OpenSearch, and it stores the alerts that the server produces. Because these components carry a permissive license, the obligations are generally lighter than GPL copyleft, but the notice and attribution conditions still apply. Treat the Apache-2.0 components and the GPL-2.0 components as separate license regimes in your inventory.
- Internal use: Apache-2.0 allows internal deployment without a license fee and without a requirement to publish your changes.
- Modification: You may modify the indexer or dashboard, subject to the notice and attribution conditions in the license.
- Resale as a service: Apache-2.0 generally permits commercial use and redistribution, including as part of a hosted service, provided the license conditions are met.
- Mixed stack: A single deployment combines GPL-2.0 and Apache-2.0 components, so your software bill of materials should list both.
Ask your legal team to confirm the notice requirements and to record the license of each component in your software inventory.
The Security Onion repository is licensed under the Elastic License 2.0 (ELv2), which is a source-available license and not an OSI-approved open source license. Security Onion moved from the GPL to ELv2 starting with version 2.4, announced on August 31, 2022. The license permits you to use, copy and modify the software, but it restricts offering the software to third parties as a managed service. For an internal team, the main practical effect is that running Security Onion for your own monitoring is a different question from providing monitoring to customers.
- Internal use: Running Security Onion to monitor your own networks is generally within the terms, but confirm the scope of the grant with counsel.
- Modification: Modifying the code is generally permitted, but redistribution and derivative use should be reviewed.
- Resale as a service: ELv2 forbids providing the software to others as a hosted or managed service, so an MSSP model needs specific legal review.
- Procurement: Because ELv2 is not OSI approved, some procurement policies that require OSI-approved licenses will treat it as a exception to approve.
If you plan to offer monitoring to clients or affiliates, bring the license text to counsel before you commit to a design.
Security Onion Pro is a paid license that adds features beyond the free distribution. According to the Security Onion documentation, Pro adds OIDC single sign-on, FIPS and STIG hardening, notifications, the Security Onion API, Manager of Managers and reports. Pro is sold on 1 to 5 year terms, according to the Security Onion Pro page. These features are a commercial agreement with Security Onion Solutions, separate from the ELv2 terms on the open repository, so the contract, not the repository license, defines what you may do with them.
- OIDC single sign-on: Connects the Console to your identity provider. Confirm which identity providers and claims your environment needs.
- FIPS and STIG hardening: Relevant if your assessment scope requires FIPS mode or OS STIG compliance. Confirm the specific controls with your assessor.
- Manager of Managers and API: Useful for multi-deployment operations. Check whether the license terms allow your intended use.
- Terms of use: Read the Pro agreement for restrictions on sharing, hosting and support scope.
Ask the vendor for the Pro license agreement and have counsel review it alongside the ELv2 terms before budgeting for Pro.
What drives the running cost of each platform
This table sets out the cost drivers behind Wazuh and Security Onion, from hardware and storage to skills, paid editions and upgrade effort. Treat hardware figures as minimums and work out storage from your own endpoint count, traffic and retention before you size anything. The main takeaway is that Wazuh's running cost leans on indexer storage and staff time, while Security Onion's leans on sensor hardware, tuning effort and whether you need the paid Pro tier.
| Cost driver | Wazuh | Security Onion |
|---|---|---|
| Infrastructure floor | No fixed minimum is supplied here. Size the indexer, server and dashboard from Wazuh's deployment guidance for your endpoint count. | Standalone needs 4 cores, 24 GB RAM, 200 GB storage and 2 NICs. Plan for 32 GB RAM or more even with small traffic. |
| Storage and retention | Alerts are stored in the indexer, so disk use grows with agent count, event volume and retention period. Confirm the sizing with Wazuh before purchase. | Elasticsearch data and full packet capture consume disk in proportion to traffic volume and how long you keep it. |
| Sensor and host hardware | Agents run on the endpoints you already manage. Central components need hosts you size and maintain yourself. | Sensors need 4 cores, 12 GB RAM and 2 NICs each. Each capture point you add is another host to run. |
| Skills to run it | Linux administration, indexer and search operations, and tuning of agent rules and decoders. | Linux administration, Suricata and Zeek tuning, Elastic-based search, and management of Sigma and NIDS rules. |
| Licensing and paid editions | Server and agents are GPL-2.0 with no license fee. Confirm any paid support or Wazuh Cloud terms directly with Wazuh. | Security Onion Pro is a paid license on 1 to 5 year terms, adding OIDC SSO, FIPS, STIG hardening and professional support. |
| Upgrade effort | Wazuh 4.14 received six patch releases in 2026. Plan regular patch windows and track the 5.0.0 release candidate. | Version 2.4 reached end of life on October 1, 2026. Oracle Linux 9 installs can upgrade to 3.x, while other distributions need a fresh install. |
| Offline operation | The offline installation guide and offline vulnerability repository support networks without internet access. | The airgap ISO carries packages and NIDS, YARA and Sigma rules, and the soup tool updates from newer ISO media. |
| One-time versus recurring | One-time: sizing, initial build and rule onboarding. Recurring: indexer storage growth, patching and staff time. | One-time: deployment, sensor placement and rule tuning. Recurring: Pro renewals, hosting, patching and staff time. |
| What to request in a quote | Sizing for your endpoint count and retention, indexer node count, and written support terms. | Sensor count and placement, hardware per role, the Pro term length, and the upgrade path for your distribution. |
Moving from one platform to the other, or running both
This sequence shows how to move monitoring from Wazuh to Security Onion, or the reverse, or run both side by side, without losing coverage of the telemetry that matters. Each step ends with a check you can verify before the next one starts.
Inventory the telemetry that must move
Start by listing every data source the current platform covers and who depends on it. Separate host telemetry (file integrity, endpoint logs, software inventory, active response) from network telemetry (NIDS alerts, Zeek metadata, packet capture) and from log sources that reach either platform through syslog. Assign an owner to each source and mark which ones your auditors, incident responders or detection rules rely on. The step is done when the list is signed off by the security operations lead and every item has a named owner and a stated reason to keep it. Because Wazuh agents and Security Onion's Elastic Agent and sensor stack do not share agents, you should expect host collection to be rebuilt on the new platform rather than carried across.
Confirm the target platform and its version path
Confirm the target platform, the release line and the operating system it requires before you plan any installation. For Security Onion, the 2.4 to 3.0 upgrade path applies only on Oracle Linux 9. The 3.0.0 release, published March 31, 2026, supports only Oracle Linux 9 and replaced Stenographer with Suricata for full packet capture. A 2.4 installation on Oracle Linux 9 can upgrade to 3 after that capture change is made, while other distributions need a fresh install. Security Onion 2.4 reached end of life on October 1, 2026, so an existing 2.4 estate has a dated support problem to plan around. Confirm with the vendor whether any custom detections or capture settings in your environment need manual migration before the upgrade is attempted. The step is complete when the target version, OS and install method are written into the change record.
Rebuild detections in the target's rule model
Rebuild each detection in the native rule model of the target platform rather than translating it line by line. Wazuh uses its decoders and rules, and its ruleset ships more than 3,000 built-in rules and decoders mapped to MITRE ATT&CK. Security Onion manages NIDS rules loaded into Suricata, Sigma rules loaded into ElastAlert and YARA rules loaded into Strelka, with tuning and suppression handled in the Detections interface. Map each source-platform detection to its equivalent in the target, mark gaps where no equivalent exists, and decide whether a network signal or a host signal is the right trigger. The step is done when every retained detection has a tested equivalent or a documented accepted gap, and the test results are stored with the change record.
Deploy the target alongside the existing platform
Install the target platform on its own hosts, sized to the documented minimums and then to your actual traffic or endpoint count. Security Onion's documented minimums include 4 CPU cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone node, and its hardware documentation suggests 32 GB of RAM or more when monitoring even a small amount of network traffic. For a production design, its architecture documentation recommends a distributed layout with a manager, sensors and search nodes, and notes that search nodes stop indexing if the manager goes down. Wazuh's indexer, server and dashboard are deployed on separate hosts from the source platform. Confirm the sizing with the vendor for your expected volume before purchasing hardware. The step is done when the target's health checks pass and the platform receives no production data yet.
Attach new collection to the target
Install the target's agents or sensors on a pilot group of hosts and network segments and confirm data reaches the target's search backend. On the Wazuh side, agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, and agentless devices can be added through syslog. On the Security Onion side, sensors capture traffic with Suricata and Zeek, and endpoints report through Elastic Agent. Where you are moving from OSSEC, note that OSSEC agents remain compatible with the Wazuh server, so a phased cutover can keep both agent types reporting during the transition. Check each pilot source by generating a known test event and confirming it appears in the target dashboard. The step is done when every telemetry item from the step one inventory has a confirmed record in the new platform.
Run both platforms in parallel
Keep the existing platform receiving the same sources while the target is being tuned, so analysts can compare alerts from both. Track alert volume, false positives and the detections that fire on one platform only. Use the parallel period to adjust thresholds and suppressions on the target, since tuning is where most of the operating effort falls. Set a written exit criterion before you start, such as a named set of detections firing correctly and an agreed review of gaps, and record who approves it. The step is done when the exit criterion is met and the security operations lead signs the cutover decision. Running both platforms doubles the hosting and licensing footprint for this period, so confirm the cost of the parallel run with your own budget owner.
Retire the old sensors and agents
Once the exit criterion is met, remove the old agents and sensors in a controlled order, starting with lower-risk segments and ending with critical hosts. Confirm that no host or network segment loses coverage during each removal by checking the target dashboard for that source. Revoke credentials and API access for the old platform, and decide with your compliance lead how long its historical data is retained and where it is stored. The step is complete when the old collection is removed from every source, no old-platform credentials remain active, and the retention decision is recorded.
Decide whether to keep both platforms
If the goal is endpoint and network coverage together, keep both platforms deliberately instead of treating the move as all or nothing. Document which platform is the system of record for each alert type, how alerts from each reach the same analysts, and who owns the upkeep of each. Note that running both means two sets of hardware, two upgrade cycles and two sets of rules to maintain, so the ongoing effort should be written into the operating plan. The step is done when the operating model is documented, the owners are named and the next review date is on the calendar.
Where Wazuh and Security Onion implementations usually run long
Security Onion projects most often stall on the network, not the software. Sensor placement and SPAN or tap design decide what Suricata and Zeek can see, and the sensor nodes need two NICs in the minimum hardware profile, so one monitoring interface is not enough. Before the build starts, the client should provide network diagrams, the list of mirror or tap points each sensor will use, and written approval for the switch or firewall changes that create them. Confirm with the network team whether full packet capture on the sensor has enough disk and whether the mirror carries the traffic you intend to inspect. Air-gapped builds add a second dependency: the ISO and the soup update path must come from a media process your change board has approved, so plan that transfer as a dated step.
Wazuh projects usually run long in agent rollout and tuning. Installing the agent on a few hosts is quick, but the work is in deploying it across the fleet, agreeing which groups receive which configuration, and clearing the first wave of alerts that the default ruleset raises in your environment. The client should provide an asset inventory with operating systems, owners and maintenance windows, a named owner for each custom rule and decoder, and change windows for agent upgrades. Ask the team to confirm how it will handle endpoints that are offline for long periods and whether the offline installation guide or an offline vulnerability repository applies to any network segment.
Security Onion Pro adds scope that many teams overlook. OIDC single sign-on, FIPS mode, STIG hardening, notifications and the Security Onion API each require identity provider settings, hardening sign-off and integration owners, so ask for those decisions in writing before the Pro license is ordered. Confirm the identity provider, the claim mapping for analyst roles, and who approves the hardened baseline. Finally, agree who owns detection content on both platforms: Security Onion Console tuning of Suricata, Sigma and YARA rules, and Wazuh rule changes, because unowned rules are the most common reason tuning never finishes.
Questions buyers ask before choosing Wazuh or Security Onion
Can we run Wazuh and Security Onion on the same network?
Yes. The two platforms cover different ground and are often deployed together, but they run as separate stacks. Wazuh agents on endpoints report to the Wazuh server, which stores alerts in the Wazuh indexer. Security Onion runs its own Suricata, Zeek, full packet capture and Elasticsearch-based storage on sensors and search nodes. Running both means two sets of storage, two dashboards and two sets of rules to tune, so the overlap is mainly at the alert level. Wazuh documents a Suricata integration that lets one view correlate host and network events. Confirm the supported versions and event fields in the Wazuh documentation before you design the pipeline.
Which one needs fewer hosts to get started?
It depends on the design you choose, and the server side of Wazuh can start on the fewest hosts. Wazuh documents an all-in-one installation and a prebuilt OVA, and its agents install on the endpoints you already run. A Security Onion standalone node needs at least 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, and its recommended production design is distributed, with a manager, sensor nodes and search nodes. Your host count will depend on traffic volume, the number of sensors and how much retention you need. Ask both vendors for sizing based on your traffic and endpoint counts, and check whether a high availability design adds hosts in your environment.
Does Security Onion need internet access to run?
No. Security Onion supports full installs on networks without internet access. The ISO carries the packages along with NIDS, YARA and Sigma rules, and the soup update tool can update from newer ISO media in airgap mode. Wazuh also documents an offline installation guide, and its vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. The practical question is how you refresh content. Rule sets, vulnerability data and software updates each have to cross your transfer process on a schedule you set. Confirm with each vendor how often content is published and how it is moved into an isolated enclave.
What does the license mean if we offer SIEM as a managed service?
The licenses treat managed delivery differently, so get a legal review before you commit. Security Onion is published under the Elastic License 2.0, which is not OSI approved and forbids offering the software as a managed service. Wazuh's server and agent are licensed under GPL-2.0 with an OpenSSL linking exception, and its indexer and dashboard are Apache-2.0. The supplied license facts do not record a managed-service restriction for the Wazuh components, but that is not a legal opinion. Whether a given service model complies depends on how each component is packaged, modified and delivered. DeployOpen works inside the client's own infrastructure, so ask counsel to review the exact components and versions in your stack.
How much staff time does each platform need to run?
No supplied figure gives staff hours for either platform, so get any estimate in writing from the vendor or from the implementation partner. The main drivers are endpoint and sensor counts, traffic volume, how many distributed nodes you operate, how often detections are tuned and how upgrades are scheduled. Wazuh runs a server, an indexer and a dashboard, and the server manages agent configuration and upgrades remotely. Wazuh shipped six 4.14 patch releases in 2026, which affects your upgrade cadence. Security Onion ships as one distribution, but its distributed design adds manager, sensor and search nodes. Ask for a written scope that lists tasks and hours, and plan time for detection tuning after go-live.
Is single sign-on free in Wazuh and Security Onion?
In Security Onion, OIDC single sign-on to the Console is part of Security Onion Pro, a paid license sold on 1 to 5 year terms. Security Onion Pro also adds FIPS mode, OS STIG compliance, the API, external notifications and Manager of Managers. For Wazuh, the supplied facts cover the single sign-on documentation but do not state which protocols it supports or whether any part sits in a paid tier. Check the Wazuh single sign-on documentation for your version, and confirm with Wazuh whether SSO covers the dashboard only or the APIs as well. Ask Security Onion Solutions for current Pro pricing in writing.
Can Wazuh read output from a network sensor like Suricata?
Yes, Wazuh can ingest network sensor output as log data. Wazuh is a host-based platform and does not inspect network traffic itself. Its agents collect endpoint events, and agentless collection through syslog and periodic API probing covers devices such as firewalls. Security Onion produces Suricata alerts, Zeek logs and full packet capture on its sensors, and those are the sources a Wazuh deployment would read. Wazuh documents a Suricata integration, so confirm the supported Suricata and Wazuh versions, the log files and fields involved, and whether a Wazuh agent must run on the sensor host. Then check whether Wazuh's built-in rules and decoders cover the Suricata events you need. Packet capture stays with the network sensor.
When running Wazuh and Security Onion together makes sense
Running both platforms makes sense when you need host-level evidence and network-level evidence for the same incident, and you have the staff to operate two consoles. Wazuh agents on endpoints see process activity, file integrity changes, configuration drift, authentication events and vulnerable software inventory. Security Onion sees what crosses the wire through Suricata alerts, Zeek metadata and full packet capture. An endpoint that beacons to a suspicious host shows up in Security Onion as a flow and in Wazuh as the process that opened it, and neither view alone gives the whole story.
The cost of this pairing is two separate license and hardware footprints. Wazuh server and agents are GPL-2.0 with an OpenSSL linking exception, and the indexer and dashboard are Apache-2.0. Security Onion is published under the Elastic License 2.0, which is not OSI approved, and its own documentation lists 4 cores, 24 GB RAM and 200 GB storage for a standalone node, with a sensor needing 4 cores, 12 GB RAM and 2 NICs. Sensors need placement on monitored network segments, so the second footprint is physical or virtual network placement, not just another server. Confirm the current minimums in the Security Onion hardware documentation before you size a sensor for your traffic, and confirm the license terms for your use case with counsel.
Analysts will correlate across two consoles unless you deliberately build a shared path. Decide early which timestamps, host identifiers and IP addresses are the join keys, and check that clocks are synchronized on every agent, sensor and manager. Wazuh's documented Suricata integration is a separate question: confirm whether it fits your Suricata version and deployment before you design around it, because it changes whether Suricata alerts land in the Wazuh pipeline or stay in Security Onion. Write a runbook that starts from an alert in one console and states exactly which query to run in the other.
How DeployOpen helps choose, implement or migrate between them
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Wazuh vs Security Onion, we start by working out whether your need is endpoint coverage, network visibility, or both, then write the scope before any work begins.
How we scope
- Map which hosts need Wazuh agents and which network segments need Suricata and Zeek sensors
- Confirm the license position your organization accepts for GPL-2.0 and Elastic License 2.0 components
- Size hardware for the manager, search and sensor roles against your traffic and endpoint counts
- Agree deliverables, timelines and exclusions in writing before any work starts
How we build
- Deploy the chosen platform or both, using the installation method your environment supports
- Configure agent enrollment, sensor placement and log sources for the agreed scope
- Tune rules and detections, documenting suppressions and custom content as you own it
- Test alert paths end to end, including air-gapped update procedures where they apply
How we hand over
- Document architecture, data flows, sizing decisions and the license terms that apply to each component
- Provide runbooks for agent management, sensor maintenance, upgrades and backup
- Walk your operations and security teams through alert triage using the delivered configuration
- Prepare control evidence for your compliance assessor, without issuing any audit report
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Plan upgrade paths for each platform's release line and end-of-life dates as you confirm them
- Retest detections and sensor coverage after changes to your environment
- Ask for a written quote that lists the scope, roles and recurring support items separately
