Open-source alternative to Datadog Cloud SIEM

Which open-source option replaces Datadog Cloud SIEM for your SOC

Wazuh, Security Onion and Graylog are the three self-hosted options to evaluate when a Datadog renewal or a residency requirement forces the question of who owns your SOC detections. Each covers a different part of what Cloud SIEM does: Wazuh focuses on host-based detection, file integrity and vulnerability correlation from endpoint agents; Security Onion combines network security monitoring with Suricata, Zeek and Sigma-based alerting; and Graylog provides log search, pipelines and event definitions. None of them is a drop-in feature match for Cloud SIEM's MITRE ATT&CK-mapped content packs, so treat the choice as a set of trade-offs to test against your own use cases.

Datadog Cloud SIEM runs on top of Datadog Log Management, so replacing it also means replacing where logs are stored, indexed and searched. Your current standard indexes, Flex Logs or Log Archives all need a destination in your environment, and the storage and search tier you choose sets the retention and query performance your analysts will live with. Graylog makes that tier explicit, with its own index model and a choice of Data Node or OpenSearch. Wazuh uses its indexer for alerts, and Security Onion runs Elasticsearch under the Security Onion Console. Confirm the storage design before you confirm the detection design.

Before choosing, ask each vendor and your own team four questions: which of your current detection rules map to a rule source you can carry over, which log sources must be ingested natively versus through a collector, how analysts will tune and suppress alerts, and who will patch and upgrade the stack. Check the license terms too. Security Onion's repository is under the Elastic License 2.0 and Graylog Open is under SSPL-1.0, so confirm with counsel whether your intended use, including any hosted service you offer, fits. Map your existing Cloud SIEM rules to the candidate platforms in a pilot before committing to a migration plan.

Mapping Datadog Cloud SIEM capabilities to open-source options

This table maps each main Datadog Cloud SIEM capability to what Wazuh, Security Onion and Graylog provide, and marks where the match is partial or missing. Read each row as a question to confirm in a proof of concept, since detection content and SOAR depend on your sources and tooling. The main takeaway is that the open-source options cover log analysis and detection well, but content packs and SOAR need planning and separate work.

Capability	Wazuh	Security Onion	Graylog Open
MITRE ATT&CK-mapped detection rules	Ships a rule set with decoders and rules on the Wazuh server. Confirm ATT&CK tagging on the specific rules you rely on.	Detections run as Suricata NIDS rules, Sigma rules and YARA rules. Mapping to ATT&CK depends on the rule source you load.	Event definitions and alerting are available in Open. Prebuilt threat detection content sits in the paid Graylog Security tier.
Coverage views by tactic and technique	Compliance dashboards are prebuilt for PCI DSS, GDPR, HIPAA and NIST 800-53. Confirm whether an ATT&CK coverage view exists in your release.	Detections interface manages rules and tuning. A dedicated ATT&CK coverage matrix is not confirmed, so verify before promising it.	Coverage views are not confirmed in Open. Risk and investigation features are in Graylog Security.
Content packs with parsers, dashboards and rules	No one-to-one equivalent to Datadog content packs. Decoders, rules and dashboards must be checked per log source.	No one-to-one equivalent. Parsing and dashboards depend on the sensor and log sources deployed.	No one-to-one equivalent. Inputs, pipelines and dashboards are built per source, and Datadog packs must be confirmed per integration.
Log ingestion and indexing	Agents on Linux, Windows, macOS and other systems, plus syslog for agentless devices. Alerts are indexed in the Wazuh indexer.	Elastic Fleet agents and Suricata feed Elasticsearch. Full packet capture uses Suricata in version 3.	Syslog, GELF and Beats inputs with streams and pipelines. Storage uses Data Node or OpenSearch, sized by your retention.
Investigation and response	Alert review in the Wazuh dashboard, plus remote agent configuration and upgrades. Active response depends on your configured rules.	Hunting and investigation in the Console, with full packet capture for network context.	Search and dashboards are included. Investigations and correlation depend on the paid tiers.
SOAR workflows	Not included as a SOAR engine. Automated response is limited to what the Wazuh server and agents can do, so a separate SOAR tool is usually needed.	Not included. Integrate with an external SOAR platform or scripts, and confirm the notification options you need.	Notifications to PagerDuty, Slack and email are documented. Multi-step SOAR workflows need a separate tool.
Compliance views and evidence	Prebuilt dashboards for PCI DSS, GDPR, HIPAA and NIST 800-53. Auditors must still review the controls you actually implement.	Compliance is not a headline dashboard. Hardening and control evidence must be built and confirmed by your team.	Compliance packs are part of Graylog Security. Open requires you to build reports and retention evidence yourself.
Licensing and support model	GPL-2.0 with an OpenSSL linking exception. Commercial support and Wazuh Cloud are separate options.	Elastic License 2.0 (source-available). Security Onion Pro is a paid edition with professional support.	SSPL-1.0 for Graylog Open, free with community support. Enterprise and Security tiers are paid.

