Wazuh

Wazuh is an open-source security monitoring platform, forked from OSSEC and extended into something closer to a SIEM. It collects events from agents and network sources, normalises them, matches them against rules, and raises alerts. For a small organisation or a lab, it is the realistic way to have detection at all.

The pieces

Agents      on each monitored host: log collection, FIM, rootkit checks, inventory
   |
Manager     decoders normalise events, rules match them, alerts are raised
   |
Indexer     stores and indexes alerts (OpenSearch)
   |
Dashboard   query, visualise, investigate

Agents exist for Linux, Windows and macOS. Anything without an agent (a firewall, a switch, an embedded device) sends syslog to the manager instead, which is the mode that matters for embedded and OT work.

What it does

Log analysis. The core function. Decoders parse a raw line into fields, rules match those fields and assign a severity level from 0 to 15.
File integrity monitoring. Watch chosen paths and alert on change, with the before-and-after diff. /etc, web roots, and binary directories are the usual targets.
Rootkit and anomaly detection, on agent hosts.
Configuration assessment. Policy checks against CIS-style benchmarks.
Vulnerability detection, by correlating collected package inventories against CVE feeds.
Active response. Run a command on an alert, for example blocking an address. Powerful and worth treating carefully, since a false positive now has an effect.

Decoders and rules

This is where the actual work is, and where a deployment succeeds or fails.

A decoder turns a log line into named fields. A rule matches fields and assigns a level; rules can require a frequency and a timeframe, so "five failures from one source in 120 seconds" is expressible directly, and can inherit from a parent rule so you refine rather than duplicate.

<rule id="100200" level="10">
  <if_sid>1002</if_sid>
  <match>unauthorized publish</match>
  <description>MQTT broker rejected a publish from an unauthorised client</description>
</rule>

Custom rule ids start at 100000; the built-in ranges belong to Wazuh and get overwritten on upgrade.

Why it fits embedded and OT

The devices cannot run an agent. They have no spare memory, no package manager, and often no way to install anything at all. What they can usually do is emit syslog, and what sits in front of them can emit a great deal more:

an MQTT broker's authentication and authorisation failures;
a reverse proxy's access log in front of a device web UI;
switch and firewall logs, which is where the segmentation described in purdue-model is either confirmed or refuted;
an IDS on a span port watching the traffic the devices generate.

That indirect collection is frequently the only telemetry a device fleet produces, which makes centralising it the single highest-value detection investment for this class of system, and directly supports the evidence problem described in incident-response.

Pitfalls

Default rules generate noise. An untuned deployment produces thousands of low-level alerts and trains everyone to ignore it. Tuning is the deployment, not an afterthought.
Alerting on everything is the same as alerting on nothing. Decide the handful of things that must page a human before switching anything on.
Log volume is the cost driver. Indexer storage grows faster than expected; set retention deliberately.
Agents need to be maintained. An agent that stopped reporting three weeks ago is a blind spot that looks like quiet.
Active response can cause the outage. On an OT network especially, an automatic block is a decision to stop traffic that something physical may depend on.

What it pairs with

incident-response is the process it feeds, ot-security and purdue-model explain the constraints on where you can collect, and wireshark is what you reach for once an alert needs the packets behind it.