Open-Source Security Monitoring, Lab-Validated
What we set out to prove
Before we tell a client we can monitor their systems, we want to have run the stack ourselves: watched it catch a real problem, not just read the vendor’s feature list. This is a write-up of that lab work, not a client engagement — see the qualifications at the bottom before drawing conclusions from it.
We built a small proof-of-concept stack combining two things a lot of managed-IT offerings treat as separate products:
- Wazuh, an open-source SIEM, for vulnerability (CVE) scanning, file integrity monitoring, and alerting.
- Prometheus and Grafana, for infrastructure metrics — CPU, disk, uptime — with threshold-based alerting.
Both are open source. Nothing in this stack is a black box we’d have to take a vendor’s word for.
The stack
A Wazuh manager, indexer, and dashboard; Prometheus and Grafana; a simulated Linux endpoint running the Wazuh agent and a metrics exporter; and a SQL Server instance with its own metrics exporter — reflecting the mixed Windows-and-database fleets our early clients actually run.
(Architecture diagram: TODO — add once final screenshots are captured from the running stack.)
Three things we demonstrated live
1. Vulnerability detection. Wazuh’s Syscollector module inventories installed software and cross-references it against known CVEs. On our test endpoint, this populated within about two minutes of the agent’s first check-in: 300+ known vulnerabilities, several rated Critical.
2. File integrity monitoring. We modified a monitored file on the test endpoint and watched the change appear as an event in the Wazuh dashboard within moments — the kind of detection that matters for catching unauthorized changes to sensitive files.
3. Resource-spike alerting. We simulated a CPU spike on the test endpoint and watched Grafana’s dashboard flag it and Prometheus’s alerting fire a threshold breach — proof that the alerting pipeline works end to end, not just that a dashboard exists.
What we learned running it
- CVE inventory (what’s already on a host) populates fast. A CVE alert for something newly introduced only fires on a detected change, by design — otherwise every agent would trigger an alert storm the moment it registers. Worth knowing the difference before you expect a live demo to alert on cue.
- A shared index holds vulnerability data for every agent in a deployment — you filter by agent, you don’t look for a separate index per host. An easy thing to get wrong the first time.
- Some services (like a vendor’s stock SQL Server image) are easier to monitor at the metrics layer than to instrument directly, without modifying or rebuilding something we don’t control.
Where this stands
This lab work is the technical foundation for our upcoming Security monitoring & SIEM and Infrastructure & VM monitoring services. It is not yet a service we’re billing for — we wanted the stack proven on our own time, with our own mistakes, before it touches a client’s environment.
Limits of this test, plainly stated
- The test endpoint ran a deliberately outdated OS image, chosen specifically to guarantee a large, realistic CVE inventory for the demo — the number above describes lab conditions, not a client’s actual exposure.
- This was a single-node lab setup, not a production deployment.
- All credentials used in the lab (dashboard logins, database passwords) were placeholders and would be rotated before any of this touched a real environment.
If you want to see it running, get in touch — we’re happy to walk through it.