Pros
- • Completely free and open-source - zero licensing costs for unlimited agents and data ingestion
- • Unified SIEM + XDR platform: log analysis, FIM, SCA, vulnerability detection, and active response in one agent
- • Native MITRE ATT&CK mapping on every alert - immediate adversary tactic context for every detection
- • Multi-node cluster architecture scales horizontally to handle millions of events per day
- • Built-in compliance dashboards for PCI DSS, HIPAA, GDPR, NIST 800-53, TSC, and CMMC
- • 620,000+ community members and 10M+ Docker pulls - the most widely deployed open-source SIEM on the planet
- • Deep cloud integrations: AWS, Azure, GCP, Office 365, Docker, and Kubernetes monitoring out-of-the-box
Cons
- • No vendor-managed SaaS option - you own the infrastructure, patching, and scaling
- • Initial deployment and rule tuning requires strong Linux and security engineering skills
- • High EPS environments require careful Indexer cluster sizing and ongoing performance tuning
- • Custom decoder/rule authoring has a steep learning curve compared to commercial alternatives
- • No built-in SOAR - requires Shuffle or TheHive integration for automated response workflows
In a market where enterprise SIEM platforms charge $100,000 to $500,000 per year in licensing fees, Wazuh has built something remarkable: a production-grade, unified SIEM and XDR platform used by over 620,000 organizations worldwide - at zero licensing cost.
Wazuh is not a hobbyist project or a learning sandbox. It protects the infrastructure of banks, government agencies, healthcare systems, and Fortune 500 companies. It processes millions of security events per day. It satisfies PCI DSS, HIPAA, GDPR, and NIST 800-53 compliance requirements in regulated industries.
This is the complete practitioner’s guide to deploying it the right way - at production scale, with high availability, and with the depth of configuration required to extract its full defensive value.
What Wazuh Actually Is
Wazuh is a unified open-source security platform that combines SIEM (Security Information and Event Management) and XDR (Extended Detection and Response) capabilities into a single, cohesive ecosystem.
The platform does not compromise: it delivers capabilities that compete directly with Splunk Enterprise Security, IBM QRadar, and Microsoft Sentinel - not by approximating their features, but by implementing them fully in a freely available, self-hosted architecture.
| Capability | What Wazuh Delivers |
|---|---|
| Log Collection & Analysis | Agents on every endpoint, syslog from network devices, cloud API polling, container log collection |
| File Integrity Monitoring (FIM) | Real-time detection of file, directory, and registry changes across all monitored hosts |
| Security Configuration Assessment (SCA) | Automated CIS Benchmark compliance checks with pass/fail scoring and remediation guidance |
| Vulnerability Detection | Cross-references installed package inventory against NVD, OSV, and vendor CVE databases |
| Threat Detection | 3,000+ built-in detection rules mapped to MITRE ATT&CK TTPs |
| Active Response | Automated firewall blocks, process kills, and custom script execution on agent hosts |
| Cloud Security | AWS CloudTrail, Azure Activity Logs, GCP Audit Logs, Office 365 APIs - all natively ingested |
| Container Security | Docker and Kubernetes monitoring with audit log collection |
| Compliance Reporting | Pre-built dashboards for PCI DSS, HIPAA, GDPR, NIST 800-53, TSC, CMMC |
| MITRE ATT&CK | Every alert tagged with tactic, technique, and sub-technique identifiers |
The Four-Component Architecture
Wazuh’s multi-node architecture separates four distinct functional components, each of which can be independently scaled, clustered, and optimized. Understanding what each component does - and what happens when it is under-resourced - is the foundation of a successful production deployment.
Component 1: Wazuh Agent
The Wazuh Agent is the lightweight endpoint sensor installed on every monitored host. It is the eyes and ears of the platform.
Supported Platforms:
- Linux (all major distributions: Ubuntu, RHEL, CentOS, Debian, Amazon Linux, SUSE)
- Windows (7 through Server 2022)
- macOS (10.12 Sierra through Ventura and later)
- FreeBSD, OpenBSD, Solaris, AIX, HP-UX
What the Agent Collects:
┌─────────────────────────────── Wazuh Agent ────────────────────────────────┐
│ │
│ Log Collection File Integrity System Inventory Active Response │
│ ───────────── ────────────── ──────────────── ─────────────── │
│ • /var/log/* • FIM engine • Running procs • firewall-drop │
│ • Windows EVT • Real-time • Packages/ports • kill-process │
│ • Syslog • Scheduled scan • OS fingerprint • Custom scripts │
│ • Application • Audit rules • HW inventory • disable-user │
│ • Custom files • Diff storage • Network ifaces • quarantine │
│ │
│ Security Configuration Assessment Vulnerability Detector │
│ ───────────────────────────────── ──────────────────────── │
│ • CIS Benchmarks (Linux, Windows) • Package → CVE correlation │
│ • Pass/fail/NA scoring • NVD / OSV database queries │
│ • Policy compliance % • CVSS scoring + severity │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
│ Encrypted TLS (port 1514)
▼
[Wazuh Server]
Agent Resource Footprint:
- CPU: < 0.5% average on modern hardware
- RAM: ~20-40 MB idle, up to 150 MB during FIM scans
- Network: ~1 Kbps per agent average (bursts during FIM/SCA)
The agent connects to the Wazuh Server on port 1514/TCP (encrypted) and receives configuration updates and active response commands back through the same channel. Agents can operate in proxy mode through a Wazuh Agent Enrollment gateway, eliminating direct firewall exposure of the server cluster.
Component 2: Wazuh Server (Manager)
The Wazuh Server is the analytical engine. It receives raw events from agents, decodes them, applies detection rules, generates alerts, and forwards structured results to the Indexer.
Internal Processing Pipeline:
[Agent Events] ──► [Input Queue] ──► [Pre-Decoding] ──► [Decoding Engine]
│
┌────────────────────────────────┘
▼
[Rule Engine] ──► [Alert Generation] ──► [Filebeat]
│ │ │
[Active Response] [Syslog Output] [Wazuh Indexer]
[Email Alerts] [CEF/LEEF Output]
Key Processing Components:
| Component | Function |
|---|---|
| Decoder Library | 3,000+ XML decoders that parse raw log text into structured fields (src_ip, user, action, event_id, etc.) |
| Rule Engine | 3,000+ detection rules with composable logic, frequency counters, correlation windows, and MITRE ATT&CK tags |
| CDB Lists | Hash-based lookup tables for known-bad IPs, malicious domains, whitelisted users - enable high-speed enrichment |
| Active Response Daemon | Executes firewall rules, process termination, and custom scripts on agent endpoints in response to triggered alerts |
| Cluster Daemon | Synchronizes rule sets, decoders, CDB lists, and agent keys across all nodes in a Server cluster |
| Filebeat | Ships structured JSON alerts from the Server to the Wazuh Indexer over TLS |
Custom Rule Example - Detecting LSASS Memory Access:
<rule id="100100" level="12">
<if_group>windows</if_group>
<field name="win.system.eventID">^10$</field>
<field name="win.eventdata.targetImage" type="pcre2">(?i)lsass\.exe</field>
<field name="win.eventdata.grantedAccess" type="pcre2">0x1410|0x1010</field>
<description>Possible credential dumping - suspicious LSASS access detected</description>
<mitre>
<id>T1003.001</id>
</mitre>
<group>credential_access,lsass,windows</group>
</rule>
Hardware Sizing (Per Server Node):
| Environment | Agents | EPS | CPU | RAM | Disk |
|---|---|---|---|---|---|
| Small | Up to 500 | < 500 | 4 cores | 8 GB | 500 GB SSD |
| Medium | 500-3,000 | 500-3,000 | 8 cores | 16 GB | 1 TB SSD |
| Large | 3,000-10,000 | 3,000-10,000 | 16 cores | 32 GB | 2 TB SSD |
| Cluster | 10,000+ | 10,000+ | Multiple nodes | 16 GB/node | 1 TB SSD/node |
Component 3: Wazuh Indexer
The Wazuh Indexer is the data persistence and search layer - a purpose-tuned distribution of OpenSearch, optimized for security alert ingestion and high-performance querying.
What the Indexer Stores:
- All alerts generated by the Wazuh Server (structured JSON)
- Raw event archives (optional, enabled per agent group)
- FIM event database (file change history)
- Vulnerability scan results
- SCA compliance check results
- Statistical summaries and agent status data
Index Architecture:
wazuh-alerts-4.x-YYYY.MM.DD ← Daily alert index (primary search target)
wazuh-archives-4.x-YYYY.MM.DD ← Raw event archive (optional, very high volume)
wazuh-monitoring-4.x-YYYY.MM.DD ← Agent health and statistics
wazuh-statistics-4.x-YYYY.MM.DD ← Server performance metrics
Multi-Node Cluster Configuration (config.yml):
# /etc/wazuh-indexer/opensearch.yml (Node 1 - Master-eligible)
network.host: 192.168.1.10
node.name: wazuh-indexer-1
cluster.name: wazuh-cluster
# Cluster peers
discovery.seed_hosts:
- "192.168.1.10:9300"
- "192.168.1.11:9300"
- "192.168.1.12:9300"
cluster.initial_master_nodes:
- "wazuh-indexer-1"
- "wazuh-indexer-2"
- "wazuh-indexer-3"
# Performance tuning
indices.query.bool.max_clause_count: 2048
thread_pool.search.queue_size: 10000
# Security
plugins.security.ssl.transport.pemcert_filepath: /etc/wazuh-indexer/certs/node.pem
plugins.security.ssl.transport.pemkey_filepath: /etc/wazuh-indexer/certs/node-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem
plugins.security.ssl.http.enabled: true
Hardware Sizing (Per Indexer Node):
| Environment | Daily Alerts | Retention | CPU | RAM | Disk (SSD) |
|---|---|---|---|---|---|
| Small | < 1M | 90 days | 4 cores | 8 GB | 2 TB |
| Medium | 1M-10M | 90 days | 8 cores | 16 GB | 4 TB |
| Large | 10M-50M | 90 days | 16 cores | 32 GB | 8 TB |
| Enterprise | 50M+ | 180 days | 16 cores × 5+ nodes | 32 GB/node | 16 TB/node |
Critical: Always use SSD storage for Indexer nodes. HDD-based clusters exhibit severe search latency degradation under even moderate alert loads. Pre-warming JVM heap to 50% of available RAM (max 31 GB per node) is essential for production stability.
Component 4: Wazuh Dashboard
The Wazuh Dashboard is the operational interface for the entire platform - a customized OpenSearch Dashboards distribution with purpose-built security modules for every Wazuh capability.
Built-in Modules:
| Module | What It Shows |
|---|---|
| Overview | Real-time alert stream, severity breakdown, top agents, top rules fired |
| Security Events | Searchable, filterable full alert explorer with KQL query support |
| Integrity Monitoring | FIM events by host, file change timelines, permission drift tracking |
| Vulnerability Detection | CVE inventory by host, CVSS score distribution, patch prioritization view |
| Configuration Assessment | SCA pass/fail by policy and host, compliance score trending |
| MITRE ATT&CK | Heatmap of detected TTPs, technique drill-down to contributing alerts |
| Threat Hunting | OpenSearch Dashboards Discover for ad-hoc investigation |
| Regulatory Compliance | PCI DSS, HIPAA, GDPR, NIST 800-53, TSC dashboards |
| Cloud Security | AWS/Azure/GCP/Office365 event explorer |
| Agent Management | Agent enrollment, group configuration, status monitoring |
Dashboard Configuration (wazuh.yml):
hosts:
- default:
url: https://wazuh-indexer-1
port: 9200
username: kibanaserver
password: kibanaserver_password
# API connection to Wazuh Manager
wazuh:
api:
selector: true
host: https://wazuh-server-1
port: 55000
username: wazuh-wui
password: wazuh-wui-password
run_as: false
Multi-Node Production Architecture Blueprint
This is the reference architecture for a production Wazuh deployment capable of handling 5,000-15,000 agents with high availability across all components.
┌──────────────────────────────────────────┐
│ MONITORED ENDPOINTS │
│ Windows Servers / Linux / macOS / Cloud │
└──────────────┬───────────────────────────┘
│ TLS 1514/TCP
▼
┌──────────────────────────────┐
│ LOAD BALANCER (HAProxy) │
│ (agent traffic) │
└──────┬───────────────┬────────┘
│ │
┌───────────▼──┐ ┌──────▼───────────┐
│ Wazuh │ │ Wazuh │
│ Server 1 │ │ Server 2 │
│ (Master) │ ◄──► │ (Worker) │
└───────────────┘ └──────────────────┘
│ Filebeat TLS 9200 │
└──────────────┬────────────────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
┌────────▼──────┐ ┌───────────▼────┐ ┌────────────▼───┐
│ Wazuh │ │ Wazuh │ │ Wazuh │
│ Indexer 1 │◄──► Indexer 2 │◄──► Indexer 3 │
│ (Master) │ │ (Data) │ │ (Data) │
└───────────────┘ └────────────────┘ └────────────────┘
│
┌────────▼──────┐
│ Wazuh │
│ Dashboard │
│ (HTTPS 443) │
└───────────────┘
Why 3 Indexer Nodes Minimum: With 3 nodes and 1 replica shard per index, the cluster can suffer the loss of any single node without losing data access or write capability. The cluster maintains quorum (2 of 3 master-eligible nodes remain) and continues operating normally until the failed node is restored or replaced.
Deployment Guide: Step-by-Step Multi-Node Install
Step 1: Generate SSL/TLS Certificates
This is the most critical pre-deployment step. All Wazuh component communication is TLS-encrypted, and certificates must be distributed correctly.
# Download the certificate generation tool
curl -sO https://packages.wazuh.com/4.7/wazuh-certs-tool.sh
curl -sO https://packages.wazuh.com/4.7/config.yml
# Edit config.yml to define your node IPs
cat > config.yml << 'EOF'
nodes:
indexer:
- name: wazuh-indexer-1
ip: 192.168.1.10
- name: wazuh-indexer-2
ip: 192.168.1.11
- name: wazuh-indexer-3
ip: 192.168.1.12
server:
- name: wazuh-server-1
ip: 192.168.1.20
node_type: master
- name: wazuh-server-2
ip: 192.168.1.21
node_type: worker
dashboard:
- name: wazuh-dashboard
ip: 192.168.1.30
EOF
# Generate all certificates
bash ./wazuh-certs-tool.sh -A
# This creates wazuh-certificates.tar with certs for all nodes
ls ./wazuh-certificates/
Step 2: Install and Configure Wazuh Indexer Cluster (All 3 Nodes)
# On each Indexer node (repeat with appropriate node name)
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor | \
sudo tee /usr/share/keyrings/wazuh.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
https://packages.wazuh.com/4.x/apt/ stable main" | \
sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt-get update && sudo apt-get install -y wazuh-indexer
# Deploy this node's certificates
NODE_NAME="wazuh-indexer-1" # Change per node
tar -xf wazuh-certificates.tar -C /etc/wazuh-indexer/certs/ \
./${NODE_NAME}.pem ./${NODE_NAME}-key.pem ./admin.pem \
./admin-key.pem ./root-ca.pem
# Set permissions
chmod 500 /etc/wazuh-indexer/certs
chmod 400 /etc/wazuh-indexer/certs/*
chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs
# Start and initialize
sudo systemctl enable --now wazuh-indexer
# After ALL 3 nodes are running, initialize the cluster (run once from node 1)
/usr/share/wazuh-indexer/bin/indexer-security-init.sh
Step 3: Install Wazuh Server Cluster
# On Wazuh Server 1 (Master)
sudo apt-get install -y wazuh-manager
# Configure cluster in /var/ossec/etc/ossec.conf
cat >> /var/ossec/etc/ossec.conf << 'EOF'
<cluster>
<name>wazuh</name>
<node_name>wazuh-server-1</node_name>
<node_type>master</node_type>
<key>c98b62a9b0169f24c0aef266747f7f2f</key> <!-- 32-char random string -->
<port>1516</port>
<bind_addr>0.0.0.0</bind_addr>
<nodes>
<node>192.168.1.20</node>
<node>192.168.1.21</node>
</nodes>
<hidden>no</hidden>
<disabled>no</disabled>
</cluster>
EOF
# Install and configure Filebeat to forward alerts to Indexer
sudo apt-get install -y filebeat
curl -so /etc/filebeat/filebeat.yml \
https://packages.wazuh.com/4.7/tpl/wazuh/filebeat/filebeat.yml
# Configure Indexer output in filebeat.yml
sed -i 's/YOUR_ELASTIC_SERVER_IP/192.168.1.10,192.168.1.11,192.168.1.12/' \
/etc/filebeat/filebeat.yml
sudo systemctl enable --now wazuh-manager filebeat
Step 4: Install Wazuh Dashboard
sudo apt-get install -y wazuh-dashboard
# Configure /etc/wazuh-dashboard/wazuh.yml
cat > /etc/wazuh-dashboard/wazuh.yml << 'EOF'
hosts:
- default:
url: https://192.168.1.10
port: 9200
username: kibanaserver
password: kibanaserver_password
EOF
# Configure /etc/wazuh-dashboard/opensearch_dashboards.yml
cat >> /etc/wazuh-dashboard/opensearch_dashboards.yml << 'EOF'
server.host: 192.168.1.30
server.port: 443
opensearch.hosts: ["https://192.168.1.10:9200"]
opensearch.ssl.verificationMode: certificate
EOF
sudo systemctl enable --now wazuh-dashboard
Step 5: Deploy Agents at Scale
# Linux agent deployment (one-liner for automation)
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor | \
sudo tee /usr/share/keyrings/wazuh.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
https://packages.wazuh.com/4.x/apt/ stable main" | \
sudo tee /etc/apt/sources.list.d/wazuh.list
WAZUH_MANAGER="192.168.1.20" WAZUH_AGENT_GROUP="linux-servers" \
sudo apt-get install -y wazuh-agent
sudo systemctl enable --now wazuh-agent
# Windows agent deployment via PowerShell (for GPO/SCCM automation)
Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.5-1.msi" `
-OutFile "wazuh-agent.msi"
msiexec /i wazuh-agent.msi WAZUH_MANAGER="192.168.1.20" `
WAZUH_AGENT_GROUP="windows-workstations" /qn /norestart
NET START WazuhSvc
Capability Deep Dive: File Integrity Monitoring
FIM is one of Wazuh’s most operationally valuable capabilities - and one of the most frequently misunderstood. It does not just alert on file changes. It stores the full diff of what changed, when it changed, under which process, and by which user.
Configuration Example - Protecting Web Server Root
<!-- In /var/ossec/etc/ossec.conf or agent group shared.conf -->
<syscheck>
<!-- Real-time monitoring of web root -->
<directories realtime="yes" report_changes="yes" check_all="yes">
/var/www/html
</directories>
<!-- Scheduled monitoring of system binaries (no realtime needed - audit is better) -->
<directories check_all="yes" check_sum="yes">
/usr/bin,/usr/sbin,/bin,/sbin
</directories>
<!-- Monitor Windows registry for persistence mechanisms -->
<windows_registry check_all="yes">
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
</windows_registry>
<!-- Ignore noisy paths -->
<ignore>/var/www/html/cache</ignore>
<ignore type="sregex">\.log$</ignore>
<!-- Alert on these regardless of ignore rules -->
<nodiff>
/var/www/html/.htaccess
/etc/passwd
/etc/shadow
</nodiff>
<scan_time>02:00</scan_time>
<scan_day>saturday</scan_day>
</syscheck>
What a FIM Alert Looks Like in TheHive/Dashboard:
- Timestamp, agent, file path
- Event type: added / modified / deleted
- Previous checksum (MD5, SHA1, SHA256)
- New checksum
- Diff of file content (for text files)
- File owner/permissions before and after
- Process that made the change (via auditd integration)
Capability Deep Dive: Active Response
Active Response is Wazuh’s built-in automated containment mechanism. When a rule triggers at a defined severity level, the Server can instruct the relevant agent to execute a predefined response action within milliseconds.
Built-in Responders
| Responder | Action | Platforms |
|---|---|---|
firewall-drop | Add iptables/Windows Firewall rule to block srcip | Linux, Windows |
disable-account | Lock user account via passwd or net user | Linux, Windows |
kill-process | Terminate a suspicious process by PID | Linux, Windows |
host-deny | Add entry to /etc/hosts.deny | Linux |
route-null | Null-route a source IP | Linux |
restart-wazuh | Restart the agent (useful for config refresh) | All |
Custom Active Response Example - Block SSH Brute Force
<!-- Define the command -->
<command>
<name>firewall-drop-ssh-brute</name>
<executable>firewall-drop.sh</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<!-- Link command to rule trigger -->
<active-response>
<command>firewall-drop-ssh-brute</command>
<location>local</location> <!-- Execute on the agent being attacked -->
<rules_id>5763</rules_id> <!-- Wazuh rule: SSH auth failure x10 -->
<timeout>3600</timeout> <!-- Auto-unblock after 1 hour -->
<repeated_offenders>30,60,120</repeated_offenders> <!-- Escalating timeouts -->
</active-response>
Compliance Coverage: Built-in Regulatory Frameworks
This is where Wazuh delivers enormous value in regulated industries. Every compliance framework ships with pre-mapped rules and purpose-built dashboards that can be presented to auditors.
| Framework | Coverage |
|---|---|
| PCI DSS v4.0 | Requirements 1-12 mapped to Wazuh rules; FIM covers req. 10 and 11; SCA covers req. 2, 6, 7 |
| HIPAA | Administrative, physical, and technical safeguards; audit logging; PHI access monitoring |
| GDPR | Data access tracking, breach detection, integrity verification |
| NIST 800-53 | Controls across Identify, Protect, Detect, Respond, and Recover |
| TSC (SOC 2) | Security, availability, confidentiality, and processing integrity controls |
| CMMC Level 2 | Access control, audit log, incident response, configuration management |
PCI DSS Requirement 10 in Practice
PCI DSS Requirement 10 mandates logging and monitoring of all access to system components and cardholder data. Wazuh addresses this directly:
<!-- Enable audit logging for all root commands (PCI DSS 10.2.2) -->
<localfile>
<log_format>audit</log_format>
<location>/var/log/audit/audit.log</location>
</localfile>
<!-- Monitor all access to the cardholder data directory (PCI DSS 10.2.1) -->
<syscheck>
<directories realtime="yes" check_all="yes" report_changes="yes"
whodata="yes">
/var/data/cardholder
</directories>
</syscheck>
The Dashboard’s PCI DSS module then provides a requirements matrix with pass/fail status for each sub-requirement, generating audit-ready evidence with a single export.
TCO Analysis: Wazuh vs. Commercial SIEM Platforms
Licensing Cost Comparison (5,000 Endpoints, 3-Year Horizon)
| Platform | Year 1 | Year 2 | Year 3 | 3-Year Total |
|---|---|---|---|---|
| Wazuh (open-source) | $0 | $0 | $0 | $0 |
| Splunk Enterprise Security | $240,000 | $240,000 | $240,000 | $720,000 |
| IBM QRadar | $180,000 | $180,000 | $180,000 | $540,000 |
| Microsoft Sentinel | $85,000 | $95,000 | $105,000 | $285,000 |
| Elastic SIEM (Enterprise) | $65,000 | $65,000 | $65,000 | $195,000 |
Licensing costs only. Infrastructure and labor not included.
Full TCO Model (Wazuh Multi-Node Production)
| Cost Category | Year 1 | Years 2-3 (per year) |
|---|---|---|
| Licensing | $0 | $0 |
| Infrastructure (3 Indexer + 2 Server + 1 Dashboard nodes) | $18,000 | $6,000 (maintenance) |
| Initial deployment engineering (one-time) | $15,000-25,000 | - |
| Ongoing operations (0.5 FTE SecOps/Linux Admin) | $40,000-60,000 | $40,000-60,000 |
| Wazuh Commercial Support (optional) | $12,000 | $12,000 |
| Total Year 1 | $85,000-$115,000 | - |
| Total Years 2-3 (avg) | - | $58,000-$78,000 |
| 3-Year Total | $200,000-$270,000 |
Even with full infrastructure, initial deployment engineering, ongoing operational headcount, and optional commercial support, Wazuh delivers a 3-year TCO that is 60-70% lower than Splunk and 30-40% lower than Microsoft Sentinel - for equivalent security coverage.
Real-World Case Study: Healthcare Provider SOC Transformation
The Scenario
A 2,800-employee regional healthcare provider (3 hospitals, 12 outpatient clinics) was facing a HIPAA audit finding: their log collection and integrity monitoring capabilities were insufficient. They were using a commercial SIEM that cost $160,000/year in licensing, but it covered only 400 of their 1,800 endpoints due to cost constraints on the per-endpoint licensing model.
The Problem
| Metric | Commercial SIEM (Before) |
|---|---|
| Endpoints covered | 400 of 1,800 (22%) |
| Annual licensing cost | $160,000 |
| FIM coverage | 0 hosts (add-on not licensed) |
| Compliance dashboard | Partial HIPAA only |
| MITRE ATT&CK mapping | Not available |
| Cloud monitoring (Azure AD, Office 365) | Not included |
The Migration to Wazuh
The team deployed a 5-node Wazuh multi-node cluster:
- 3 Indexer nodes (8 cores / 16 GB RAM / 4 TB SSD each)
- 2 Server nodes (8 cores / 16 GB RAM each) behind HAProxy
- 1 Dashboard node (4 cores / 8 GB RAM) with Nginx reverse proxy
90-day migration timeline:
- Days 1-14: Infrastructure deployment, certificate generation, cluster initialization
- Days 15-30: Agent rollout to all 1,800 endpoints via SCCM (Windows) and Ansible (Linux/RHEL)
- Days 31-60: Rule tuning, custom decoder authoring for Epic EHR and Meditech logs, HIPAA dashboard validation
- Days 61-90: Active Response configuration, FIM policy deployment, compliance baseline generation
The Results
| Metric | Before (Commercial) | After (Wazuh) | Change |
|---|---|---|---|
| Endpoints covered | 400 (22%) | 1,800 (100%) | +350% |
| Annual licensing cost | $160,000 | $0 | -100% |
| FIM coverage | 0 hosts | 1,800 hosts | New capability |
| HIPAA dashboard | Partial | Full (12 controls) | Complete |
| MITRE ATT&CK visibility | None | Full TTP mapping | New capability |
| Azure AD / O365 monitoring | Not included | Full coverage | New capability |
| CVSS vulnerability visibility | Not included | All hosts | New capability |
| Infrastructure cost (annual) | Included in licensing | $18,000 | - |
| Alert-to-triage time (avg) | 47 minutes | 12 minutes | -75% (via Shuffle integration) |
The $160,000 in annual licensing savings was redistributed: $40,000 to a dedicated Wazuh operations engineer, $18,000 to infrastructure, and $102,000 to fund a dedicated purple team exercise program. The HIPAA audit finding was remediated in the 90-day window with documented evidence from Wazuh’s compliance dashboards.
Integration Ecosystem: Wazuh as the SOC Foundation
Wazuh is most powerful when integrated as the telemetry foundation of a broader open-source SOC stack.
Wazuh + TheHive + Cortex + Shuffle
This is the complete, production-grade open-source SOC architecture:
[Wazuh Agents] ──► [Wazuh Server] ──► [Wazuh Indexer]
│
[Alert Webhook]
│
▼
[Shuffle SOAR]
│
┌───────────────┼──────────────────┐
▼ ▼ ▼
[Cortex: [TheHive: [Slack/Teams:
Enrich IOCs] Create Case] Notify SOC]
│ │
└───────────────┘
Pre-triaged
Case with full
intelligence
Wazuh + MISP (Threat Intelligence)
<!-- Custom integration to pull MISP IoCs into Wazuh CDB lists -->
<integration>
<name>misp</name>
<hook_url>http://misp-server/api/attributes/restSearch</hook_url>
<api_key>YOUR_MISP_API_KEY</api_key>
<alert_format>json</alert_format>
</integration>
Wazuh + Velociraptor (Digital Forensics)
For active incident response investigations, Wazuh’s active response can trigger Velociraptor artifact collection on compromised endpoints - enabling immediate forensic triage from the same alert that detected the threat.
Security Hardening: Production Best Practices
1. Harden the API
# Change default API credentials immediately
curl -k -X PUT "https://localhost:55000/security/users/1" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"password": "YourStrongPassword123!"}'
# Restrict API access to Dashboard IP only (firewall rule)
ufw allow from 192.168.1.30 to any port 55000
ufw deny 55000
2. Agent Authentication with Keys
# Pre-generate agent keys for unattended enrollment
/var/ossec/bin/manage_agents -a # Add agent, generates unique AUTH key
/var/ossec/bin/manage_agents -e # Export key for distribution
# Enforce agent key authentication (blocks any unauthorized agent)
# In ossec.conf:
# <auth><use_source_ip>yes</use_source_ip></auth>
3. Index Template for Data Retention
# Set 90-day index lifecycle policy via API
curl -k -X PUT "https://localhost:9200/_plugins/_ism/policies/wazuh-alerts-policy" \
-H "Content-Type: application/json" \
-u admin:admin -d '{
"policy": {
"phases": {
"hot": { "min_index_age": "1d" },
"delete": {
"min_index_age": "90d",
"actions": { "delete": {} }
}
}
}
}'
Who Should Deploy Wazuh Multi-Node?
Ideal Candidates
| Organization Profile | Why Wazuh Wins |
|---|---|
| MSSPs and MDR providers | Unlimited agents, no per-endpoint licensing - the economics are unbeatable for multi-tenant environments |
| Healthcare and financial services | Native HIPAA/PCI DSS dashboards with audit-ready evidence exports |
| Government and defense contractors | Full data sovereignty, CMMC and NIST 800-53 mapping, no vendor telemetry |
| High-growth startups | Scales from 50 to 10,000 agents without licensing renegotiation |
| Organizations on Linux/OpenSearch stack | Native technology alignment - no learning curve on the underlying infrastructure |
When to Choose a Commercial Alternative
| Scenario | Better Alternative |
|---|---|
| Zero Linux/DevOps expertise in-house | Microsoft Sentinel (cloud-native, minimal infra ops) |
| Need instant deployment with pre-built detection content | Splunk Enterprise Security (massive content ecosystem) |
| Fully Microsoft 365 + Azure environment | Microsoft Sentinel (native integration depth unmatched) |
| Require guaranteed SLA and TAC support | IBM QRadar or Elastic with paid support tier |
The Bottom Line
Wazuh has earned its position as the world’s most widely deployed open-source SIEM through a simple proposition: production-grade security visibility at zero licensing cost, without compromising on capability.
The platform covers every detection and monitoring use case that regulated enterprises require - FIM, SCA, vulnerability detection, MITRE ATT&CK mapping, compliance reporting, cloud security monitoring, and active response - in a single, cohesive agent and backend architecture.
The operational investment is real. You need Linux expertise, OpenSearch familiarity, and the engineering bandwidth to tune rules and manage infrastructure. But for organizations that have those capabilities - or are willing to build them - the ROI calculation is straightforward.
A 5,000-endpoint Wazuh deployment costs roughly $200,000-$270,000 over three years. The equivalent commercial SIEM costs $500,000-$720,000 over the same period. The difference funds a full-time threat hunter, a red team exercise program, and the SOAR automation stack described in our companion article.
The money you save on licensing is the money you invest in the human expertise that actually wins the fight.
Resources & Further Reading
| Resource | Description |
|---|---|
| Official Wazuh Documentation | Deployment guides, API reference, rule authoring |
| Wazuh GitHub | Source code, issue tracker, community contributions |
| Wazuh Community Slack | 620,000+ member community for troubleshooting |
| Wazuh Blog | Integration tutorials, detection engineering, use case guides |
| Wazuh + TheHive Integration | Official guide to connecting Wazuh alerts to TheHive cases |
| Wazuh + Shuffle SOAR | Community SOAR playbook templates for Wazuh + Shuffle |
| CIS Benchmarks | Hardening guides used by Wazuh SCA policies |
| MITRE ATT&CK | Adversary tactic and technique reference |
