Secure your Prometheus surface
Alerting rules with no receiver, short retention, and endpoints exposing internals without authentication. We don’t connect to Prometheus to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Prometheus goes wrong
Prometheus goes wrong between rule and route: an alerting rule with no matching Alertmanager route fires into nothing.
- Alerting rules defined without a matching Alertmanager route, so alerts go nowhere
- Retention set to defaults far below investigation needs
- Metrics endpoints exposed without authentication, revealing internal topology
- Alertmanager silences created indefinitely
- Scrape targets down without anyone alerting on the absence
[02] What We Secure
What we watch, catch and fix on Prometheus
On Prometheus we verify rule-to-route matching, because an unrouted alert is silent by construction rather than by accident.
- Rule-to-route matching verified, since an unrouted alert is silent by construction
- Retention assessed against requirement
- Endpoint exposure tested
- Silence inventory reviewed for indefinite entries
- Target health monitored, because a down scrape target means blind monitoring rather than a healthy service
[03] Where It Lands
Where Prometheus lands in your registers
Logging and alerting platforms enter the asset register as critical dependencies, since losing them blinds every detective control you own. Access reviews cover who can alter retention, silence alerts, or read logs containing personal data. The risk register carries what a monitoring gap actually means: an incident window you would not be able to reconstruct.
[04] How We Engage
On Prometheus specifically
On Prometheus, we correct routing, clear stale silences, and add target-down alerting. Retention and storage architecture we plan with your platform team.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Prometheus FAQs
What Prometheus access does Konfirmity need?
Konfirmity needs read access to the Prometheus and Alertmanager HTTP APIs, sufficient to list rules, targets, silences and routing configuration. Where these sit inside a private network we connect through your existing access path.
Why alert on scrape targets being down?
Because a down target means you are not monitoring that service at all, yet no alerts fire from it — which looks exactly like a healthy service. Target-down alerting turns a monitoring blind spot into a visible finding.
Datadog
Splunk
Amazon CloudWatch
Grafana
New Relic