Security Requirements Gathering
Domain 2: Security Requirements Gathering
This domain tests how to turn business and security expectations into requirements that can be designed, built, and verified. The exam favors requirements with measurable acceptance criteria over slogans.
Core rules and concepts
- Separate functional requirements, which describe what the application does, from security requirements, which describe how it resists misuse and protects data.
- Gather from business owners, privacy and legal staff, operations, security, and users. Include regulatory, contractual, and internal policy obligations.
- Use data classification to set handling rules such as public, internal, confidential, and restricted, and define retention, encryption, and access conditions.
- Derive abuse cases and misuse cases from threat modeling: who might misuse a feature, how, and what must happen in response.
- Make each requirement testable by specifying subject, action, condition, threshold, and expected result.
- Include security acceptance criteria, logging and audit needs, error behavior, and dependency and upgrade expectations.
Worked example
Weak: password reset must be secure. Testable version: a reset token is at least 128 bits of cryptographically random data, stored only as a hash, valid for 15 minutes, single-use, and invalidated after a successful reset. The reset response is identical whether or not the email exists. Every reset request and completion is logged with user ID, time, and source IP, but never the token. The reasoning is that each clause maps to a control and a test, and the non-enumeration clause prevents account discovery.
Traps that cost marks
Do not accept use encryption without scope, algorithm class, key management, and data states. Do not omit non-functional requirements such as availability and audit retention. Do not let security requirements arrive after design freeze. Do not write requirements that testers cannot verify. Do not confuse a design decision with a requirement.