Design Privacy-Preserving Security Telemetry

Protection need

Security telemetry must answer defined questions such as who attempted one protected action, which policy made the decision, whether a session moved across devices, and what access followed a compromised identity. Collecting every available request, claim, header, body, and device fact creates a surveillance and breach asset without guaranteeing useful detection.

Security objectives and requirements

For each detection and investigation, list event, fields, precision, identity scope, correlation window, retention, recipients, and response. Separate routine service metrics, detection signals, investigation records, and raw debug data.

Use event and policy identifiers that support correlation without exposing full content. Use scoped pseudonyms for routine analysis when stable real identity is unnecessary. Keep identity resolution in a separately controlled service with an approved investigation purpose.

Exclude tokens, cookies, secrets, full identity assertions, request bodies, URL query secrets, recovery data, and unnecessary personal attributes. Redact before the event leaves the source process so downstream copies never receive the value.

Security invariants and evidence

• Every telemetry field supports a named operational, detection, or investigation question.
• Routine analysts cannot resolve identity or access raw high-sensitivity fields without a distinct workflow.
• Event time precision and retention match the question and do not default to indefinite history.
• Debug mode cannot silently add secret or content fields to shared telemetry.
• Deletion and access changes reach indexes, alerts, exports, cold storage, and restored backups.
• Incident elevation is explicit, time-bounded, reviewed, and recorded.

Failure cases

• A reverse proxy logs bearer tokens and full query strings.
• A global subject ID lets unrelated product teams build a cross-service behavior profile.
• Traces export headers and identity claims to a third-party processor.
• Detection requires thirty days, but raw events persist for years because storage is cheap.
• An alert copies sensitive source data into chat and ticket systems.
• A responder downloads a broad export to a personal workstation.

Detection and privacy tests

Create representative allowed, denied, suspicious, and incident events. Prove the detection still fires and the investigation can answer its question. Inspect logs, metrics, traces, alerts, tickets, dashboards, exports, and backups for prohibited fields and unnecessary precision.

Test identity resolution authorization, bulk access, unusual query, retention expiry, deletion, revoked analyst, third-party destination, debug mode, and restore. Use synthetic sensitive values so leakage is easy to detect.

Design tradeoffs and residual risk

Less identity and shorter retention reduce investigation depth. Pseudonyms preserve linkability. Separate resolution adds latency and a high-value mapping service. Aggregation can hide low-volume targeted attacks. Detailed evidence can protect users from false accusation while increasing data exposure.

State the question that justifies each tradeoff. Protect evidence integrity so privacy reduction does not also remove accountability.

Pomerium boundary

Pomerium can emit identity-aware access logs for configured routes. Operators control destinations, downstream processors, access, enrichment, alerts, tickets, exports, and retention. Upstreams add their own object and action evidence. Pomerium telemetry does not justify collecting unrelated endpoint or application content.

Exercise

Select three detections and two incident questions. Build a field-purpose-retention matrix for Pomerium, identity-provider, application, and infrastructure events. Remove unneeded content and identity fields, create a scoped routine-analysis identifier, and define a separate identity-resolution workflow.

Run the detections and one investigation. Then test raw-token leakage, debug mode, third-party export, analyst revocation, expiry, deletion, and backup restore. Show which questions still work and which evidence you intentionally chose not to retain.

Evaluation checklist

• Does every field, precision, join, recipient, and retention period answer a named security question?
• Are secrets, content, full claims, query data, and unnecessary identity excluded before export?
• Can routine detection work without global real identity, with controlled resolution only when needed?
• Do alerts, tickets, dashboards, exports, cold storage, and backups obey the same controls?
• Are incident elevation, bulk access, third parties, deletion, and investigation tradeoffs explicit and tested?