A Detection Must Prove It Is Still Alive

A Detection Must Prove It Is Still Alive

Connect source, pipeline, analytic, delivery, and case health to the coverage claim consumers see.

Health monitoring turns past validation into current confidence

A detection passes its launch tests in January. In March, a provider changes an enumeration value. The parser accepts the records but stops populating the actor field. Event volume looks normal, the query runs successfully, and the dashboard remains green. The detection has failed quietly.

This is silent failure: the service appears operational while a condition needed for its security claim is broken. General platform uptime cannot reveal every silent failure because the platform may be healthy while one population, field, schedule, or delivery route is not. Health has to reflect the evidence the detection actually needs.

Begin with dependencies. A detection may rely on audit configuration, expected producers, field completeness, entity enrichment, event latency, correlation state, rule enablement, scheduling, alert routing, case creation, and consumer access. Each dependency needs an observable indicator or an acknowledged blind spot. Freshness and volume help, but they become stronger when segmented by tenant, source, event class, and required field.

A canary is known activity expected to traverse the path. A recurring canary can reveal that events are generated, transported, evaluated, and delivered. It should not become the only health signal: one canary path can succeed while another producer disappears. Combine it with completeness, latency distributions, schema drift, execution errors, and delivery acknowledgements.

Health should change what you claim. If the identity audit feed is delayed beyond the correlation window, the affected coverage becomes degraded even if the rule file has not changed. Detection Health Monitoring and Silent Failure explains this dependency-aware model. It prevents a coverage dashboard from presenting stale confidence during an outage.

Continuous assurance joins health with scheduled regression and change events. A provider schema update, parser release, field-map change, new filter, or identity migration should trigger the tests tied to that assumption. The objective is not to rerun everything constantly. It is to know which evidence would make the old validation no longer applicable and to gather new evidence before restoring the claim.

Resources

• NIST Cybersecurity Publications — Primary reference for the standards and concepts discussed in this lesson.