Architecture, Design, and Implementation
This domain tests secure-by-design reasoning: deriving controls from principles, modelling threats before code exists, and knowing exactly where trust boundaries sit.
Design principles
- Least privilege, separation of duties, defense in depth, fail-safe defaults (deny on error), complete mediation, economy of mechanism, open design, psychological acceptability - the Saltzer and Schroeder set, still examinable.
- Zero trust: verify explicitly, assume breach, use least-privilege access and microsegmentation instead of perimeter trust.
- Reference monitor and TCB: small, verifiable, always invoked, tamper-proof.
- Shared responsibility: in IaaS the provider secures the cloud; you secure what you put in it. The split shifts for PaaS and SaaS but never disappears.
Threat modelling
Apply STRIDE per element and per trust boundary: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Output is a list of threats, mitigations, and residual risk - not a document filed and forgotten.
Worked example
A payment microservice calling a database. Spoofing: mutual TLS plus workload identity. Tampering: signed requests, parameterized queries. Repudiation: immutable audit log with correlation IDs. Information disclosure: TLS in transit, KMS-managed encryption at rest with rotation. Denial of service: rate limits, autoscaling, WAF. Elevation: short-lived IAM roles, no wildcard permissions, secrets manager instead of baked-in credentials. Reasoning: each mitigation maps to a STRIDE letter and a named principle; nothing is added merely because it is a common best practice.
Traps
Treating network segmentation as the only control; adding encryption without key management and rotation; confusing authentication with authorization; assuming the cloud provider covers your configuration and data; drawing trust boundaries that ignore the browser or the API gateway.