Turn protection needs into access requirements

Protection need

Start with a stakeholder and credible harm. Do not start with a control or configuration.

Example: the service owner needs to prevent an unauthorized or unaccountable change to production deployment policy because such a change can expose data or stop customer service.

Identify:

1. The stakeholder whose objective can be harmed.
2. The asset and protected action.
3. The security properties that must hold.
4. The adversary or fault that can violate them.
5. The unacceptable consequence.

For this example, the asset is production deployment policy. The protected action is change. Integrity, authenticity, accountability, and availability matter. Credible threats include a stolen administrator session, a compromised workstation, an overprivileged service, a direct upstream path, a false group attribute, and an emergency procedure that bypasses ordinary review.

Security objectives and requirements

A security objective describes the result the system must achieve. It stays independent of a specific product.

Objective: only an approved production administrator using a managed device can request a policy change; the application must require a separate valid change approval; each accepted and denied attempt must support attribution and review.

Derive specific requirements:

• The route enforcement point must deny a request unless current identity and device facts satisfy the approved route policy.
• No network or application path may reach the administration service without the route enforcement point or an explicitly designed emergency control.
• The application must deny a policy change unless the authenticated principal has the required application permission and the referenced approval is valid for that change.
• The system must expire or revoke route and application access within the stated bound after identity, device, policy, or approval change.
• The route and application must produce correlated evidence without recording reusable credentials.

Use "must" only for a required, verifiable result. Record a performance bound where time matters. "Quickly revoke access" is not testable. "A new protected request is denied within five minutes of group removal under normal dependency operation" is.

Security invariants and evidence

An invariant is a condition that must hold across allowed states or transitions. It gives design and test work a stable target.

For this system:

• Every request that reaches the administration service crossed an effective route enforcement point.
• Every accepted change has one verified user principal, one application permission decision, and one valid approval bound to the exact change.
• A caller cannot create a trusted identity or approval signal through an untrusted request field.
• Denied route requests do not produce a successful application change.
• Emergency access is narrow, time-bound, attributable, and reviewed.

For each invariant, create an evidence plan. A topology and connectivity test can support the first. Assertion validation and header-injection tests can support the third. Correlated route, application, and change-system events can support the second and fourth. An emergency exercise can support the fifth.

Evidence should name the system version, configuration, test input, expected result, observed result, time, and owner. No single log or test proves the complete design.

Failure cases

Test cases must challenge assumptions:

• Send the same request directly to every known upstream address and listener.
• Use a valid session after removing its user from the required group.
• Make the device fact unavailable or invalid.
• Send a trusted-looking identity header without a valid signed assertion.
• Reach the application with gateway access but without the object or action permission.
• Reuse an approval for another change or after its expiry.
• Interrupt the policy or context dependency during an active operation.
• Invoke emergency access and verify its scope, expiry, evidence, and review.

For each case, state whether the system denies, provides limited degraded operation, or enters a controlled recovery path. An unplanned fail-open result is a design failure.

Design tradeoffs and residual risk

Short context lifetimes reduce stale access but increase dependency load and outage sensitivity. Application approval improves action integrity but adds workflow and availability dependencies. Detailed evidence helps investigation but increases privacy and confidentiality exposure. Emergency access helps recovery but creates concentrated authority.

Record residual risks such as a measured revocation delay, a legacy application that cannot verify an assertion, a device signal that can become unavailable, or a recovery process that needs broad authority. Give each risk an owner, monitoring signal, expiry or review date, and condition that requires redesign.

Pomerium boundary

Pomerium can authenticate the access session, evaluate route policy, enforce the route decision, and produce route-level evidence. Its signed identity assertion can let the upstream verify identity context when the application validates signature, issuer, audience, and lifetime.

Pomerium does not define the stakeholder protection need. It cannot close an alternate upstream path that the deployment leaves open. It does not know whether an application approval is valid for a business action. The application and its data systems own those permissions and outcomes.

Exercise

Choose one sensitive action in a real application. Create a table with these columns:

1. Protection need and stakeholder.
2. Asset and action.
3. Security property.
4. Threat and consequence.
5. Objective.
6. Requirement with a measurable bound.
7. Invariant.
8. Mechanism and owner.
9. Negative test.
10. Evidence.
11. Failure behavior.
12. Residual risk and review trigger.

Complete at least three rows: route access, application action permission, and revocation or recovery. Run one negative test. Update the requirement when the observed behavior differs from the claim.

Evaluation checklist

• Does each requirement trace to a stakeholder protection need and credible harm?
• Are objectives independent from product names and implementation choices?
• Is each requirement specific enough to produce a clear pass or fail result?
• Does each invariant cover the complete path rather than one component?
• Is there evidence for configuration, enforcement, and final application outcome?
• Are dependency failure, stale context, bypass, and emergency access tested?
• Does each residual risk have an owner and review trigger?