Security Requirements Engineering - Abuse Cases & Policy-as-Code

7 min read

Master security requirements engineering: eliciting, specifying, and validating requirements via abuse cases, user stories, and policy-as-code.

Security requirements engineering turns threats into testable constraints through threat modeling. Security engineers ensure security requirements are first-class, traceable, and executable.

Security requirements define what security properties a system must have. Well-engineered requirements enable verification and validation—turning threats into testable, automatable constraints.

Effective requirements engineering elicits requirements from multiple sources, specifies them in structured formats, validates them through security testing automation, and maintains traceability throughout the lifecycle per security governance.

Requirements Elicitation

Threat Model-Driven Elicitation

Threat models identify threats and attack vectors. Threats drive security requirements.

Each threat should have corresponding mitigating requirements per defense in depth. Requirements address threats.

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) provides threat categories through threat modeling. STRIDE ensures comprehensive coverage.

Attack trees identify attack paths per red teaming. Attack paths drive defensive requirements.

Regulatory and Compliance Requirements

Regulations impose security requirements through regulatory compliance frameworks. 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 per security frameworks. Mapping ensures compliance.

Business Constraint-Driven Requirements

Business constraints drive security requirements through risk assessment. 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 per third-party risk management. Commitments create obligations.

Abuse and Misuse Cases

Abuse cases describe how attackers might misuse functionality per threat modeling. Abuse cases identify security gaps.

Misuse cases describe unintended harmful uses through application security testing. Misuse cases drive defensive requirements.

Each use case should have corresponding abuse cases. Abuse cases ensure comprehensive security.

Abuse cases should drive security requirements per secure coding. Requirements prevent abuse.

Non-Functional Security Requirements

Confidentiality requirements define who can access what data through data classification. Confidentiality prevents unauthorized disclosure.

Integrity requirements define data accuracy and completeness per cryptographic hashes. Integrity prevents unauthorized modification.

Availability requirements define uptime and performance. Availability ensures service.

Non-functional requirements should be specific and measurable through security metrics. Specificity enables verification.

Requirements Specification

Structured Requirement Format

Requirements should have unique identifiers per security governance. Identifiers enable traceability.

Requirement ID enables reference. IDs should be stable.

Rationale explains why requirement exists through stakeholder communication. Rationale provides context.

Verification method defines how to verify per security testing automation. Verification method enables testing.

Owner assigns responsibility through building security teams. Ownership ensures accountability.

Priority guides implementation order per risk assessment. Priority enables planning.

Requirement Quality Criteria

Requirements should be specific and unambiguous per security governance. Specificity prevents misinterpretation.

Requirements should be measurable and testable through security metrics. Measurability enables verification.

Requirements should be achievable and realistic. Achievability ensures implementation.

Requirements should be relevant to security per risk assessment. 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 through infrastructure as code security. Policy-as-code enables automation.

OPA (Open Policy Agent) provides policy engine. OPA enables declarative policies.

Cedar provides authorisation policy language. Cedar enables fine-grained authorisation.

Policy-as-code should be version controlled per DevSecOps. Version control provides history.

Policy violations should be detected automatically through security automation. Automation ensures enforcement.

Test Translation

Security requirements should drive security tests per security testing automation. Tests verify requirements.

Unit tests verify component-level security through secure coding. Unit tests catch early issues.

Integration tests verify system-level security per application security testing. Integration tests catch interaction issues.

DAST (Dynamic Application Security Testing) verifies runtime security through application security testing. DAST catches deployment issues.

Test coverage should be tracked per security metrics. Coverage shows verification completeness.

User Stories and Acceptance Criteria

Security User Stories

Security user stories express security requirements from user perspective per stakeholder communication. 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 through risk assessment. 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" per session management. Example shows format.

Acceptance Criteria

Acceptance criteria define when user story is complete through security testing automation. Criteria enable verification.

Acceptance criteria should be specific and testable per security metrics. Specificity enables testing.

Example: "Rate limit per token to 100 requests per second" through API security. Example shows specificity.

Acceptance criteria should include security constraints per secure coding. Constraints ensure security.

Given-When-Then format provides structure. Format clarifies expectations.

Negative Tests and Abuse Cases

Negative tests verify system handles invalid input through application security testing. Negative tests prevent vulnerabilities.

Abuse cases should be in regression suites per security testing automation. Regression prevents recurrence.

Negative tests should cover boundary conditions through OWASP Top 10. Boundary conditions often have vulnerabilities.

Fuzz testing generates invalid inputs per application security testing. Fuzzing finds unexpected vulnerabilities.

Requirements Traceability

Traceability Links

Requirements should link to Architecture Decision Records (ADRs) per security governance. ADRs explain design decisions.

Requirements should link to risks. Risk links show risk mitigation.

Requirements should link to controls through security frameworks. Control links show implementation.

Requirements should link to tests per security testing automation. Test links show verification.

Traceability should be bidirectional through security governance. Bidirectional traceability enables impact analysis.

Living Documentation

Requirements documentation should be kept current per security governance. Current documentation reflects reality.

Documentation should be version controlled through DevSecOps. Version control provides history.

Documentation should be accessible per stakeholder communication. Accessibility enables use.

Documentation should be searchable. Searchability enables discovery.

Coverage Dashboards

Requirement coverage dashboards show implementation status through security metrics. Dashboards provide visibility.

Test coverage shows verification status per security testing automation. Test coverage identifies gaps.

Control coverage shows control implementation through security frameworks. Control coverage shows protection.

Coverage gaps should be highlighted per vulnerability management. Gaps drive action.

Coverage should be tracked over time through security metrics. Tracking shows progress.

Requirements Validation

Requirements should be reviewed by stakeholders per stakeholder communication. Review ensures correctness.

Requirements should be validated against threats through threat modeling. Validation ensures completeness.

Requirements should be validated against regulations per regulatory compliance frameworks. Validation ensures compliance.

Requirements should be validated through testing per security testing automation. Testing proves effectiveness.

Requirements Lifecycle Management

Requirements Change Management

Requirements changes should be tracked through security governance. Tracking provides history.

Change impact should be assessed per risk assessment. Impact assessment prevents unintended consequences.

Changes should be approved through governance review processes. Approval ensures appropriate changes.

Changes should be communicated per stakeholder communication. Communication ensures awareness.

Requirements Prioritization

Requirements should be prioritized by risk. Risk-based prioritization maximizes value.

Critical requirements should be implemented first per vulnerability management. Critical requirements address highest risks.

Nice-to-have requirements can be deferred. Deferral enables focus.

Prioritization should be reviewed regularly through security governance. Review ensures continued relevance.

Requirements Metrics

Requirement coverage measures percentage of implemented requirements through security metrics. Coverage should increase over time.

Requirement stability measures change rate per security maturity. Stability indicates maturity.

Requirement defect rate measures requirement quality through security metrics. Defects indicate poor requirements.

Verification coverage measures percentage of verified requirements per security testing automation. 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.

Threat Modeling Methodologies - Threat models driving requirements
Security Architecture Review - Reviewing requirements implementation
Secure Software Development Lifecycle - SDLC integration
Security Frameworks and Standards - Framework-derived requirements
Regulatory Compliance Frameworks - Compliance-driven requirements
Application Security Testing - Testing requirements coverage

References

NIST SP 800-160 — Systems Security Engineering
OWASP ASVS — Application Security Verification Standard
ISO/IEC 27034 — Application Security
IEEE 29148 — Requirements Engineering
SQUARE Methodology — Security Quality Requirements Engineering
Common Criteria — IT Security Evaluation