Model | Verification | Requirements-driven Testing
The goal of the Requirements-driven Testing (RT) practice is to ensure that the implemented security controls operate as expected and satisfy the project’s stated security requirements. It does so by incrementally building a set of security test and regressions cases and executing them regularly.
A key aspect of this practice is its attention to both positive and negative testing. The former verifies that the application’s security controls satisfy stated security requirements and validates their correct functioning. These requirements are typically functional in nature. Negative testing addresses the quality of the implementation of the security controls and aims to detect unexpected design flaws and implementation bugs through misuse and abuse testing. In its more advanced forms, the practice promotes security stress testing, such as denial of service, and strives to continuously improve application security by consistently automating security unit tests and creating security regression tests for all bugs identified and fixed.
While both the Requirements-driven Testing and Security Testing practices are concerned with testing, the former focuses on verifying the correct implementation of security requirements, while the latter aims to uncover technical and business-logic weaknesses in an application, irrespective of requirements.
|Maturity level||Stream AControl Verification||Stream BMisuse/Abuse Testing|
|1||Opportunistically find basic vulnerabilities and other security issues.||Test for software security controls||Perform security fuzzing testing|
|2||Perform implementation review to discover application-specific risks against the security requirements.||Derive test cases from known security requirements||Create and test abuse cases and business logic flaw test|
|3||Maintain the application security level after bug fixes, changes or during maintenance.||Perform regression testing (with security unit tests)||Denial of service and security stress testing|