Learning outcomes
- Define risk from named assets, threat events, likelihood, and impact.
- Evaluate control effectiveness with evidence instead of control names.
- Record assumptions, uncertainty, dependencies, and residual risk.
- Turn risk results into owned engineering and operating decisions.
Protection need
Assess one defined access system and decision horizon. Name the protected resources, security properties, owners, users, workloads, data, dependencies, and unacceptable outcomes. Avoid a generic label such as "identity risk." A useful risk statement connects a threat event to a consequence.
Example: an attacker with a stolen developer session reaches a direct administrative endpoint, changes production policy, and causes unauthorized data access before revocation. This statement exposes the identity, route, action, asset, and time assumptions that controls must address.
Security objectives and requirements
Turn protection needs into testable objectives. Only approved administrators through the enforced route can change production policy. A disabled account cannot make a new request after the stated bound. A policy change has two-person review and immutable evidence. A direct endpoint rejects callers outside the gateway.
Identify threat sources and events: credential theft, insider misuse, workload compromise, control-plane takeover, route bypass, issuer compromise, stale context, policy error, dependency outage, and denial of service. Estimate likelihood from exposure, capability, preconditions, observed events, and control strength. Estimate impact across confidentiality, integrity, availability, safety, operations, and recovery.
Security invariants and evidence
For each control, state the claim, implementation owner, enforcement point, test, evidence, failure mode, and residual risk. "MFA enabled" is not enough. State which authentication event requires which factor, how session theft is handled, and what a negative test proves.
Record assumptions and uncertainty. Examples include identity-provider uptime, group freshness, clock accuracy, complete route inventory, key custody, and application authorization. Assign owners to validate them.
Failure cases
- The assessment lists vulnerabilities but no assets or outcomes.
- A control name is treated as proof of effectiveness.
- Likelihood is copied from a generic matrix without system evidence.
- Impact ignores control-plane or recovery compromise.
- The team assumes every request uses the intended gateway.
- Residual risk is marked accepted without an accountable owner and review trigger.
- A change in identity provider, route, tool, or upstream does not trigger reassessment.
Design tradeoffs and residual risk
Quantitative estimates improve comparison and can imply false precision. Qualitative ratings are easier and can hide different assumptions. Show the evidence and uncertainty behind either method.
Controls can reduce likelihood, impact, or both. Some transfer failure into availability or operations. Short credential lifetimes reduce replay and increase issuer dependency. Fail-closed policy protects sensitive resources and can stop critical work.
Residual risk is the risk after current controls. Name the remaining path, maximum exposure, owner, acceptance or treatment decision, and trigger for review.
Pomerium boundary
Pomerium can provide route authentication, authorization, and access evidence for deployed paths. The assessment must also cover identity providers, devices, networks, direct upstreams, applications, control planes, credentials, and recovery. Pomerium does not supply the business impact or accept residual risk for the owner.
Exercise
Assess one administrative application. Draw its complete request and control path. Write five threat events. For each, record likelihood evidence, impact, controls, negative test, residual risk, owner, and next review trigger.
Run at least one test for direct bypass, stolen session, stale group, policy error, and identity-provider outage. Update the assessment from the measured behavior.
Evaluation checklist
- Does every risk connect a threat event to a named asset and consequence?
- Are likelihood and impact supported by system-specific evidence and assumptions?
- Does each control have an owner, enforcement point, test, and failure mode?
- Are direct paths, control planes, dependencies, and recovery included?
- Does every residual risk have an accountable decision and review trigger?
Next learning unit
Security Risk
Connect a credible threat, likelihood, consequence, uncertainty, and stakeholder impact to an explicit risk decision.