Which self-hosted SIEM fits which SOC model

Wazuh suits a SOC that wants host-based detection, file integrity and vulnerability visibility across mixed endpoints, with compliance reporting built into the same console. It is split into four components: the Wazuh indexer, which stores and searches alerts, the Wazuh server, which decodes and analyzes agent data with rules, the Wazuh dashboard, and the Wazuh agents installed on endpoints. The server can run as a cluster, and it pushes agent configuration and upgrades remotely.

Agent coverage: Agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, so mixed estates can report to one server.
Agentless sources: Firewalls and other devices that cannot host an agent can send syslog, and the server can probe their APIs periodically.
Compliance views: The dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, which help with evidence gathering but do not replace an assessment.
License: Wazuh is distributed under GPL-2.0 with an exception for linking with OpenSSL, which should be reviewed by counsel for your distribution model.
Operating burden: You own the indexer sizing, cluster design, agent rollout and patch cadence, with 4.14 patch releases arriving roughly every one to two months.

Confirm with the vendor which deployment option (OVA, Docker, Kubernetes, Ansible or offline installation) fits your change-control process, and confirm the vulnerability data source you will use on isolated networks.

Where detection content comes from after the switch

Datadog Cloud SIEM ships curated content packs and an ATT&CK coverage view, and neither moves with your logs. Each candidate platform brings its own rule engine, so the detection work is a rebuild and not a configuration change. The cards below cover where each platform's rules live and what your team must confirm before cutover.

Wazuh decoders and rules

Wazuh's server parses agent and syslog data with decoders, then matches events against rules that raise alerts with severity levels. Rules are files you can extend, so Datadog detections you want to keep become Wazuh rules and decoders written for your log formats. Check that every log source behind a Datadog rule has a decoder in Wazuh, because a rule with no parsed field never fires. Confirm the rule-to-ATT&CK tagging you need, since you must add or verify it yourself.

Security Onion Sigma, NIDS and YARA

Security Onion splits detection by engine: Suricata runs NIDS rules, ElastAlert runs Sigma rules and Strelka runs YARA rules. The Console Detections interface lets you modify, suppress and threshold NIDS rules and add custom filters for Sigma. Sigma is the most portable format if you already write rules as vendor-neutral content. Note that Security Onion is licensed under the Elastic License 2.0, which is source-available, so confirm that license fits your policy before you build on its rule set.

Graylog event definitions and pipelines

In Graylog Open, event definitions run real-time or historical searches and send notifications, while processing pipelines normalize fields before a rule matches. Your Datadog log-based detections map to event definitions that query the same fields, so field naming must match after parsing. Graylog Open does not include a prebuilt SIEM content library, so your team writes or imports every detection. Confirm which correlation and threat content you need before you assume it is included in the free edition.

MITRE ATT&CK mapping you must build

Datadog Cloud SIEM shows rule coverage by tactic and technique, and that view depends on Datadog's own tagging. None of the three platforms reproduces that mapping for you, so each detection needs a technique ID you assign and maintain. Build a coverage matrix in a spreadsheet or a version-controlled file before cutover, then compare it with the techniques your SOC actually monitors. Treat this as ongoing work, because rules change and the matrix must follow them.

Inventory active Datadog rules first

