Wazuh and log management

What Wazuh is

Wazuh is a fork of OSSEC, started in 2015, now developed by a company of the same name. It kept the OSSEC architecture, a manager receiving events from agents and applying decoders and rules, and built substantially on top: a REST API, a much larger rule set, vulnerability detection, security configuration assessment, MITRE ATT&CK mapping, cloud service integrations, and a web interface people use.

Some context on where we are standing. Trunc was founded by the author of OSSEC, so Wazuh and Trunc share an ancestor several generations back. We think Wazuh is a good product and this page is not an argument against running it. It is an argument about which part of the problem you want to own.

The three components

A Wazuh deployment is three separate services, and the naming obscures what two of them are.

If you have read our page on the ELK Stack, the second and third rows will look familiar. Running Wazuh means running a search cluster, whether or not you think of it that way, and the operational characteristics are those of Elasticsearch because that is what it is.

What Wazuh does with logs

Agents collect from files, Windows event channels, journald, command output and various cloud APIs, and forward to the manager. The manager decodes and applies rules, and matching events become alerts written into the indexer.

The important detail is the same one that applies to OSSEC: by default, only alerts are stored. An event that matches no rule is evaluated and dropped. Wazuh has an archives option that keeps everything, written to archives.json and optionally indexed, and this is where the cost question starts.

Indexing all archives rather than just alerts multiplies your ingest volume by a large factor, because the ratio of routine events to alertable ones is heavily weighted towards routine. That means more indexer nodes, more disk, more shards to manage, and a retention policy that has to reconcile "keep twelve months for the auditor" with "keep the cluster healthy". Many deployments compromise by enabling archives to disk without indexing them, which gets you compliance storage that nobody can search, which is roughly where OSSEC's logall left off.

What Wazuh adds over OSSEC

• A working interface. The single largest practical difference. Alerts are searchable, filterable and charted without building anything.
• A much larger rule set, with MITRE ATT&CK technique mapping, which makes coverage conversations easier.
• Vulnerability detection. Agents report installed packages and the manager correlates against CVE feeds. This answers "which of my hosts is affected" the week a CVE lands, and it is one of the most used features.
• Security configuration assessment. Policy checks against CIS benchmarks and similar baselines.
• A REST API and agent management, which makes managing several hundred agents realistic rather than a scripting exercise.
• Cloud integrations for AWS, Azure, GCP, Office 365 and container platforms.

What it costs to run

The software is free. The operational load is the price, and it is mostly the indexer.

Heap sizing has the same trap as Elasticsearch: the JVM loses compressed object pointers somewhere around 32GB, so a node given more heap than that can address less usable memory than one given less. Shard sizing has the same characteristic as any Lucene based store, where a strategy that suits your current volume becomes a problem at ten times the volume, and the symptom is a cluster going yellow rather than an obvious error.

Version upgrades move three components that have to stay compatible with each other, and the indexer is the one that carries risk because it holds the data. Then there is the ordinary work of any cluster: capacity planning, disk growth, monitoring the thing that monitors everything else, and having somebody who understands it well enough to fix it when it breaks at an inconvenient hour.

None of that is a criticism of Wazuh. It is what running a search cluster involves, and Wazuh needs one because storing and searching security events at scale requires one. The question is whether operating it is work you want.

When Wazuh alone is the right answer

• Your data cannot leave the network. Wazuh runs entirely on your infrastructure and that settles it.
• Endpoint features are the point. If vulnerability detection and configuration assessment are why you deployed it, and log retention is a secondary concern, the indexer you are already running may be enough.
• You have the operational capacity. A team that already runs OpenSearch or Elasticsearch will find the indexer unremarkable.

The case for pairing them is narrower than it sounds. It comes down to whether the cluster underneath your security tooling is something you chose or something you inherited by choosing the tool above it.

Common questions

Can Trunc replace Wazuh entirely?

For log analysis, correlation and storage, yes. For file integrity monitoring, vulnerability detection and configuration assessment, no, because those are agent side capabilities Trunc does not have. Teams using Wazuh mainly as a log platform tend to find the swap straightforward. Teams using the endpoint features should keep it.

Will Trunc parse Wazuh alerts properly?

Yes. Alerts arrive with the rule ID, level, description, agent name and decoded fields intact, and Trunc categorizes them alongside everything else, so a Wazuh brute force alert lands in the same view as one derived from your firewall logs.

Does this mean running two agents?

On hosts where you want file integrity monitoring, yes, and they do not conflict. On hosts where you only want logs, the Trunc agent by itself is enough and you can leave Wazuh off entirely.

What about the Wazuh cloud offering?

Wazuh offers a hosted version, which removes the cluster operations problem in the same way Elastic Cloud does. Compare it on price at your ingest volume and on whether the interface suits how your team works, since both products are then solving the same shape of problem.