Open Source SIEM in 2026: Wazuh, ELK, or Autonomous Agent?
An unfiltered comparison of Wazuh, ELK Stack, and Graylog. Why SIEM alone is no longer enough, and how an AI agent completes the equation.
The SIEM remains the backbone of any security program. But in 2026, the question is no longer "which SIEM?", it's "what do you put on top of the SIEM?". I've deployed Wazuh, ELK, and Graylog in production environments from 50 to 5,000 machines. Here's an honest debrief.
Wazuh: the open source Swiss army knife
Wazuh has become the reference open source SIEM/XDR, and for good reasons.
Wazuh strengths
-
Lightweight agent: deploys on Linux, Windows, macOS with an agent using <50 MB RAM
-
Native detection: MITRE ATT&CK-mapped rules, rootkit detection, file integrity monitoring (FIM)
-
Built-in compliance: PCI DSS, HIPAA, GDPR, NIST 800-53 reports out of the box
-
Vulnerability detection: CVE scanning on installed packages, CVSS scoring
-
Kibana/OpenSearch dashboard: powerful visualization, active community (18,000+ GitHub stars)
Wazuh limitations
-
Indexer scaling: beyond 500 agents, the Elasticsearch/OpenSearch cluster requires serious tuning (heap size, sharding, retention). Budget for a dedicated admin.
-
Static rules: detection relies on rules. No native ML, no behavioral analysis. An attacker who stays below rule thresholds goes undetected.
-
No automated response: Wazuh detects and alerts. The response is on you. At 3 AM.
-
Limited correlation: correlation rules are basic compared to commercial SIEMs. Complex attack chains require custom rules.
ELK Stack (Elasticsearch, Logstash, Kibana)
ELK isn't a SIEM per se. It's a log management platform on which you build a SIEM. The distinction matters.
ELK strengths
-
Total flexibility: you can ingest anything via Logstash/Beats/Elastic Agent
-
Elastic Security: since Elastic 8.x, SIEM detection rules are built in (800+ pre-packaged rules)
-
Performance: distributed search engine, built for volume
-
Elastic AI Assistant: LLM integration for analysis (recent, still immature)
ELK limitations
-
Operational complexity: running an Elasticsearch cluster in production is a job in itself. Index lifecycle management, cold/warm/hot architecture, snapshots, cluster monitoring...
-
Hidden cost: "open source" doesn't mean free. Budget for 2-3 servers minimum, an engineer who knows Elasticsearch, and advanced features (ML, RBAC) are behind paid licenses.
-
No response: like Wazuh, ELK detects but doesn't respond.
Graylog: the outsider
Graylog deserves mention for environments that prioritize structured log management.
-
Strengths: powerful processing pipeline, flexible alerting, clean interface, better multi-tenant support than ELK
-
Weaknesses: smaller community, fewer SIEM detection rules than Wazuh, dependency on MongoDB + Elasticsearch, the Security version is commercial
Why SIEM alone is no longer enough
Here's the real problem. Whether you pick Wazuh, ELK, or Graylog, you get:
-
Log collection ✓
-
Rule-based detection ✓
-
Alerting ✓
-
Compliance reporting ✓
But you do not get:
-
Intelligent correlation: linking an abnormal SSH connection + a suspicious DNS query + an unusual file transfer into a single incident
-
Behavioral detection: identifying that a user is deviating from their baseline without a predefined rule
-
Automated response: isolate, block, capture without human intervention
-
Contextual prioritization: differentiating a critical alert on a production server from an identical alert on a dev environment
This gap between detection and action explains the 194-day dwell time (IBM 2025). The SIEM tells you something is happening. Nobody does anything for 6 months.
ThreatClaw: the intelligence layer on top of your SIEM
ThreatClaw doesn't replace your SIEM. It connects to it and adds what's missing:
-
Alert ingestion from Wazuh/ELK/Graylog via API or syslog
-
Reasoning-based correlation: the AI agent links events that static rules cannot correlate
-
Behavioral baseline: 14 days of learning, then ML-powered anomaly detection
-
Graduated response: Sentinel (alert), Hybrid (approved proposal), Autonomous (immediate action)
-
49 specialized skills: continuous auditing with Lynis, Trivy, OWASP ZAP, Nmap, CIS Benchmarks
The architecture is simple: your SIEM does what it does well (collect, index, search). ThreatClaw does what it does well (reason, decide, act). The two complement each other.
Which combination to choose?
Here's my pragmatic take based on size:
-
SMB <100 machines: Wazuh + ThreatClaw. Wazuh handles collection and compliance, ThreatClaw handles advanced detection and response. Cost-effective.
-
Mid-market 100-1,000 machines: Wazuh or ELK depending on internal skills + ThreatClaw. If you have an Elasticsearch admin, ELK offers more flexibility.
-
Enterprise >1,000 machines: your existing commercial SIEM (Splunk, QRadar, Sentinel) + ThreatClaw as a reasoning and response layer.
FAQ
Is Wazuh really free?
The software is 100% open source (GPLv2). The real cost is infrastructure (servers for the indexer, storage) and human administration time. For 100 agents, budget 1-2 dedicated servers and about 10-15 hours/month of administration. Wazuh also offers a paid cloud service.
Can you use ThreatClaw without a SIEM?
Yes. ThreatClaw can collect logs directly through its own agents and integrations. But combining with a SIEM is recommended for long-term retention and compliance reporting. The SIEM is your memory; ThreatClaw is your brain.
ELK or OpenSearch in 2026?
Since the 2021 fork, OpenSearch has caught up with Elasticsearch on most features. If you already use Wazuh, it includes OpenSearch by default. For a new standalone deployment, both are comparable. The OpenSearch community is more open; Elastic has more commercial features. Pragmatic choice, not dogmatic.
How long to deploy Wazuh + ThreatClaw?
Wazuh: 1-2 days for the server, a few minutes per agent (deployable via Ansible/Puppet). ThreatClaw: under 48 hours. The behavioral baseline is operational after 14 days. Budget 3 weeks total before having a fully functional stack.
Related articles
Wazuh, Elastic/Security Onion, Graylog, OpenSearch — a genuinely balanced comparison of free and open-source SIEM options for SMBs, with real resource requirements, a Sigma-ingestion table, and the part every vendor page skips: what happens after install day.
Rule count is a vanity metric. Here is the checklist that actually decides whether a Sigma, YARA or NIDS detection feed is worth paying for: license for resale, deduplication, conversion coverage, false-positive discipline, signature and maintenance cadence.
SigmaHQ is free, so why pay for a Sigma rule feed? A practical comparison of the public corpus, SOC Prime, Nextron Valhalla and curated feeds, with the criteria that actually matter for a SOC or MSSP.
How to convert Sigma rules into SPL queries with pySigma, handle CIM field mapping, avoid rules that match nothing, and maintain the pipeline at scale.