Export a list of every enabled Datadog Cloud SIEM rule, including the content pack it came from, its data sources, its severity, and its suppression or exclusion filters. Separate rules you copied from curated packs from rules your team wrote, because only the second group reflects your own risk decisions. Use that inventory to choose the platform, since a source you cannot parse in a candidate tool defeats its rules. Record which rules alert your on-call staff so none are lost in cutover.

How log storage cost changes when Datadog Log Management leaves

Datadog Cloud SIEM does not replace the log bill, it sits on top of it. Cloud SIEM runs on Datadog Log Management, and logs can be stored in standard indexing, Flex Logs or Log Archives, so the cost you pay Datadog for security analytics is tied to how much you ingest, index and keep. When you move to self-hosted Wazuh, Security Onion or Graylog, those per-GB and retention charges disappear, but the same volume now lands on servers you run. The cost moves to compute, disk, backup and staff time. Before you sign anything, pull the current Datadog invoice and map each log category to its storage tier, so you know which data is indexed for search and which is archived.

Sizing is the first decision that drives the new bill. Graylog's system architecture guidance advises sizing log storage as daily ingest times retention days times 120 percent, and giving the message journal 3 to 5 times daily ingest on SSDs. For a Graylog deployment, a team with a known daily volume can run that formula directly against its retention policy. Wazuh and Security Onion size differently: Security Onion's documented minimums for a standalone node are 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, and for a manager or search node 4 cores and 16 GB RAM, while sensors need 4 cores, 12 GB RAM and 2 NICs. These are floors, not production sizing, so ask the vendor or partner to size retention and search nodes against your measured ingest.

Ask any quote to itemize the recurring and one-time parts separately: hardware or cloud instances, object or block storage by retention tier, backup of indices, SSD allowances for the journal, licensing if you choose a paid tier (Graylog Enterprise and Graylog Security start at 15,000 and 18,000 US dollars per year, respectively, per the Graylog pricing page), and the labor to operate upgrades and capacity growth. Request a retention schedule per data source and the expected growth rate of ingest, because retention length and ingest volume are the two inputs that push cost up fastest. Confirm with the partner whether historical logs exported from Datadog Log Archives will be restored into the new store, since restoring history adds storage and indexing work.

Migrating Datadog Cloud SIEM rules, sources and analysts

This sequence moves detection content, log sources and analyst workflows from Datadog Cloud SIEM to a self-hosted platform in stages, so each source and rule is validated before Datadog is switched off.

Inventory log sources and active detection rules
The security engineering lead exports the list of log sources feeding Datadog Log Management and the enabled Cloud SIEM detection rules, grouped by content pack and by MITRE ATT&CK tactic and technique. Record each rule's query, severity, suppression filters and any linked SOAR workflow, because these define the behavior the SOC depends on. The step is complete when every source has an owner and every active rule has a row in a shared register marked for keep, rewrite or retire.
Select the platform by coverage gap
Compare the register against the candidate platforms: Wazuh for host and endpoint telemetry with vulnerability detection, Security Onion for network security monitoring with Suricata and Zeek, and Graylog for log search, pipelines and event definitions. Confirm each platform's support for your specific sources, detection formats and compliance reporting in writing with the vendor or your integrator. The step is complete when a documented decision lists which source families go to which platform and what gaps remain.
Build the self-hosted stack in a pilot network
The platform team deploys the chosen option in a non-production network using the vendor's documented deployment path, with hardware checked against the vendor's minimum requirements and a distributed or cluster design where production load requires it. For Security Onion, confirm x86-64 hardware and the Oracle Linux 9 requirement for the 3.x line. For Graylog, confirm the MongoDB and OpenSearch or Data Node versions against the compatibility matrix. The step is complete when the pilot ingests test events end to end and the health of every component is confirmed.
Map detection rules to the new engine
Detection engineers translate each retained Datadog rule into the native format of the target platform, such as Wazuh decoders and rules, Suricata or Sigma rules in the Security Onion Console, or Graylog event definitions. Keep the MITRE ATT&CK tags so coverage views can be rebuilt, and record any rule with no equivalent as a documented gap with a compensating control. The step is complete when each register row points to its new rule identifier or to a recorded gap decision.
Run dual ingestion from the same pipeline
Platform engineers fan out each source once through an OpenTelemetry Collector or a syslog relay, sending the same events to Datadog and to the pilot platform in parallel. This keeps the sources identical during evaluation and avoids reconfiguring endpoints twice. The step is complete when event counts per source are compared across both platforms over an agreed window and any parsing differences are logged and fixed.
Validate alerts against known events
The SOC replays or triggers known test events, such as authentication failures, a benign malware test or a policy violation, and checks that each migrated rule fires on the new platform and that the same events produced a signal in Datadog. Review suppression and threshold settings with the analysts who own them, since differences here change alert volume. The step is complete when a signed-off test record shows each in-scope rule raised the expected alert or has a documented exception.
Cut over sources and retire Datadog routing
Operations staff repoint each source to the new platform one group at a time, starting with lower-risk sources, and remove the Datadog exporter only after the new alerts have been monitored for the same period. Update analyst runbooks, case workflows and on-call routing, and train the SOC on the new search syntax and dashboards. The step is complete when no in-scope source sends to Datadog, the SOC has accepted the runbooks, and the cutover record is filed.
Export archives and signal history for retention
The compliance lead requests Datadog Log Archives to your own object storage for the retention period your policy requires, and exports the rule definitions and dashboards as JSON. Datadog signal history is limited to what the Log Archives and API export provide, so confirm with Datadog what can be exported before decommissioning, and record any gap for auditors. The step is complete when the archive copy is verified readable and the export inventory is approved by the data owner.

