This article is part of a series that explores the practices of the OWASP SAMM (Software Assurance Maturity Model) [1] framework. This article will discuss Requirements-Driven Testing in Application Security for the Verification business area.
As defined by SAMM, Security Requirements-Based Testing for Applications is a technique used to ensure that an application meets the specified security requirements in the project. It can involve conducting pentests and both user interface and code security tests.
This is a crucial step in the software development process as it allows us to verify that the application is free of vulnerabilities that could compromise the security of users.
Requirements-Driven Testing
Requirements-driven testing is part of the verification and validation activities of the software development lifecycle. They are performed to ensure that a system meets previously established security requirements.
1. It is important to observe the following steps for conducting requirements-driven testing:
2. Identify application security requirements and document them clearly and accurately;
3. Plan the tests to be carried out, which tools to use, and those responsible for execution;
4. Run the tests and record the results;
5. Analyze the results to identify any vulnerabilities or security issues found;
6. Fix the vulnerabilities.]
To define the security requirements for a system, conduct an analysis of potential threats, vulnerabilities, and security measures within the scope of the system being tested. Various techniques can be employed for this analysis, each with its advantages and drawbacks.
One technique could involve using requirements identified through threat modeling (as shown in Figure 1) or a pre-established list of requirements such as the ASVS (Application Security Verification Standard). These techniques can be used separately or in combination, depending on the specific needs and context of the project. When selecting and implementing these techniques, keep in mind the particular scenario and environment of the application being tested.
During testing, evaluators or testers aim to uncover vulnerabilities and other security weaknesses that could affect the application. They also verify that the application adheres to the security policies and standards set by the company. Testing can be carried out by various types of professionals, such as security engineers, test analysts, and software developers.
In Figure 1, we see a list of requirements created from a threat modeling carried out in Conviso Platform to perform an API Test.
Figure 1: Test requirements list from a threat modeling (Conviso Platform)
Requirement-based testing is complementary to other security practices, such as automated testing (AST), as shown in Figure 2.
Requirement-driven Testing examples
During the design phase, security requirement-based testing for applications may include conducting a risk analysis to identify the main security risks for the software and how to mitigate them. During the development phase, testing may include checking the code to ensure it adheres to established security standards and performing penetration testing to verify the software’s resistance to cyber-attacks.
Each type of test aims to verify a specific area of the application’s security.
For instance, consider the scenario where you are developing a password management system for a company, and one of the security requirements you have established is that user passwords are stored in an encrypted format. To verify if the requirement is being met, you could conduct a security requirement-oriented test by entering a password into the system and confirming that it is stored in encrypted form.
If the password is stored in encrypted form, the test is deemed successful.
However, if the password is not stored in this way, the test will be considered failed, and the development team will need to address and fix the issue before the system can be deployed to production.
As another example, consider a scenario where the requirement is to ensure that the system is protected against brute force attacks. In this case, a security requirement-oriented test might involve attempting to log in with incorrect passwords multiple times in a row and checking whether the system blocks the user account or the request’s source after a certain number of failed attempts. The test is successful if the system behaves as specified in the security requirement. However, if the system does not crash or block the user as expected, the test has failed, and the issue must be addressed and resolved before the system can be deployed to production.
It’s important to note that these are just a few examples to provide context and do not cover all types of tests that could be conducted for a given set of requirements.
Maturity levels
SAMM provides a framework for assessing and improving software security. It is divided into three maturity levels, each with a set of specific security practices and two streams: Control Verification – Stream A and Testing for misuse/abuse – Stream B.
- Maturity Level 1: requirement-based testing is performed on an ad hoc basis without a formalized or automated process. The focus is mainly on identifying and fixing security issues after they occur, so control verification in flow A (Software security control testing) and misuse or abuse testing in flow B (Security fuzzing testing) are carried out reactively after a problem has been identified, thereby finding basic vulnerabilities.
- Maturity Level 2: requirement-based testing is integrated into the software verification and validation process. At this level, the company can identify and fix security issues during the software lifecycle, so control verification in flow A, which derives test cases from known security requirements, and misuse or abuse testing in flow B, which creates and tests abuse cases and business logic failure tests, can be performed proactively, i.e., before a problem occurs, by conducting reviews to discover new risks.
- Maturity Level 3: requirement-based testing is integrated into the software development process, and there is a set of processes and tools to manage software security. At this level, there is a mature management approach to preventing security issues, so control verification in flow A (Regression testing with unit tests) and misuse or abuse testing in flow B (Denial of service testing and security stress testing) are carried out proactively during software development, ensuring the system’s security throughout the software lifecycle. In addition, it’s possible to integrate these activities into the regression testing process, which is carried out whenever there are changes to the software to ensure that they do not affect the system’s security. With its high maturity, the company can maintain the application’s security level with the practices adopted here.
Tools
Conviso Platform [2] is a comprehensive suite of application security verification tools that follows the SAMM framework and can perform requirement-driven testing in application security. It offers several features, such as code analysis and automated testing, that help developers identify vulnerabilities (Figure 1) in their applications and provide recommendations for fixing them. It can also monitor application security in real time and evaluate the effectiveness of implemented security measures.
In addition to its capabilities for identifying and fixing vulnerabilities, Conviso Platform can also help organizations efficiently and effectively implement and manage various types of security testing, including code reviews and penetration tests. Its integrated platform provides a centralized, streamlined approach to managing these tests, allowing organizations to ensure their applications’ security confidently.
Some of Conviso’s products that meet these purposes include:
- Secure by Design: supports the integration of security into the software development process, which helps to minimize vulnerabilities and ensure that products are more secure and of higher quality;
- Secure Pipeline: supports the integration of security into all stages of the CI/CD process, which helps ensure that applications are released more securely and efficiently; and
- Attack Surface: supports the identification and management of an application’s attack surface, which helps to minimize the risk of attacks.
Figure 2: Vulnerabilities identified after automated testing on Conviso Platform
Note: In the following article, we will delve further into the topic of Application Security Tests.
Conclusion
Application security verification is essential to ensure users’ protection from cyber threats.
When performing requirement-driven testing in application security, you should keep in mind application security is not something fixed and static but rather something that needs to be constantly maintained and updated. Therefore, it is essential to continue performing regular security tests, even after an application is released into production, because they help ensure that software is secure and reliable, protecting both users and the organization itself from security threats.
SAMM article series
- Governance according to SAMM: Strategy and Metrics in Application Security
- Governance according to SAMM: Policies and Conformities in Application Security
- Governance According to SAMM: Application Security Education and Guidance
- Design according to SAMM: Threat Modeling in Application Security
- Design According to SAMM: Security Requirements in AppSec
- Design according to SAMM – Secure Architecture in Application Security
- Implementation according to SAMM: Secure Build in Application Security
- Implementation according to SAMM: Secure Deployment in Application Security
- Implementation According to SAMM: Defect Management in AppSec
- Verification according to SAMM: Application Security Architecture Analysis
- Verification according to SAMM: Requirements-Driven Testing in Application Security
- Verification according to SAMM: Security Tests in Application Security
- Operations according to SAMM: Application Security Incident Management
- Operations according to SAMM: Environment Management and Application Security
- Operations according to SAMM: Operational Management in Application Security