Wazuh as a small team's SIEM: what it does well and where it hurts

Almost every compliance framework expects you to collect logs, keep them, and detect things in them. The commercial answer costs per gigabyte ingested, which for a mid-sized cloud estate becomes the largest line in the security budget surprisingly quickly.

Wazuh is the open-source answer most small teams end up trying. It is a fork of OSSEC with an Elasticsearch-family backend, an agent for endpoints and servers, and a rule engine with several thousand rules shipped. It is genuinely capable. It is also a distributed system you now operate.

What you get without building anything

The agent does more than ship logs, and this is the part that makes Wazuh worth considering over a plain log stack:

• File integrity monitoring on paths you specify, with a report of what changed, when and by which process. This is a control that PCI DSS and ENS name explicitly and that is tedious to build otherwise.
• Configuration assessment against CIS benchmarks, per host, re-run on a schedule, with pass/fail per check. Useful on its own, and it produces evidence in the shape auditors expect.
• Vulnerability detection by correlating the host's installed package inventory against CVE feeds — no scanning traffic, no credentials, just the agent's own view.
• Log collection and decoding for the usual suspects: sshd, sudo, auditd, Windows event logs, web servers, and a decoder format for anything else.
• Active response, which can run a script on the agent when a rule fires. Use this sparingly; an automatic firewall block triggered by a spoofable log line is its own denial of service.

Out of the box, on a fleet of Linux servers, this gives you brute-force detection, privilege escalation detection, file change alerts and a CIS score within an afternoon.

The cloud integrations are the reason it fits a cloud estate

Wazuh ingests CloudTrail, GuardDuty, VPC flow logs, Google Cloud audit logs and Entra ID sign-in logs through its own modules. That means the cloud control plane and the hosts land in one place with one rule language, which is the main thing you want from a SIEM and the main thing a collection of per-provider consoles does not give you.

The default cloud rules are thin, though. The rules that catch real cloud attacks — a role assumed from an unusual country, a new access key created for an identity that has never had one, GetSecretValue from a principal that has never called it, CloudTrail being disabled — you write yourself. Budget for that; it is where the detection value actually is.

Where it hurts

The indexer is the operational cost. Wazuh's storage is an Elasticsearch/OpenSearch cluster, and you are now running an Elasticsearch cluster. Shard sizing, index lifecycle policies, disk pressure, heap tuning, version upgrades that require ordered restarts. If nobody on the team has operated one before, this is the part that fails at 2 a.m., and the failure mode is that you stop collecting logs and nobody notices for three weeks.

Set up a monitor that alerts when agents stop reporting. It is the single most important piece of configuration and it is not there by default.

Rule tuning is continuous. The shipped ruleset alerts on things that are normal in your environment. Every untuned rule trains the team to ignore the alert channel, and that habit is very hard to reverse. Budget an hour a week, indefinitely.

Upgrades are real work. Agent and manager versions are coupled, the indexer has its own compatibility matrix, and upgrading a fleet of agents is a change window.

Retention costs money anyway. You saved the licence, not the disk. A year of retention for audit purposes is a real storage bill, and moving old indices to cheaper storage is another thing to configure.

When to stop and buy

Be honest about the arithmetic. Wazuh costs roughly half an engineer, continuously, once you count operating the indexer, tuning rules and handling upgrades. If your commercial SIEM quote is below that, buy it.

It is the right choice when: you have a small, homogeneous estate; somebody on the team genuinely enjoys operating this kind of system; you need file integrity monitoring and configuration assessment as much as you need correlation; or data residency requirements make a hosted service awkward.

It is the wrong choice when: nobody owns it, the volume is large enough that indexer operation becomes a specialism, or the actual requirement is an auditor's checkbox — in which case a smaller, well-scoped managed service costs less than the engineer you will spend.

The deciding question is not what it costs to install. It is who is going to read the alerts on a Tuesday in eight months, and whether the thing will still be collecting logs by then.