Learning outcomes
- Turn an access threat into observable hypotheses and required evidence.
- Combine identity, policy, route, network, and application signals.
- Validate detection logic with known positive and negative events.
- Measure blind spots, latency, precision, recall, and response value.
Operating objective
Detection logic identifies a defined harmful access behavior soon enough to support a useful response. Each detection names the threat hypothesis, protected asset, required data, analytic logic, expected benign behavior, response owner, and known blind spots.
Use ATT&CK to describe observed adversary behavior and investigation pivots. Do not treat a technique name as proof that a control or detection works. Start from the access path: identity source, session, credential, route, policy, enforcement point, upstream, application, and control plane.
Signals and evidence
Useful access detections include direct-origin traffic that has no gateway record, reuse of one credential across unexpected subjects or locations, access after disablement, sudden expansion of allowed resources, emergency policy without expiry, stale policy or context versions, unusual service-account behavior, repeated denied object actions, new issuer or audience, certificate anomalies, and control-plane changes followed by access changes.
Join identity-provider events, Pomerium decisions and access records, configuration changes, DNS and network flow, cloud control-plane events, endpoint signals, and application object actions. Record data owner, schema, latency, retention, expected volume, integrity control, and loss mode.
For each analytic, keep a versioned test set with known positive, benign, ambiguous, delayed, duplicated, and missing-data cases. Measure time to event availability, time to alert, precision, estimated recall, analyst effort, and time to containment. A low alert count does not prove low attacker activity.
Response and recovery
- Write one threat hypothesis with actor, authority, route, resource, action, and consequence.
- Identify the earliest and strongest observable facts across independent sources.
- Build the simplest analytic that preserves the relevant subject, resource, and time context.
- Run safe simulations or replay controlled records. Verify both trigger and non-trigger cases.
- Test delayed, missing, malformed, duplicated, and high-volume input.
- Connect the alert to a named investigation and containment procedure.
- Record analyst disposition and feed false positives, false negatives, and changed system behavior back into the test set.
- Retire detections when the threat, system, or response value no longer justifies them.
Design tradeoffs and residual risk
Broad anomaly detection can find unknown behavior and create high analyst load. Narrow deterministic logic is explainable and misses variations. Correlation improves confidence and fails when identifiers or clocks disagree.
Fast local signals reduce latency and can lack identity context. Central enrichment adds context and delay. Blocking from one weak signal can create an availability incident. Choose monitor, challenge, limit, deny, or revoke based on evidence strength and impact.
Residual risk includes encrypted or unobserved direct paths, attacker use of valid low-volume access, compromised evidence, new applications without instrumentation, and harmful actions that look normal at the route layer.
Pomerium boundary
Pomerium can provide request, decision, route, and component metrics for traffic that it processes. It does not observe direct-origin traffic, identity-provider administration, endpoint compromise, or the application's final object action unless those systems provide evidence. Operators must build correlation, analytics, simulation, alert routing, and response outside Pomerium.
Exercise
Implement three staged detections: one direct-origin request without a Pomerium record, one request accepted after a subject disable event, and one policy change that expands a protected route. Generate known benign controls for each.
Measure event availability, alert delay, precision in the test set, and time to containment. Remove one source and skew one clock. Verify that the detection reports reduced confidence or a telemetry fault instead of silently declaring normal operation.
Evaluation checklist
- Does each detection start from a threat hypothesis and protected consequence?
- Are data requirements, owners, latency, integrity, and blind spots explicit?
- Do repeatable tests cover positive, negative, malformed, delayed, and missing input?
- Does the alert lead to a specific investigation and containment action?
- Can the team detect failure of the detection pipeline itself?
Next learning unit
Intrusion Detection
An intrusion detection system monitors events and produces alerts when it finds signs of an incident or policy violation.
