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 and watched it catch a real problem. This write-up covers that lab work, not a client engagement. Read the qualifications at the bottom before drawing conclusions from it.
We built a small proof-of-concept stack that combines two things a lot of managed-IT offerings sell 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, so nothing in this stack is something we’d ask a client to take on faith.
The stack
A Wazuh manager, indexer, and dashboard. Prometheus and Grafana for metrics. 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.)
What we demonstrated
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.
We also modified a monitored file on the test endpoint. The change showed up as an event in the Wazuh dashboard within moments.
Then we simulated a CPU spike. Grafana’s dashboard flagged it, and Prometheus fired a threshold-breach alert. The whole pipeline worked, end to end.
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. A live demo won’t alert on cue unless something actually changes during it.
A shared index holds vulnerability data for every agent in a deployment. You filter by agent, not a separate index per host. Easy to expect otherwise the first time you look.
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. We haven’t started billing for it. We wanted the stack proven on our own time, with our own mistakes, before it touches a client’s environment.
Limits of this test
- The test endpoint ran a deliberately outdated OS image, chosen 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.