Control objective
Security telemetry produces evidence that can detect harmful access, explain a decision, measure control health, and guide response. Logs record discrete facts. Metrics aggregate measurements. Traces connect work across components. Events communicate state changes. An alert applies logic and ownership to one or more signals.
Signal design
Start with a question. Select subject, resource, action, policy, result, reason, target, time, version, and correlation fields needed to answer it. Define producer, schema, integrity, latency, volume, retention, privacy, and loss behavior.
Validation
Generate known positive, negative, delayed, duplicated, malformed, and missing signals. Verify collection, joins, alerting, triage, and containment. Monitor the telemetry pipeline itself.
Failure and residual risk
More data can hide the useful signal and expose credentials or personal data. Sampling can remove rare security events. Traces can propagate attacker-controlled fields. A healthy metric cannot prove an uninstrumented path is safe.
Pomerium boundary
Pomerium emits documented access, authorization, and component telemetry. Operators own destination integrity, retention, correlation, alerts, application evidence, and response. Pomerium cannot report direct bypass or final application actions that it does not observe.
Evaluation checklist
- Which detection or investigation question does each signal answer?
- Are producer, schema, integrity, latency, retention, and privacy defined?
- Can records join identity, decision, request, and target action safely?
- Do tests cover signal loss, delay, duplication, and malformed input?
- Can telemetry failure itself be detected and contained?
