Security Architecture, Design and Engineering
Security architecture and engineering is where requirements become structures: reference designs, trust boundaries, component placement and design principles that keep a system secure when parts of it fail. The exam probes named design principles, threat modelling technique, and how architecture decisions are documented and governed so assessors can trace a control requirement to a component.
Design principles worth naming
- Least privilege, separation of duties, and least common mechanism (avoid shared state between users).
- Economy of mechanism and open design: simple, reviewable designs; security must not depend on secrecy of the design itself.
- Complete mediation: every access is checked every time, with no cached bypass.
- Fail-safe defaults: deny by default; authorisation fails closed, and fail-open is reserved for safety-critical cases.
- Psychological acceptability: users will follow controls that do not obstruct them.
Trust boundaries and threat modelling
Diagram data flows and mark every boundary where data crosses privilege or ownership (browser to API, API to database, tenant to tenant). Apply STRIDE to each element: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. Every threat gets a mitigation or a recorded accepted risk, prioritised by DREAD or likelihood times impact.
Architecture governance
Patterns such as zero trust, hub-and-spoke, defence in depth and segmentation are selected to satisfy policy, not fashion. Design reviews, architecture decision records and time-limited exceptions keep the design honest as it evolves, and reference architectures give project teams a compliant starting point.
Worked example
For a login service: browser to API crosses an untrusted boundary, so spoofing is mitigated by TLS with certificate validation and rate-limited credential checks; tampering of the request body is mitigated by server-side validation; repudiation is mitigated by authenticated audit logs with synchronised time; verbose errors are replaced by generic messages to limit information disclosure; denial of service is reduced by rate limiting, with lockout tuned to avoid a lockout attack; elevation is mitigated by server-side role checks that never trust a client-supplied role. Each mitigation sits at the boundary it protects.
Traps
- Treating a VPN or firewall as architecture; architecture is about placement and trust, not a product.
- Relying on obscurity as the primary control.
- Privilege checks only in the user interface.
- Threat models written once at design and never revised when data flows change.