Requirements Elicitation
Threat Model-Driven Elicitation Threat models identify threats and attack vectors. Threats drive security requirements. Each threat should have corresponding mitigating requirements. Requirements address threats. STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) provides threat categories. STRIDE ensures comprehensive coverage. Attack trees identify attack paths. Attack paths drive defensive requirements. Regulatory and Compliance Requirements Regulations impose security requirements. Compliance requirements are mandatory. GDPR requires data protection. GDPR drives privacy requirements. PCI DSS requires payment card security. PCI DSS drives payment security requirements. HIPAA requires healthcare data protection. HIPAA drives healthcare security requirements. Regulatory requirements should be mapped to technical controls. Mapping ensures compliance. Business Constraint-Driven Requirements Business constraints drive security requirements. Business context shapes requirements. Data classification drives protection requirements. Sensitive data requires stronger protection. Service level objectives drive availability requirements. SLOs define acceptable downtime. Customer commitments drive security requirements. Commitments create obligations. Abuse and Misuse Cases Abuse cases describe how attackers might misuse functionality. Abuse cases identify security gaps. Misuse cases describe unintended harmful uses. Misuse cases drive defensive requirements. Each use case should have corresponding abuse cases. Abuse cases ensure comprehensive security. Abuse cases should drive security requirements. Requirements prevent abuse. Non-Functional Security Requirements Confidentiality requirements define who can access what data. Confidentiality prevents unauthorized disclosure. Integrity requirements define data accuracy and completeness. Integrity prevents unauthorized modification. Availability requirements define uptime and performance. Availability ensures service. Non-functional requirements should be specific and measurable. Specificity enables verification.Requirements Specification
Structured Requirement Format Requirements should have unique identifiers. Identifiers enable traceability. Requirement ID enables reference. IDs should be stable. Rationale explains why requirement exists. Rationale provides context. Verification method defines how to verify. Verification method enables testing. Owner assigns responsibility. Ownership ensures accountability. Priority guides implementation order. Priority enables planning. Requirement Quality Criteria Requirements should be specific and unambiguous. Specificity prevents misinterpretation. Requirements should be measurable and testable. Measurability enables verification. Requirements should be achievable and realistic. Achievability ensures implementation. Requirements should be relevant to security. Relevance ensures value. Requirements should be time-bound where appropriate. Time bounds create urgency. Policy-as-Code Translation Security requirements should be encoded as policy-as-code. Policy-as-code enables automation. OPA (Open Policy Agent) provides policy engine. OPA enables declarative policies. Cedar provides authorization policy language. Cedar enables fine-grained authorization. Policy-as-code should be version controlled. Version control provides history. Policy violations should be detected automatically. Automation ensures enforcement. Test Translation Security requirements should drive security tests. Tests verify requirements. Unit tests verify component-level security. Unit tests catch early issues. Integration tests verify system-level security. Integration tests catch interaction issues. DAST (Dynamic Application Security Testing) verifies runtime security. DAST catches deployment issues. Test coverage should be tracked. Coverage shows verification completeness.User Stories and Acceptance Criteria
Security User Stories Security user stories express security requirements from user perspective. User stories provide context. User story format: “As a [role], I want [capability], so that [benefit]”. Format provides structure. Security user stories should include security benefits. Benefits justify requirements. Example: “As a user, I want my session to expire after inactivity, so that my account is protected if I forget to log out”. Example shows format. Acceptance Criteria Acceptance criteria define when user story is complete. Criteria enable verification. Acceptance criteria should be specific and testable. Specificity enables testing. Example: “Rate limit per token to 100 requests per second”. Example shows specificity. Acceptance criteria should include security constraints. Constraints ensure security. Given-When-Then format provides structure. Format clarifies expectations. Negative Tests and Abuse Cases Negative tests verify system handles invalid input. Negative tests prevent vulnerabilities. Abuse cases should be in regression suites. Regression prevents recurrence. Negative tests should cover boundary conditions. Boundary conditions often have vulnerabilities. Fuzz testing generates invalid inputs. Fuzzing finds unexpected vulnerabilities.Requirements Traceability
Traceability Links Requirements should link to Architecture Decision Records (ADRs). ADRs explain design decisions. Requirements should link to risks. Risk links show risk mitigation. Requirements should link to controls. Control links show implementation. Requirements should link to tests. Test links show verification. Traceability should be bidirectional. Bidirectional traceability enables impact analysis. Living Documentation Requirements documentation should be kept current. Current documentation reflects reality. Documentation should be version controlled. Version control provides history. Documentation should be accessible. Accessibility enables use. Documentation should be searchable. Searchability enables discovery. Coverage Dashboards Requirement coverage dashboards show implementation status. Dashboards provide visibility. Test coverage shows verification status. Test coverage identifies gaps. Control coverage shows control implementation. Control coverage shows protection. Coverage gaps should be highlighted. Gaps drive action. Coverage should be tracked over time. Tracking shows progress. Requirements Validation Requirements should be reviewed by stakeholders. Review ensures correctness. Requirements should be validated against threats. Validation ensures completeness. Requirements should be validated against regulations. Validation ensures compliance. Requirements should be validated through testing. Testing proves effectiveness.Requirements Lifecycle Management
Requirements Change Management Requirements changes should be tracked. Tracking provides history. Change impact should be assessed. Impact assessment prevents unintended consequences. Changes should be approved. Approval ensures appropriate changes. Changes should be communicated. Communication ensures awareness. Requirements Prioritization Requirements should be prioritized by risk. Risk-based prioritization maximizes value. Critical requirements should be implemented first. Critical requirements address highest risks. Nice-to-have requirements can be deferred. Deferral enables focus. Prioritization should be reviewed regularly. Review ensures continued relevance. Requirements Metrics Requirement coverage measures percentage of implemented requirements. Coverage should increase over time. Requirement stability measures change rate. Stability indicates maturity. Requirement defect rate measures requirement quality. Defects indicate poor requirements. Verification coverage measures percentage of verified requirements. Verification ensures correctness.Conclusion
Security requirements engineering turns threats into testable constraints through elicitation, specification, validation, and traceability. Security engineers ensure security requirements are first-class, traceable, and executable. Success requires comprehensive elicitation from threat models, regulations, and business constraints, structured specification with IDs, rationale, and verification methods, translation to policy-as-code and tests, user stories with acceptance criteria, and traceability to ADRs, risks, controls, and tests. Organizations that invest in requirements engineering build secure systems.References
- NIST SP 800-160 Systems Security Engineering
- OWASP Application Security Verification Standard (ASVS)
- ISO/IEC 27034 Application Security
- IEEE 29148 Requirements Engineering
- SQUARE (Security Quality Requirements Engineering) Methodology
- Common Criteria for Information Technology Security Evaluation