Secure Software Requirements
Requirements decide everything downstream
Security requirements state what the system must protect and how well, in terms a test can verify. Separate functional requirements (what the system does) from nonfunctional or quality requirements (how well it does it, including security). Security requirements commonly address confidentiality, integrity, availability, authentication, authorization, session management, auditing and logging, privacy, and regulatory compliance.
Sources include laws and regulations, contracts, organizational policy and standards, the threat model, risk assessment results, incident history, and the customer. Elicitation techniques include interviews, workshops, use cases, misuse and abuse cases, attack trees, prototyping, and review of past defects. Misuse cases such as 'a customer changes the order ID in the URL to view another customer's order' are the most productive source of security acceptance criteria. Good requirements are unambiguous, testable, traceable, prioritized, and feasible. Keep a traceability matrix linking requirement to design, code, and test - it supports change impact analysis and audit evidence.
Traps
- 'The system shall be secure' is untestable and therefore not a requirement.
- Verification (built to spec) differs from validation (built the right thing).
- Over-specifying implementation, such as naming a cipher, is a design constraint and acceptable only when policy or compliance mandates it.
- Requirements come from regulators and internal policy, not only the customer.
Rule of thumb
If you cannot write the test case, rewrite the requirement. 'Session cookies shall be marked Secure and HttpOnly and expire after 15 minutes of inactivity' is a requirement; 'sessions must be secure' is a wish.