Wazuh-SIEM-Lab: The Repo That Turns a SIEM Into a Detection Engine

A two-node lab that starts with default alerts and ends with tuned rules, real-time file integrity monitoring, and the log-forensics mistakes every security engineer eventually has to make.

6 to 8 min read • View on GitHub • More from nileshmethri

A home lab control room with a calm SIEM dashboard on one side and a spill of raw log lines on the other. The scene explains the repo’s core idea: a dashboard can be running and still not be useful until someone interrogates the evidence underneath it. — A SIEM only becomes valuable when the raw evidence is treated as the real interface.

Key Takeaways

This repo is really about the moment a SIEM stops being a dashboard and starts being a discipline of reading logs, baselines, and rule behavior carefully.
Its most useful lesson is that default detections are often technically correct and operationally wrong, so tuning has to follow intent, not just event type.
The lab makes state visible by showing how real-time FIM, baseline timing, and raw log fields change whether an event is noisy, invisible, or high-fidelity.
Compared with broader lab stacks, it wins by staying small enough to teach one hard thing well: how to turn generic Wazuh output into meaningful detections.

The lab works before it is useful. That is the whole story here. nileshmethri/wazuh-siem-lab does what many security demos do: it brings up a working Wazuh environment. Then it goes one step further and asks the harder question, which is whether the alerts actually mean anything.

Wazuh SIEM lab to setup and test wazuh in docker environment.

wazuh-siem-lab (Repository Description), Project Description · nileshmethri/wazuh-siem-lab

Why this repo exists

The README frames the project as a quick way to set up a Wazuh SIEM lab environment with Docker Compose. That sounds simple, but the real value is more specific: it gives a reproducible place to practice security monitoring without fighting a full enterprise rollout.

That makes this less like a product demo and more like a training ground. The lab is small on purpose. It is built for people who want to see how alerts, baselines, and package risk behave when you start changing the rules on purpose.

The real lesson: SIEMs break quietly

The article’s sharpest insight is the silent failure pattern. A file created before the first baseline scan can disappear into known good. A command a human typed as sudo su may land in the logs as /usr/bin/su. In both cases, the system is functioning, but the detection logic is wrong.

The same host event can disappear, noise up the dashboard, or become a useful alert depending on timing, parsing, and rule choice.

Situation	What happens	Why it matters
File created before the first baseline scan	It becomes part of known good	The system sees state, not history, so timing determines visibility
File created after real-time FIM is enabled	It triggers immediately	State changes become events instead of waiting for the next sweep
Typed command looks like sudo su	The log records /usr/bin/su in full_log	Rules have to match what the system stored, not what the operator typed
Installed package has known CVEs	Vulnerability feed turns it into risk	Version data becomes actionable instead of sitting as inventory

From noise to signal

The custom rule work is the strongest evidence that this repo is about detection engineering, not mere deployment. The default sudo rule is broad and noisy. The tuned rule lifts the signal by targeting intent, then validating that intent against the raw event fields instead of assuming the shell command text will match cleanly.

<rule id="100002" level="10">
  <if_sid>5402</if_sid>
  <match>sudo su</match>
  <description>Privilege escalation via su</description>
</rule>

<!-- The lesson is not the regex itself. It is that full_log may show /usr/bin/su, not the literal command the user typed. -->

That matters because a SIEM is not supposed to reward volume. It is supposed to reward meaning. A high-priority alert should reflect a security-relevant decision, not just a generic administrative action.

A close-up ledger for filesystem integrity monitoring. One set of files is stamped as already known, while a newer file is marked as newly observed. In the background, a small terminal scene shows a command being translated into a different logged form, emphasizing the timing and representation problems behind detection. — When the baseline comes first, new events stay visible. When it comes too late, they blend into the background.

Why real-time FIM changes the game

The shift from scheduled scans to realtime="yes" is the clearest operational upgrade in the repo. Scheduled FIM is useful, but it is delayed by definition. Real-time FIM changes the experience from eventually noticing to catching the change as it happens.

That is the difference between a lab that proves a feature exists and a lab that teaches how detection actually behaves under pressure. The repo makes that gap visible instead of abstract.

The CVE feed turns packages into risk

The vulnerability management piece is simpler, but it rounds out the lab. Enabling the Canonical feed for Ubuntu Jammy turns installed package versions into a live risk inventory. That is important because it shows how SIEM data becomes actionable when it is tied to a known vulnerability source.

Layer	Without the feed	With the feed
Packages	Just installed software	Software plus exposure context
Visibility	Version numbers in a list	Version numbers mapped to CVEs
SOC value	Inventory	Prioritized risk

The point is not the number of CVEs. The point is the translation. A version string stops being bookkeeping and starts becoming a decision signal.

Why this beats just using the official docs

Compared with the official Wazuh Docker setup, this repo is less generic and more opinionated. Compared with broader frameworks like DetectionLab or Security Onion, it is smaller, lighter, and easier to use for one thing: learning how Wazuh behaves when you tune it for real incidents instead of happy-path demos.

Project	What it is	Strength	Trade-off	Best for
wazuh-siem-lab	A focused Docker-based Wazuh lab	Fast path to practical tuning	Narrow scope	Learning Wazuh detections
Official Wazuh Docker	The upstream deployment baseline	Authoritative and minimal	Requires more interpretation	Starting from first principles
DetectionLab	A full multi-VM security lab	Breadth and realism	Heavy setup cost	Broad blue-team practice
Security Onion	A full security monitoring platform	Integrated stack depth	More platform than lab	Enterprise-style threat hunting

This repo wins on friction and clarity, not scale. That is exactly why it is interesting. It teaches a narrower but more transferable lesson: a security stack becomes useful only after someone learns what its defaults miss.

What this project teaches beyond Wazuh

The transferable lesson is bigger than this repo. Every monitoring system has the same blind spots. Baselines can hide real events. Default rules can be too broad. Raw logs matter more than the pretty label on the dashboard.

That is the real value of Wazuh-SIEM-Lab. It shows the moment a SIEM stops being a dashboard and starts being a discipline.