What changes for analysts, detection engineers and the SOC

Moving off Datadog Cloud SIEM changes more than the log store. Analysts lose a hosted query and case workflow, detection engineers take on rule content, and the SOC inherits paging, patching and capacity work. Confirm each item with your chosen vendor and your own runbooks before cutover.

Query language and dashboards

Datadog analysts search with its hosted log query syntax and saved views. Wazuh, Security Onion and Graylog each use their own search layer: Wazuh alerts sit in the Wazuh indexer and dashboard, Security Onion searches through its Console on Elasticsearch, and Graylog uses its own query language over OpenSearch or Data Node. Ask the vendor which query language, field names and dashboard formats apply, and have analysts rewrite their ten most-used searches before go-live.

Alert triage and case handling

Datadog Cloud SIEM bundles signal triage with its log and security views. In the open-source options, triage depends on which console you choose and what it includes. Graylog Open offers event definitions and notifications, while Security Onion Pro adds features such as OIDC single sign-on and external notifications. Map each current triage step, including who closes signals and where case notes live, to a tool or a documented manual process.

On-call routing to rebuild

Datadog routes Cloud SIEM signals through its monitors and notification integrations, and those routes will not carry over. Graylog Open lists PagerDuty, Slack and email as notification targets, and Security Onion supports external notifications only in its Pro edition. Confirm which destinations your escalation policies need, test each route with a sample alert, and document severity thresholds before retiring the Datadog routes.

Detection content ownership

Datadog ships curated content packs with rules, dashboards, parsers and SOAR workflows, and it maps rules to MITRE ATT&CK. In a self-hosted stack, detection engineers own that content. Security Onion loads NIDS rules into Suricata, Sigma rules into ElastAlert and YARA rules into Strelka, and Wazuh uses decoders and rules on the server. Confirm which ATT&CK coverage you need, then track rule source, licence and tuning history in version control.

Patching and upgrade cadence

Datadog patches its hosted service for you. Self-hosted, your team applies every component update. Wazuh shipped six 4.14 patch releases in 2026, and Security Onion 2.4 reaches end of life on October 1, 2026. Assign an owner for each component, subscribe to release notes, and test upgrades in a non-production copy before each window.

Capacity and on-call for the platform

Someone must watch disk, indexing lag and node health once the stack runs in your environment. Graylog advises sizing storage as daily ingest times retention days times 120 percent, and Security Onion's architecture notes that search nodes stop indexing if the manager goes down. Ask the vendor for a production sizing review and add platform health alerts to the on-call rota that the SOC already staffs.

Questions buyers ask before replacing Datadog Cloud SIEM

Does an open-source option match Datadog Cloud SIEM feature for feature?

