Wazuh SIEM: one place to see what happened

Context

Security signals were scattered between the Kubernetes clusters, a handful of infrastructure VMs and the cloud provider account. Nothing correlated them, and nobody could answer “what happened last night?” from one screen.

What I built

• Architecture first: manager, indexer and dashboard on a dedicated VM, deployed with Terraform, with the log flows designed before anything was installed.
• Agents as code: the Wazuh agent packaged as a Helm chart and rolled out on every Kubernetes node through ArgoCD, with automated enrollment. Agent upgrades follow the same release channels as the rest of the platform.
• SSO: dashboard and indexer behind the internal identity provider (OIDC), the application declared in Terraform and roles mapped from the provider. No local accounts.
• Detection content: correlation of Falco alerts, SSH brute force, privilege escalation, suspicious root access; vulnerability detection, malware detection and threat-intelligence feeds.
• Cloud sources: the cloud account’s API logs and the managed databases’ logs ingested with custom decoders and rules.
• Alerting: Slack notifications through the bot API, aligned with the existing Alertmanager setup.

Taming the noise

A SIEM nobody reads is worse than no SIEM. One cloud-account rule fired about 474,000 times a day. I traced it to an API key polling node pools once per second, then re-tiered the rule set:

• HTTP errors and IAM refusals evaluated first, and raised;
• successful reads silenced;
• mutating calls (POST, PUT, DELETE, PATCH) kept at a visible level;
• rule order fixed for Wazuh’s first-match logic between sibling rules.

The same approach removed repeated alerts from system timers and from the managed databases’ internal health checks.

Outcome

One place to look across clusters, VMs and the cloud account, with alerts that are worth reading. Incident-response runbooks and security dashboards are the next step.