Secure Platforms and Trusted Components
Build justified trust from small enforcement components, hardened runtimes, boot evidence, isolation, and controlled information flow.
Topic index
Security Engineering Foundations
Learn the system models and design principles behind secure access.
Topic index
Understand this domain
Pomerium coverage
Pomerium can enforce identity-aware policy on a protected route and produce access evidence. The operator still owns the complete system design, upstream isolation, application authorization, dependency behavior, and recovery plan.
Limits
- A model omits detail by design and must be revised when the system, adversary, or environment changes.
- A control claim is not assurance until suitable evidence tests it under expected and adverse conditions.
- Route-level access control does not replace application permissions, endpoint controls, data protection, or recovery engineering.
Primary sources
2 learning paths
Paths for this topic
Security engineering for identity-aware access
Turn a protection need into boundaries, requirements, controls, evidence, failure behavior, and recovery.
9 related guides
Guides in this topic
Build a Privacy Threat Model
Model data actions, observers, linkability, inference, unawareness, loss of control, and human consequences across a complete system lifecycle.
Build application security requirements
Turn application risks into testable security requirements, assurance levels, negative tests, and evidence with OWASP ASVS.
Build assurance for an access control
Connect a protection need to requirements, design, implementation, tests, operations, evidence, and residual risk.
Design access controls that people can use
Use open design, clear choices, safe defaults, and observable recovery so people can operate security correctly.
Design access for resilience and recovery
Keep access controls safe through dependency failures, limit damage, recover service, and prove the restored state.
Minimize a Trusted Computing Base
Derive the real trusted set for one security claim, remove accidental trust, and build evidence for every remaining assumption.
Model and Verify a Security Invariant
Turn one access protection need into a precise state model, analyze adverse transitions, and connect the result to deployed evidence.
Threat-Model a Human Security Workflow
Model the real people, pressures, interfaces, support paths, incentives, and technical controls around one high-impact security task.
Turn protection needs into access requirements
Derive testable security objectives, requirements, invariants, controls, and evidence for one protected action.
24 related terms
Concepts in this topic
Actor, Subject, and Principal
Separate the real-world actor, active subject, represented principal, digital identity, and account.
Adversary Model
State who can attack the system, what they want, what they can do, where they start, and what constrains them.
Asset and Protected Resource
Identify what has value, what needs protection, and which resource an access decision controls.
Assume Breach
Design as if one identity, credential, workload, route, or control will fail, then limit movement and impact.
Attack Tree
An attack tree decomposes one attacker goal into alternate and combined paths that can achieve it.
Complete Mediation
Check every relevant access and prevent alternate paths or stale decisions from bypassing current policy.
Defense in Depth
Place complementary controls across distinct failure domains so one failure does not expose the protected asset.
Economy of Mechanism
Economy of mechanism keeps trusted security functions small, clear, and free of unnecessary shared behavior.
Fail-Safe Defaults
Start from explicit denial and define safe behavior for missing policy, invalid input, dependency failure, and recovery.
Formal Methods and Security Models
Use precise models, invariants, and proofs to answer a bounded security question without confusing the model with the deployed system.
Principle of Least Privilege
Limit authority by resource, action, context, and time, then remove access when the assigned function ends.
Reference Monitor
Evaluate an access-control mechanism for complete mediation, tamper resistance, and evidence-based assurance.
Secure by Design and by Default
Build security into system requirements and architecture, then ship the safest practical configuration as the default.
Security Assurance and Evidence
Distinguish a control claim, verification, validation, assurance argument, and the evidence that supports each conclusion.
Security Engineering
Design complete systems that keep stated security properties under faults, misuse, and deliberate attack.
Security Policy and Mechanism
Separate the rule that states allowed behavior from the components that decide, enforce, and record it.
Security Properties
Distinguish confidentiality, integrity, availability, authenticity, accountability, and privacy in a system claim.
Security Risk
Connect a credible threat, likelihood, consequence, uncertainty, and stakeholder impact to an explicit risk decision.
Security Understandability
Make the system, its authority, dependencies, state, failure behavior, and evidence clear enough to change and operate safely.
Separation of Privilege
Require independent conditions, authorities, or actors before the system permits a sensitive action.
Threat, Vulnerability, and Attack
Distinguish a possible harmful event, a weakness, an attempted exploit, exposure, consequence, and impact.
Trust Boundary and Data Flow
Map where data or authority crosses between components with different control, identity, or assurance assumptions.
Trusted Computing Base
Identify every component whose correct behavior is necessary for a stated security property, then reduce and verify that trusted set.
Usable Security
Make the secure action effective, efficient, understandable, accessible, recoverable, and compatible with the person's real task.