No single open-source tool matches Cloud SIEM feature for feature, and the gaps depend on which one you choose. Wazuh covers host-based detection, file integrity, vulnerability detection and prebuilt compliance views for PCI DSS, GDPR, HIPAA and NIST 800-53, and it works with agents on endpoints and syslog from devices such as firewalls. Security Onion adds network security monitoring with Suricata, Zeek and Sigma rules. Graylog covers log search, streams, pipelines and correlation-style event definitions, while its risk scoring, anomaly detection and prebuilt threat content sit in the paid Graylog Security tier. Map your current Cloud SIEM rules and log sources to each tool before you commit, and confirm MITRE ATT&CK coverage with the vendor, because the supplied documentation does not give a coverage count for any of them.

What does an open-source SIEM replacement cost, and what drives it?

The software licenses for Wazuh and Security Onion Community are free, while Graylog Open is free with no volume limits and community support. The recurring costs are staff time, server hardware or virtual machines, storage and any paid support you choose. Storage is often the largest driver: Graylog's architecture guidance sizes log storage as daily ingest times retention days times 120 percent. Security Onion's minimum hardware for a standalone node is 4 cores, 24 GB RAM and 200 GB storage, and it supports only x86-64 processors. Paid options include Graylog Enterprise, which starts at 15,000 US dollars per year, and Graylog Security, which starts at 18,000 US dollars per year, both per the Graylog pricing page, with a minimum of 10 GB per day or 100 Graylog Compute Units. Security Onion Pro is sold on 1 to 5 year terms. Ask any partner for a written quote that separates one-time setup from recurring hosting, storage and support.

How long does a Cloud SIEM migration take?

The timeline depends on the number of log sources, the detection content you need to rebuild, the hardware lead time and how much tuning your SOC requires. No duration is supplied for this migration, so ask for one in a written scope. The main steps are sizing the platform, deploying the manager or indexer, onboarding agents or sensors, mapping Cloud SIEM rules to Wazuh rules, Suricata or Sigma content, and running both platforms in parallel until alert quality is acceptable. Wazuh's offline and Security Onion's airgap guidance can extend the work if your network is isolated. Plan for a dual-running period, and do not retire Datadog log ingestion until your analysts have validated alerts on the new platform.

Can our team run this replacement alone, or do we need a partner?

A team with Linux administration, log engineering and SOC detection experience can often run a self-hosted SIEM, but the work is larger than installing software. Security Onion's production design is Distributed, with a manager, sensors and search nodes, and Graylog's multi-node guide recommends three Graylog and MongoDB nodes, three Data Nodes and a load balancer. Each of these needs patching, backup and monitoring. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, usually under a fixed-scope agreement with written deliverables and timelines. Ongoing support and upgrades are available as retainers. Ask us for a written scope covering your sources, detections and runbooks, and compare it against your internal capacity.

Which license limits apply to commercial use of Wazuh, Security Onion and Graylog?

Wazuh is distributed under GPL-2.0 with an OpenSSL linking exception, which permits commercial use, but you must follow the GPL's source-availability terms if you distribute modified binaries. Security Onion's repository is under the Elastic License 2.0, a source-available license rather than an OSI-approved open-source license, so ask counsel to confirm how its terms apply to your planned internal use and any service you offer to others. Graylog Open is under the Server Side Public License version 1 (SSPL-1.0), which is not OSI-approved and carries obligations if you offer Graylog as a managed service. Internal SOC use is generally different from resale, but confirm the terms for each component against its LICENSE file before you deploy.

What should we do about the Security Onion 2.4 end-of-life date?

Security Onion 2.4 reached end of life on October 1, 2026, so an existing 2.4 deployment no longer receives support and should be moved. Installations on Oracle Linux 9 can upgrade to Security Onion 3 after you move full packet capture from Stenographer to Suricata, which 3.0.0 requires because it replaced Stenographer. Other distributions need a fresh install. Security Onion 3.0.0 supports only Oracle Linux 9. Before you plan, check the current end-of-life page and the latest tagged release, and confirm your hardware meets the x86-64 and minimum specifications. Treat the upgrade as a change with its own test window, not a background patch.

