A year ago we rolled out Wazuh as the SIEM backbone across a mining operation — four pits, three processing areas, and a sprawl of legacy PLCs and Windows boxes that predate most of the team. Twelve months of alerts later, here is the honest ledger: what earned its keep, and what I ripped back out.

The environment fights you

Industrial sites are not data centers. Links between pit and head office are wireless and lossy, half the endpoints can't take an agent without a change-management fight, and "maintenance window" means a scheduled production stop that costs real money. Any monitoring design that assumes a clean, always-on LAN will drown in false positives on week one.

What stuck

  • File integrity monitoring on the servers that matter. Scoped tightly to config directories and binaries, FIM caught more real change — including unplanned "helpful" edits by vendors — than any fancy correlation rule.
  • Centralized log collection from the network edge. Piping FortiGate, Cisco, and Aruba logs into one place turned "why is the pit link flapping?" from an afternoon into a query.
  • A small set of high-signal detection rules. Failed-logon storms, new local admins, and disabled security services. Three rules that page someone beat three hundred that page no one.

What I ripped out

The vulnerability-detection module, at full breadth, was noise on this estate — it flagged CVEs on air-gapped, unpatchable OT boxes we already knew about and could not touch. I narrowed it to the reachable IT servers and let the OT side be governed by network segmentation instead.

On an OT-heavy site, segmentation is a stronger control than a longer alert list. Detection tells you the fence was crossed; the fence keeps most people out.

I also dialed back overly-chatty rules that fired on normal operational behavior. An alert that everyone learns to ignore is worse than no alert — it trains the team to swipe the pager away.

The real lesson

The SIEM was the easy part. The value came from the boring work around it: agreeing on what "normal" looks like per site, deciding who responds at 2 a.m., and writing the runbook so the response doesn't depend on the one engineer who understands the wireless topology. Tools detect; people respond. Budget for both.