Almost every SIEM comparison lists the same features in three columns and declares a winner. That is not where these decisions go wrong. They go wrong because Wazuh, Splunk and the Elastic Stack are three different kinds of product, and the cost of each only becomes visible in year two.
They are not the same category
Getting this clear first saves most of the argument.
Wazuh is a security product that brings its own data platform. It ships agents, built-in detection rules, file integrity monitoring, rootkit detection and compliance mappings out of the box. You install it and it is already detecting things. Underneath it uses an OpenSearch-derived indexer, but you mostly do not think about that.
The Elastic Stack is a data platform you build security on top of. Elasticsearch stores and searches, Beats and Logstash collect, Kibana visualises, and Elastic Security is the detection layer sitting above them. It is enormously flexible and it expects you to do the building.
Splunk is a mature data platform with a mature security product sold separately. Splunk Enterprise ingests and searches; Enterprise Security is the SIEM layer with correlation, risk-based alerting and an analyst workflow. The search language is the best of the three by a clear margin.
So "which is the best SIEM" is the wrong question. The right one is how much security engineering you intend to do yourself, and what happens to the bill when your log volume doubles.
The cost models, which is where the real difference lives
Splunk charges for data, and that is the whole risk. Historically by ingest volume per day, more recently also by workload. Either way, the bill moves with how much you send, and the things you most want to log — endpoint process creation, DNS queries, verbose cloud audit trails — are exactly the high-volume sources.
The predictable failure is that teams start filtering at the collector to stay inside the licence, and the filtering decisions are made by cost rather than by detection value. You end up with an expensive SIEM that cannot answer the question you bought it for, because the data that would have answered it was dropped to save licence.
Wazuh is free, and you pay in operations. No licence, no ingest tier. You pay by running the indexer cluster yourself — sizing it, upgrading it, keeping it healthy, managing retention and storage. That is a real and recurring cost, and it is a person rather than an invoice. Teams that already run infrastructure well absorb it easily. Teams that do not will have an unhealthy cluster within a year.
Elastic sits in between. The free tier is genuinely generous and the stack is open, but several things you will want — advanced detection rules, machine learning, some integrations — sit in paid tiers. Self-managed, you take on the same operational burden as Wazuh; on Elastic Cloud, you are back to a resource-based bill.
What you actually get on day one
This is the difference most comparisons miss.
Install Wazuh and point agents at it, and it is already alerting: failed logins, file changes in sensitive paths, suspicious processes, vulnerable packages, and compliance mappings for PCI DSS, HIPAA, GDPR and NIST. For a small team with no detection engineer, that out-of-the-box coverage is the single strongest argument for it.
Install Elasticsearch, and you have a very good search engine with no opinion about security until you add Elastic Security, install integrations and enable rules. More work, more control.
Install Splunk and you have superb search over whatever you have sent it. Meaningful detection means Enterprise Security or writing your own correlation searches.
Searching and investigating
Splunk's SPL is the strongest query language here, and it is not close. Complex investigative pivots that take one SPL line take noticeably more work elsewhere. If your analysts are experienced and spend their day in search, this is a genuine productivity difference that partly justifies the price.
Elastic's query options have improved considerably and are good enough for most work. Wazuh's interface is oriented around its own rules and dashboards rather than open-ended investigation; you can query the indexer directly, but it is not the product's strength.
Endpoint coverage
Wazuh includes an agent that does host intrusion detection, file integrity monitoring, log collection and vulnerability detection. One deployment covers both log collection and endpoint security, which is a real consolidation saving.
With Splunk or Elastic you deploy a forwarder or Beats agent for collection, and separately decide what provides endpoint detection. Elastic Defend covers this within the stack; Splunk expects you to bring something.
Which one, honestly
Choose Wazuh if you have no dedicated detection engineer, you need compliance evidence quickly, your budget is constrained, and you have someone competent to run the infrastructure. It is the fastest route from nothing to real coverage.
Choose Elastic if you already run Elasticsearch, you want one platform for security and observability, and you have the engineering capacity to build detections rather than inherit them.
Choose Splunk if analyst productivity is the constraint, your data volume is predictable enough to budget, and the organisation can support the licence. Where the SOC is large enough that an hour of analyst time matters more than the subscription, SPL pays for itself.
Three questions to answer before you decide
- What is your realistic daily log volume, and what will it be when you add the sources you have not onboarded yet? Most teams underestimate by a wide margin, because endpoint and DNS data dwarf everything else.
- Who writes and tunes the detections? If the answer is nobody, you need the platform that ships with them.
- Who owns the cluster at 2am? Free software with no operator is not cheaper than a licence.
And whichever you pick, remember the uncomfortable truth underneath all three: a SIEM nobody tunes becomes an alert queue nobody reads. The platform choice matters far less than whether someone owns the detections, which is covered in detection engineering basics and, for the staffing side of it, in building a SOC or buying one.
0 comments
Leave a comment