Will our analysts lose detection coverage during the switch?

Coverage can drop during the switch if detection content is not translated and validated. Cloud SIEM rules are mapped to MITRE ATT&CK tactics and techniques, and the open-source tools use different rule formats: Wazuh uses its own decoders and rules, Security Onion uses Suricata NIDS rules, Sigma rules in ElastAlert and YARA rules, and Graylog uses event definitions. Export your current rule inventory, record which ATT&CK techniques each one covers, and rebuild them in the target format. Run both systems in parallel and compare signal volumes for each rule before retiring Datadog detections. Security Onion's Detections interface supports tuning and suppression, which helps reduce noise during this period.

Can Cloud SIEM logs be exported to keep history during a move?

Logs held in Datadog Log Management can be routed to your own storage through Log Archives, which can keep history available for search in your environment, but the open-source tools do not ingest those archives automatically. Datadog Cloud SIEM stores logs in standard indexing, Flex Logs or Log Archives, so confirm which tier holds your data before you plan the export. Ask the migration team to define how much history must remain searchable, how archived data will be reindexed or retained, and which compliance evidence must survive the cutover. Keep this decision with your compliance lead, because retention obligations may differ by log source.

Keeping Datadog for APM and metrics while the SIEM moves

You do not have to move everything at once. A SOC can move security logs first and keep Datadog for APM, infrastructure metrics and monitoring while the detection estate is rebuilt. The mechanism that makes this practical is the fan-out. Datadog accepts OpenTelemetry data through the Datadog Agent with its DDOT Collector, through a standard OpenTelemetry Collector pipeline exporting over OTLP, or by direct OTLP ingestion. A Collector pipeline with two exporters, one to Datadog and one to a self-hosted Wazuh or Graylog deployment, can send the same security-relevant log stream to both destinations. Syslog forwarding from firewalls, identity providers and endpoints can often be duplicated at the source in the same way. Confirm with your Datadog account team which log sources you ship through the Agent and which go to Datadog directly, because the fan-out point differs for each.

Two constraints shape the plan. Each Datadog site is completely independent and data cannot be shared across sites, so the site that holds your Cloud SIEM data is also where your APM and metrics live, and you cannot split them across regions to suit a residency rule. Confirm the site your organization uses, and check whether any security data you plan to keep only in your own infrastructure would fall under a residency or retention obligation that the current Datadog site does not meet. Your self-hosted SIEM must also be sized for the log volume you duplicate, which means knowing which sources feed both platforms before you agree a dual-shipping window.

Plan the cutover decision now. Record which detections are running in Datadog Cloud SIEM, which data sources they depend on, and which owner signs off when Datadog is no longer the system of record for security alerts. Keep dual-shipping for long enough to compare alert outputs on the same events, and document any gap where a Datadog rule has no equivalent yet. Ask any implementation partner to put that comparison, the fan-out configuration and the site-level constraints into a written scope before work starts.

How DeployOpen scopes and delivers a SIEM replacement

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Datadog Cloud SIEM replacement, we start from the detection content and log sources your SOC depends on, then build the chosen platform in your cloud accounts, data centers or air-gapped network.

How we scope

Inventory the log sources, detection rules and MITRE ATT&CK coverage that Datadog Cloud SIEM currently provides.
Agree which platform fits the scope: Wazuh, Security Onion or Graylog, with the license terms confirmed in writing.
Set the retention, storage sizing and network placement the written scope will cover before work starts.

How we build

Deploy the chosen platform in the target environment, using the installation method your architecture requires.
Rebuild or translate detection rules, alert routing and dashboards, then test them against replayed or live log samples.
Harden access control, single sign-on and encryption to match your internal security baseline and compliance needs.

How we hand over

Document architecture, data flows, rule inventory, tuning decisions and runbooks for your SOC and platform teams.
Provide evidence of configuration and detection coverage that your internal or external auditors can review.
Train analysts on triage, rule tuning and the console workflows that replace Datadog Cloud SIEM views.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Plan version upgrades and patch cycles with your change management process, including offline update paths where needed.
Ask any provider to confirm support terms, upgrade paths and licensing obligations in writing before you commit.