Why a valid detection rule still cannot fire
Syntax validation answers whether a rule is accepted. Readiness answers whether production can satisfy its assumptions.
A detection rule can pass CI, deploy successfully and remain operationally incapable of firing. This is not an edge case. Rules depend on data sources, event categories, normalized fields, time windows, storage freshness and downstream routing.
Extract the hidden dependencies
Take a rule that detects suspicious Kubernetes exec activity. Its query may assume fields such as verb, objectRef.resource, requestURI, user.username and sourceIPs. It also assumes Kubernetes audit logging is enabled, the relevant policy stage is captured, events reach the query store and the parser preserves those fields.
Represent those assumptions explicitly. A rule should link to one or more telemetry contracts, and every contract should state required fields, source, destination and freshness.
Classify readiness, not just enabled state
A practical readiness model has four states:
- Ready: all required telemetry conditions are currently verified.
- Partial: events arrive, but fields, freshness or routing are incomplete.
- Cannot fire: a required source or event class is absent.
- Unknown: the prerequisite has not been tested recently.
This classification makes an important operational difference. A disabled rule is visible. An enabled rule with absent input often is not.
Use safe synthetic validation
Queries can prove recent evidence exists, but some paths need active testing. A controlled dry-run API call, synthetic authentication attempt or scoped canary event can verify ingestion and classification without generating harmful behavior.
Record every stage separately: generated, accepted by the source, observed in storage, fields valid, detection evaluated and evidence recorded. A partial result should identify the exact stage where proof stopped.
Prioritize by consequence
Readiness findings should inherit business context from the detection. A missing field for an informational rule is not equal to a broken privileged-access detection. Add severity, system criticality, internet exposure and ownership to the result.
Then treat the finding as engineering work: assign an owner, state the impact and verify the fix with the same check that exposed the problem.
Make drift visible
Parser releases, source configuration and platform upgrades change continuously. Detection readiness therefore expires. Run checks on a cadence and after relevant changes. Keep the latest proof and the history of state changes so teams can distinguish persistent gaps from new regressions.
The goal is not a larger rule count. It is a smaller set of rules whose operating conditions are known.