Model the opponent
An adversary model describes the actors that can deliberately cause harm. For each actor, state the goal, starting access, capabilities, knowledge, resources, persistence, and constraints. Include insiders, compromised accounts, malicious services, supply-chain actors, and automated abuse when they fit the system.
Capability matters more than labels
"External attacker" says little. Can the actor send public requests, steal a session, control a client, operate an upstream account, change DNS, read a network segment, alter policy, or compromise a dependency? A useful model states which trust boundaries the actor starts outside or inside.
Connect actors to paths
For each protected asset, ask how the actor can reach it and which assumptions the path challenges. Consider direct access, misuse of legitimate authority, confused deputies, stale access, control-plane compromise, and denial of service. Keep accidental faults in the system model even when they are not adversarial.
Failure and residual risk
Teams often model only a remote unauthenticated attacker and omit privileged operators, compromised trusted services, and stolen sessions. An adversary can also change tactics after observing controls. Review the model after exposure, dependency, identity, or business changes.
Pomerium boundary
Pomerium can reduce some attack paths by placing policy enforcement before an upstream. It cannot remove a direct upstream path, secure a compromised application, or make a false identity source true. The adversary model must include the Pomerium control plane, identity provider, client, and upstream as distinct components.
Evaluation checklist
- Does each adversary have a goal, starting position, capability, and constraint?
- Are insiders, stolen sessions, compromised services, and operators considered?
- Can the adversary reach the asset through a path that avoids the gateway?
- Which trusted component would most increase capability if compromised?
- What event requires the adversary model to be reviewed?
