Build assurance for an access control

Protection need

Assurance is justified confidence that a control satisfies a stated need in a stated environment. Begin with the protected resource, security property, threat event, unacceptable consequence, operating assumptions, and decision that the evidence must support.

Replace labels with claims. "Zero trust enabled" is not a claim. "Every request to the production administration route is authenticated, authorized for the named action, and mediated by the configured enforcement point, including after session, policy, and context changes" can be analyzed and tested.

Security objectives and requirements

Decompose the claim into requirements for identity, credential, issuer and audience, resource and action, context freshness, policy, enforcement coverage, direct-path prevention, failure behavior, administration, evidence, revocation, recovery, and dependencies. Assign each requirement an owner and acceptance method.

Trace protection need to threat, objective, requirement, design element, implementation, configuration, test, runtime signal, response, and residual risk. A framework control identifier can index this evidence. It does not replace the system-specific claim.

Use complementary methods. Architecture review finds missing boundaries. Formal or structured analysis tests logic and invariants. Code and configuration review inspect implementation. Positive and negative tests exercise behavior. Fault injection examines dependencies. Penetration tests explore attack paths. Runtime observation checks continuing operation. Independent review reduces shared assumptions.

Use each adversarial method for a different question. A penetration test searches a defined system and time window for exploitable paths. A red team tests whether an organization can prevent, detect, and respond to a realistic objective across people, process, and technology. Continuous control validation repeats narrow positive, negative, bypass, and failure checks against the current deployment. None of these methods proves every path safe. Combine their evidence with design review, configuration state, and runtime observation.

Security invariants and evidence

The protected resource has no unmediated route. Every decision uses the intended subject, resource, action, policy version, and required context. A dependency failure produces the stated safe result. Unauthorized policy changes are rejected or detected. Revoked authority stops within the stated bound. Recovery restores known-good control and rejects old authority.

Evidence must identify scope, environment, version, method, expected result, actual result, time, producer, integrity, and limitations. Prefer evidence produced by the control and independent evidence from the target or surrounding system. Freshness matters: a passed test before a route or issuer change may no longer support the claim.

Failure cases

• The control objective names a product or framework label but no protected outcome.
• A design document proves intent while deployed configuration differs.
• A positive test proves allowed access but no negative test challenges boundaries.
• A penetration test is treated as proof that no other attack path exists.
• A red-team result is treated as a component test, or one scripted validation is presented as a realistic adversary exercise.
• Logs show decisions but not direct-origin or final application behavior.
• Evidence is stale, sampled, produced by the same compromised component, or detached from a version.
• An exception changes the claim without changing the tests or residual-risk decision.
• A compliance mapping is presented as proof of technical effectiveness.

Design tradeoffs and residual risk

Stronger evidence costs engineering and operating effort. Sampling lowers cost and can miss rare paths. Independent evidence increases confidence and may lack internal context. Highly formal analysis can prove a narrow model while implementation or assumptions remain wrong.

Continuous validation detects drift and adds test traffic, credentials, and failure risk. Deep periodic review finds structural problems and leaves longer intervals. Combine methods according to impact and rate of change.

Residual risk includes incorrect requirements, incomplete threats, hidden paths, compromised evidence, operator error, and harmful application actions outside the access control's scope. State confidence and limitations directly.

Pomerium boundary

Pomerium documentation, configuration, decisions, access records, health, and tests can support claims about routed authentication and authorization. They do not prove complete route coverage, identity-provider behavior, application object authorization, direct-origin prevention, or the operator's deployment and recovery controls. Assurance must combine Pomerium evidence with independent network, identity, configuration, and application evidence.

Exercise

Choose one control objective for a production administration route. Write one claim and trace it through ten requirements, design elements, deployed settings, tests, runtime signals, response actions, and residual risks. Mark every assumption and evidence owner.

Run a positive request, an unauthorized subject, a wrong action, stale context, direct-origin attempt, policy-service failure, and revocation test. Change one route setting and show which evidence becomes stale. Have an independent reviewer identify one unsupported inference.

Evaluation checklist

• Is the control claim tied to a named resource, property, threat, and consequence?
• Can each requirement be traced to deployed implementation, test, and runtime evidence?
• Do methods cover design, implementation, negative behavior, failure, and operation?
• Are evidence scope, freshness, version, integrity, and limitations explicit?
• Does the conclusion state residual risk and confidence without claiming that a mapping grants compliance?