Security Design and Systems Requirement Setting
Domain 5 covers security design and systems requirement setting: deriving complete, measurable requirements and designing controls into the system. The exam tests requirement quality, allocation, interfaces, security architecture principles, and design trade-offs.
Core rules
- Derive security requirements from stakeholder needs, threat models, control baselines, and obligations.
- Write requirements that are unambiguous, measurable, testable, traceable, and bounded by constraints.
- Separate functional security behavior from assurance and from performance; specify interfaces and data flows.
- Apply design principles: least privilege, defense in depth, domain separation, fail-safe defaults, minimization, and trustworthy recovery.
- Allocate requirements to components and interfaces; define external dependencies and inherited controls.
- Evaluate trade-offs explicitly: usability, cost, performance, assurance, and schedule.
Worked example
A clinical system must protect data at rest. The team writes: 'The system shall encrypt stored records with a FIPS 140-3 validated module using approved algorithms; keys shall be managed in a hardware security module; the system shall log key-use events; decryption shall require role-based authorization.' Each clause is testable and allocates to a component or interface. A trade study rejects application-layer encryption only because backup copies would remain unprotected. The design adds storage-level encryption and a key-management interface requirement.
Traps
Requirement adjectives with no metric such as 'strong' or 'secure'; missing interface requirements; over-specifying a product instead of a need; ignoring inherited controls; and designing controls without operational feasibility.