Can open source replace Splunk Enterprise Security?
If your renewal or price change applies to the Enterprise Security premium app rather than the whole platform, the answer is that open source covers the core SIEM and detection work, but not all of it. Wazuh covers log analysis, rules-based detection, file integrity monitoring, vulnerability detection and compliance views, and Security Onion adds network visibility through Suricata and Zeek, NIDS and Sigma rule management in its Detections interface, and threat hunting. SOAR, UEBA and threat intelligence are the gaps. Shuffle or custom playbooks can cover response automation, custom rules can approximate some correlation, and dedicated tools fill threat intelligence and behavioral analytics, but each of these is a separate build with its own ownership. Some Enterprise Security content, such as prebuilt correlation searches tied to Splunk's own apps, has no open-source equivalent and must be rebuilt or dropped.
Splunk Enterprise Security runs on Splunk Cloud Platform or Splunk Enterprise, so the platform decision is separate from the app decision. You can keep Splunk as your log platform and stop paying for the premium app, or move the whole stack. Before choosing, list which Enterprise Security features your team uses, including the Essentials and Premier edition differences that Splunk publishes, and map each one to Wazuh, Security Onion, a SOAR tool or a gap. Confirm with Splunk how your current contract prices the app separately from the platform, and ask Wazuh and Security Onion which detection content they ship for your regulatory frameworks.
DeployOpen plans, implements and supports these stacks inside your own cloud accounts, data centers or air-gapped networks, including integration with your existing SOAR or ticketing tools and the detection rule migration work. The effort depends on how many custom correlation searches and playbooks you rely on, so an assessment against your actual Enterprise Security content is the practical first step. Scope and deliverables are agreed in writing before work starts.
Splunk Enterprise Security capabilities mapped to open-source options
This table maps each major Splunk Enterprise Security capability to the open-source option that covers it, with the gaps stated plainly. Read the rows marked partial or no direct equivalent as work you will plan, build or accept, and confirm each specific against your own log sources and detection backlog before you commit.
| Splunk ES capability | Open-source option | Coverage notes and gaps |
|---|---|---|
| SIEM correlation and alerting | Wazuh server rules and decoders, OpenSearch alerting | Wazuh covers rule-based correlation and alert generation on ingested events. Multi-stage correlation across unrelated sources needs custom rules and testing, and there is no drop-in equivalent of Splunk's correlation search framework. |
| Detection content and tuning | Wazuh rule set, Security Onion Detections (Suricata NIDS, Sigma via ElastAlert, YARA via Strelka) | Security Onion's Console can modify, suppress and threshold NIDS rules and add custom Sigma filters. Splunk ES's curated content library and its Detection Studio workflow have no direct open-source match, so expect to translate and maintain your own rules. |
| UEBA (user and entity behavior analytics) | No direct equivalent. Partial coverage through custom OpenSearch analytics and Wazuh rules | Wazuh and Security Onion do not provide a packaged behavioral baseline model for users and entities. Teams usually build baselines with OpenSearch queries or anomaly tooling. Confirm the exact behavioral coverage you need with the vendor or in a proof of concept. |
| SOAR and playbooks | Shuffle with Wazuh active response, custom scripts | Shuffle can run playbooks triggered by alerts and call APIs, but its library and integrations differ from Splunk SOAR. Premier-tier automated response has no one-to-one mapping, so budget for writing and testing each playbook. |
| Threat intelligence | OpenSearch indices fed by your own feeds, Wazuh CTI for vulnerability data, custom enrichment | Wazuh's Cyber Threat Intelligence source covers vulnerability data, not general indicator feeds. Indicator enrichment and matching against threat feeds must be built and maintained, and you must confirm license terms for any commercial feed you add. |
| Premier-tier automated threat analysis | No direct equivalent | Splunk's automated threat analysis in the Premier edition has no open-source counterpart in this stack. Plan for analysts to perform this work manually or with custom tooling, and confirm the Splunk edition you currently license. |
| Compliance dashboards | Wazuh dashboard with prebuilt PCI DSS, GDPR, HIPAA and NIST 800-53 views | Wazuh provides prebuilt views for these frameworks. Evidence for an assessor still depends on your configuration, retention and process records, and DeployOpen prepares that evidence without issuing audit reports. |
| Vulnerability context | Wazuh vulnerability detection using CTI or an offline repository | Wazuh correlates agent software inventory with vulnerability data. Coverage depends on which operating systems and applications your agents inventory, so confirm asset coverage in your environment. |
| Endpoint telemetry | Wazuh agents on Linux, Windows, macOS, Solaris, AIX and HP-UX | Agent coverage is broad, but telemetry depth differs from Splunk's forwarder inputs and any EDR feeds you already ingest. Confirm each operating system and event source you rely on. |
| Network visibility and packet capture | Security Onion with Suricata, Zeek and Suricata full packet capture | Security Onion provides network monitoring and packet capture as a bundled capability. Splunk ES does not supply this natively, so this is usually an addition rather than a replacement. Sensor sizing and placement need planning. |
| Air-gapped operation | Security Onion airgap install and soup updates, Wazuh offline installation and offline vulnerability repository | Both platforms document offline paths, including rule and package updates from ISO media or local repositories. You must still plan a process for refreshing rules and vulnerability data on a schedule. |
Which open-source option fits which Splunk ES need
Splunk Enterprise Security bundles SIEM, SOAR, UEBA and detection engineering into one premium layer. No single open-source project reproduces that bundle, so the practical question is which component covers which need, and where your team writes its own logic. The cards below set out each option, its license or tier, and the trade-off you accept.
Wazuh as the endpoint and log SIEM
Wazuh combines the indexer, server, dashboard and lightweight agents into an XDR and SIEM stack covering log analysis, file integrity monitoring, vulnerability detection and compliance views for PCI DSS, GDPR, HIPAA and NIST 800-53. It is licensed under GPLv2, so there is no license fee, but you own the agent rollout, rule tuning and upgrades. Check whether your Splunk correlation searches depend on fields that Wazuh decoders must be rewritten to produce.
Security Onion for network monitoring
Security Onion is a Linux distribution that bundles Suricata, Zeek and the Elastic Stack for network-centric detection, threat hunting and full packet capture. Its Detections interface manages NIDS rules, Sigma rules and YARA rules, which fits teams whose Splunk ES content focuses on network traffic. The repository is under the Elastic License 2.0, which is source-available rather than OSI open source, and Security Onion Pro is a paid tier that adds SSO, FIPS mode and professional support.
OpenSearch as the analytics layer
OpenSearch, under Apache 2.0, can store and search events and host dashboards when you need a general analytics layer beyond the Wazuh indexer. It forked from Elasticsearch 7.10.2, so check that any Splunk dashboards or saved searches you move will translate to its query languages and tooling. The trade-off is that you size, patch and scale the cluster yourself, and that cost moves into staff time and infrastructure.
Shuffle for SOAR-style playbooks
Shuffle covers the automation side of Splunk ES's SOAR premium features by running workflows that pull alerts, enrich indicators and open tickets across your tools. It is a separate project, so you must integrate it with Wazuh alerts and confirm which of your Splunk playbook actions have a matching app or a custom integration. Plan for workflow testing, since automated response actions can affect production systems if left unreviewed.
Custom rules for correlation logic
Splunk ES's correlation searches, risk-based scoring and UEBA baselines have no direct open-source equivalent, so teams write their own rules in Wazuh decoders and rules, Sigma or Security Onion detections. Expect to inventory each Splunk ES detection, decide which are kept, and document the logic for auditors. UEBA-style behavioral baselining is the gap most likely to need custom development or a separate tool, and you should confirm that scope before committing.
Running open-source detection beside Splunk while you decide
This is the most common starting point when the renewal is near but the detection content is not yet ready to move. Splunk Enterprise keeps handling log search, dashboards and other apps, while Wazuh or Security Onion takes over detection work in parallel. Wazuh agents can be installed alongside existing forwarders on the same endpoints, so alerts from the Wazuh server flow to a separate dashboard, and you compare them with Splunk correlation results over the same period. Security Onion sensors can be placed on mirror or tap traffic to produce network alerts that you check against Splunk's network detections.
- Dual collection: Forwarders keep sending to Splunk while Wazuh agents send to the Wazuh server, so no existing alert path is removed.
- Scope split: Assign specific sources, such as endpoints or network segments, to the open-source stack first, and leave the rest on Splunk.
- Duplicate ingestion cost: Every event sent to both platforms is licensed or stored twice on the Splunk side and kept on your own storage twice, so parallel running increases spend until the cutover.
- Alert comparison: Log each rule match in both systems for the same test cases so gaps in coverage are visible before decommissioning.
- Ownership: Name who maintains the Wazuh rules and Security Onion detections during the overlap, since two alert queues need triage.
Confirm with your Splunk account team which renewal terms allow reduced ingest during the overlap period, and confirm the expected parallel-running window with your own security operations lead.
Some teams move to Splunk Cloud Platform but drop the Enterprise Security premium app, keeping search and dashboards while detections move elsewhere. In this model the open-source stack does the security analytics and Splunk remains a log store and search layer. Wazuh agents or Security Onion sensors can forward selected alerts into Splunk as events, so existing dashboards still show security data while the detection logic lives in the open-source platform. Check whether your Splunk Cloud contract separates the platform subscription from the Enterprise Security line item, because that determines which costs actually stop.
- Alert forwarding: Send Wazuh alerts to Splunk over syslog or a configured forwarder so existing searches keep working during transition.
- Detection ownership: Move correlation logic to Wazuh rules or Security Onion detections, then keep only the reporting searches in Splunk.
- Cloud dependencies: Confirm how Splunk Cloud Platform ingest is metered, since forwarding alerts back into it adds volume.
- Export path: Plan retrieval of historical searches before the change, using the methods listed in the Splunk export documentation.
- Contract split: Ask the vendor to show the Enterprise Security line on the quote so the savings from dropping it can be measured.
Review the Splunk Cloud Platform contract with procurement before changing any ingest path, and confirm the exact line items that stop at renewal.
On networks without internet access, the open-source stack can run fully inside the enclosure, which removes dependence on vendor cloud services for detection. Security Onion supports full installs on networks without internet access, with the ISO carrying packages and NIDS, YARA and Sigma rules, and the soup update tool can apply newer ISO media in airgap mode. Wazuh documents an offline installation guide, and its vulnerability detection can use an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform. Splunk Enterprise can also be deployed on isolated networks, so the parallel plan here compares two self-hosted stacks rather than a cloud and an on-premises one.
- Offline rule updates: Plan a media transfer process for Security Onion ISO updates and Wazuh content, since no rule feed reaches the network directly.
- Vulnerability data: Build the offline repository for Wazuh vulnerability detection and refresh it on a schedule your change process approves.
- Hardware: Security Onion supports only x86-64 processors, so confirm the enclosure hardware meets the documented minimums before ordering.
- Parallel sensors: Place Security Onion sensors on the isolated segment beside existing monitoring so both feeds see the same traffic.
- Support path: Confirm how patches reach the enclosure and who applies them, because Security Onion 2.4 reached end of life on October 1, 2026 and version support changes affect upgrade planning.
Confirm the enclosure's media transfer and approval rules with your security authority before deciding which stack runs first, and confirm the Security Onion release that matches your Linux distribution.
What needs Shuffle or custom rules in place of Splunk ES
Several Splunk ES features have no one-to-one open-source equivalent, so the team has to design them. Notable events, risk-based alerting and investigation queues are the main examples. Wazuh writes alerts to the Wazuh indexer with a rule level and metadata, but it does not roll alerts up into a per-entity risk score or assign analysts to a queue. Before cutover, decide how alerts are grouped, which rule levels create tickets, how risk is calculated from several weak signals, and where analysts record their work. Confirm in the Wazuh dashboard and your chosen case tool which of these views each version provides out of the box.
Playbooks and response actions are the next gap. Shuffle can be used to build workflows that act on Wazuh alerts, for example by enriching an alert and opening a ticket, but the team should confirm which Shuffle apps, connectors and triggers it needs for each step. Wazuh active response can run predefined or custom scripts on agents when a rule fires, which covers some containment actions, but its supported actions differ by operating system and agent version. UEBA baselines and threat intelligence correlation are weaker still. Wazuh does not supply a UEBA engine equivalent to Splunk's, so behavioral baselines must be written as queries or external jobs. Test every indicator-matching rule against a known sample before trusting it.
The team takes on what ES packages as content. Expect to write and maintain decoders for each log source, custom rules with severity and suppression logic, Shuffle workflows, and tests that replay sample logs after each change. Wazuh patch releases arrived roughly every one to two months during 2026, so rules and workflows need regression testing on every upgrade. Keep detection content in version control, assign an owner for each rule family, and track the staff hours this takes. That recurring effort, not the license fee, is usually the largest difference from Splunk ES, so ask your team to estimate it before you commit.
How to move Enterprise Security content to a self-hosted stack
This sequence turns Splunk Enterprise Security correlation searches, notable event types and playbooks into a tested set of Wazuh, Security Onion and workflow components, with each detection proven against live alerts before Splunk is switched off.
Inventory correlation searches and playbooks
Export the full list of Enterprise Security correlation searches, notable event types, risk rules, adaptive response actions and any UEBA or threat intelligence content in use. Your detection engineers and Splunk administrator do this together, and the Splunk admin confirms which items are scheduled, which are disabled and which feed other apps. The step is done when every item has an owner, a data source and a last-fired date, so no active detection is missed.
Classify each item by target capability
Sort each inventory item into one of four groups: a SIEM rule that Wazuh rules and decoders can express, a network detection better suited to Security Onion's Suricata or Zeek, a SOAR workflow to rebuild in Shuffle or scripts, or an item with no open-source equivalent. Record the reason for each placement, including any UEBA behavior that will need custom analytics or a documented acceptance of the gap. The output is a signed-off mapping that the security leadership can review before build work starts.
Deploy Wazuh and Security Onion in a test environment
Install the Wazuh components (indexer, server, dashboard and agents) and, where network visibility is needed, a Security Onion deployment in a non-production network segment. Choose the deployment type that matches the test goal, and confirm the hardware meets the published minimums for each node role and that the x86-64 requirement is satisfied. The step is complete when test agents report, sensor traffic reaches the console and both platforms accept a test event end to end.
Rebuild detections and tune them
Rewrite each SIEM-class item as Wazuh decoders and rules, each network-class item as Suricata or Zeek detections managed through the Security Onion Console Detections interface, and each SOAR item as a Shuffle workflow. Tune thresholds, suppressions and exclusions against the test traffic, and document every rule with its data source and intent. Custom code is needed for anything the classification flagged as a gap, so budget for that work with your team. Done means each rebuilt rule fires on its test case and is recorded in version control.
Export historical data when investigations need it
If open investigations or compliance evidence depend on past events, export only the needed time ranges from Splunk using the CLI or REST API, which Splunk describes as the most stable retrieval methods for this purpose. Store exports in a controlled location with hashes and a retrieval log so chain of custody is clear. The step is complete when the exported sets open correctly in the target stack and an analyst confirms the key records are present.
Run detections in parallel until alerts match
Feed the same production sources to Splunk and the new stack for a fixed observation period agreed in advance by the security and operations leads. Compare alerts for each mapped detection, and record each mismatch as a false positive, a missed detection or an accepted difference. Review the results with the SOC lead and close each gap before cutover. The step is complete when the agreed match criteria are met and every accepted difference has a named approver.
Cut over and decommission Enterprise Security
Switch alert routing, playbook triggers and dashboards to the new stack, and keep Splunk read-only for the retention period set by your records policy. Update runbooks, on-call paths and any reporting that referenced Splunk notable events. Retire the Enterprise Security app and the forwarders only after the read-only window closes and the retention plan has been checked. The output is a documented decommission record that compliance and audit teams can review.
Where Splunk Enterprise Security has no open-source equivalent
Wazuh and Security Onion cover much of the SIEM and detection work, but the premium layers of Splunk Enterprise Security have no direct open-source match. The cards below mark where coverage is partial or absent, and each one names what to confirm against current product documentation before you decide.
Premier-tier UEBA depth
Splunk sells UEBA as part of the Premier edition, and its behavioral baselines and entity risk scoring are built into the product. Wazuh and Security Onion provide rules, thresholds and anomaly-style detections, but they do not offer a packaged entity-behavior model out of the box. Ask your team to list the UEBA use cases it relies on today, then test each one against the open-source detections you plan to run.
Vendor threat intelligence feeds
Enterprise Security integrates threat intelligence as a managed part of the platform. Wazuh's vulnerability detection draws on the Wazuh Cyber Threat Intelligence platform or an offline repository, but general IOC feeds from commercial providers are not bundled. You will need to source, license and load those feeds yourself, and confirm the licensing terms of each provider before you ingest them.
Splunk app ecosystem integrations
Much of Splunk's connector and content coverage comes from its app and add-on marketplace, built by Splunk and by third parties. Open-source stacks cover common sources through agents, syslog and decoders, but a vendor-specific add-on may not have a maintained equivalent. List every add-on your team uses, then check whether an existing decoder, integration or custom parser covers each one.
Vendor support and SLAs
A commercial SIEM comes with vendor support terms, escalation paths and contractual response commitments. Wazuh and Security Onion are free to run, and their paid tiers or commercial support options vary by product. Support is a contract you must buy from a provider, not a feature you inherit. Ask each candidate for its written support terms, response targets and named escalation contacts before you plan the cutover.
Splunk search language depth
SPL is a mature, expressive search language that many analysts know well, and it drives Splunk's correlation searches and reports. Wazuh rules are written in XML with decoders, and Security Onion uses Suricata, Sigma and query tooling in the Elastic stack, so SPL searches do not transfer one to one. Budget time to rewrite your highest-value correlations and to retrain analysts on the new query model.
How much does it cost and how long does the work take
What are the cost components of replacing Splunk Enterprise Security with open source?
The main components are software licenses, compute and storage, staff time for detection content and upgrades, and outside support. Wazuh and OpenSearch carry no license fee for self-managed use, so the recurring spend shifts to infrastructure and people. Splunk's Enterprise Security cost sits on top of its platform licensing, and Splunk's own pricing page lists the models, so compare the Splunk renewal line by line with your infrastructure and staffing plan. Ask any quote to separate one-time costs (design, migration, rule rewrites) from recurring ones (hosting, patching, on-call, support subscriptions).
What drives the infrastructure cost of a self-hosted SIEM up or down?
Daily event volume, retention period, search concurrency and the number of monitored endpoints drive compute and storage. Wazuh's indexer stores alerts and can be scaled, and the Wazuh server can run as a cluster for horizontal scaling, so capacity can grow in steps. For Security Onion, the published minimums are 4 cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone node, 4 cores and 16 GB RAM for a manager or search node, and 4 cores, 12 GB RAM and 2 NICs for a sensor, per the Security Onion hardware documentation. Those are floors, not production sizing. Full packet capture and longer retention multiply storage, so size from your own measured volume.
Can our own team run Wazuh and Security Onion without outside help?
A team with Linux, search engine and detection engineering skills can run these platforms in-house, and both projects publish installation and architecture documentation. Wazuh documents all-in-one and step-by-step installs, an OVA, Docker, Kubernetes, Ansible and Puppet options. The harder work is ongoing: writing and tuning rules to replace Splunk correlation searches, onboarding log sources, handling upgrades and keeping the platform patched. Wazuh's 4.14 line received patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so plan for regular patch windows. Be honest about whether you have that capacity before deciding.
What should a fixed-scope engagement need from our side?
A written scope needs an inventory of log sources and endpoints, the current Splunk searches, dashboards and alerts that matter, the retention and compliance obligations you must meet, and named owners for detection approval and change windows. You should also provide hardware or cloud accounts, network paths between agents and servers, and access to the Splunk environment for export. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ask for the timeline in the written scope rather than relying on a general estimate.
How do Security Onion Pro and Wazuh support options change the cost picture?
Security Onion Pro is a paid edition sold on 1 to 5 year terms, and it adds OIDC single sign-on, LUKS encryption, FIPS mode, OS STIG compliance, an API, Manager of Managers, an MCP server, the Onion AI assistant and professional support. If you need those features or vendor support, price them as a recurring line item and confirm the term and scope with Security Onion Solutions. Wazuh is free under GPLv2, and Wazuh Cloud is a separate hosted offering, so confirm whether you need any paid support tier from Wazuh before budgeting. Support subscriptions are optional, but they shift risk and response obligations, so weigh them against in-house or DeployOpen retainer coverage.
How do air-gapped installs change the cost and effort?
Air-gapped installs add work before the platform works. Security Onion supports full installs on networks without internet access, where the ISO carries packages and NIDS, YARA and Sigma rules, and the soup tool updates from newer ISO media in airgap mode. Wazuh documents an offline installation guide and an offline vulnerability repository in place of its online threat intelligence platform. Expect extra effort for media transfer, approval of each update, and manual rule refresh, which recurs with every release. Confirm with each vendor how often offline content is refreshed and budget the staff time for that cycle.
Which Splunk migration steps add the most effort to the timeline?
The longest items are usually rewriting correlation searches as detection content, validating that alerts match what Splunk produced, and exporting historical data. Splunk offers export through Splunk Web, the CLI, the REST API, SDKs and the dump command, and Splunk calls the CLI its most stable retrieval method. Running both platforms in parallel until detections match adds licensing and infrastructure time while you do it. Ask any proposal to name how long parallel running lasts and who signs off on detection parity.
Does moving to open source remove compliance and audit costs?
No. Wazuh's dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, which reduces report-building effort, but those views do not make a system compliant. DeployOpen prepares systems, controls and evidence for compliance assessments, yet it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, and their fees are a separate cost to plan for.
How DeployOpen scopes and delivers an Enterprise Security replacement
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For an Enterprise Security replacement, we start from a written scope that maps your current correlation searches, detections, UEBA use and SOAR playbooks to Wazuh, Security Onion and any custom components you still need.
How we scope
- Inventory the Enterprise Security correlation searches, notable event types and risk-based alerting in use today
- Classify each detection as covered by Wazuh rules, Security Onion detections, custom rules or no open-source equivalent
- Agree in writing which data sources, deployment type and retention periods are in scope before work starts
How we build
- Deploy Wazuh indexer, server and dashboard, and Security Onion nodes in your cloud accounts, data centers or air-gapped networks
- Rewrite prioritized detections as Wazuh rules and decoders, and Sigma or Suricata rules where Security Onion fits
- Build playbooks for Shuffle or equivalent workflows and test each detection against recorded events before go-live
How we hand over
- Document architecture, rule ownership, tuning decisions and runbooks so your analysts can operate the stack
- Provide evidence of configured controls and detection coverage for your compliance and audit teams to review
- Run knowledge transfer sessions with your security engineers and record open gaps for your own decisions
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover
- Confirm the Wazuh and Security Onion release and end-of-life dates with the vendors before planning each upgrade
- Ask for the retainer scope in writing, covering patching, rule maintenance and incident support hours
