Deriving Security Test Requirements
You must know the testing objectives to have a successful security testing program. Security requirements specify these objectives. In this section, we will discuss the testing objective and how you can document requirements by deriving them from applicable standards and regulations.
One of the objectives of security testing is the validation of security control if they work as expected or not. Security requirements help document the functionality of the security control. Another objective of security testing is to implement security controls with no or few vulnerabilities. The OWASP Top 10 mentions some of these vulnerabilities, and some other vulnerabilities identified previously during risk assessments in the SDLC.
Understanding business requirements is necessary to document security requirements. For example, if any business wants to provide financial services or deals with online transactions, the security section for its services will highlight the need to secure customer data, and also comply with applicable security standards or regulations.
Compliance with regulatory industry standards is the first step towards achieving security. For instance, a company that handles credit card data of customers needs to comply with the PCI-DSS regulation. According to this regulation, any company handling credit card information can’t store PINs and CCV2 data.
These regulations are necessary for companies handling customer data and require security validation via testing and documentation.
Security Requirements Validation
The main goal of security testing is to validate security requirements. Proper documentation of security requirements can help identify gaps in security controls, such as lack of basic authentication, authorization, or encryption controls. Also, the main objective of security assessment is a risk analysis that can help identify potential weaknesses in the security controls.
If an application needs access to customer data, companies should use different encryption methods in the application to protect that data from threat actors. Different testing techniques can help detect vulnerabilities early in the SDLC. For example, threat modeling can identify security flaws in the design phase, or source code review can help review source code and highlight potential weaknesses in the application code during development.
Security Testing and Risk Analysis
To support a risk mitigation strategy, security testing needs to consider the severity of the vulnerabilities that may be encountered during app development. Identified vulnerabilities can be reported by type, root cause, mitigations, and mapped according to the applications where they are found.
Risk analysis during the SDLC can help identify and evaluate potential issues that can impact the application negatively. Security requirements must involve proper risk assessments to avoid vulnerabilities during the SDLC.
Security Tests Integrated into Development and Testing Workflows
Security testing in the development workflow
Security testing in the development phase of the software development life cycle enables the developers to look for security flaws in the software components individually before they are built into an application.
Source code review allows the developers to verify that the source code developed doesn’t consist of any vulnerabilities and its compliance with the secure coding standards.
Security testing in the testing workflow
Once different components of the software are tested by developers in the development workflow and built into the application, it is time to test the application as a whole entity. These tests may act as the last line of defense for application security before it is released. It is crucial to carry out security testing in the testing workflow with great care.
Security Test Data Analysis and Reporting
Once you are done security testing, and the application is ready to release, you must analyze security test data afterward. It can help you reduce vulnerabilities for the next application development process. Moreover, it enables organizations to measure the quality of their software security.
There are certainly other factors that should be taken into consideration while evaluating the security posture of an application, such as the size of the application. According to the OWASP guide “application size has been statistically proven to be related to the number of issues found in the application during testing”.
Furthermore, reporting is an integral part of security testing. It can help understand why the mitigation controls were ineffective in alleviating the threat. According to OWASP, reporting best practices may include:
- categorization of each vulnerability by type;
- the security threat that each issue is exposed to;
- the root cause of each security issue, such as the bug or flaw;
- each testing technique used to find the issues;
- the remediation, or countermeasure, for each vulnerability;
- and the severity rating of each vulnerability (e.g., high, medium, low, or CVSS score).
The Web Security Testing Framework
The OWASP web security testing guide consists of a reference framework that organizations can adapt according to their security environment and culture. Many organizations still depend on penetration testing that occurs in the development phase. For secure app development, security testing needs to occur in various phases of the Software Development Life Cycle.
Implementing security testing in the early phases of the SDLC is crucial for secure app development.
“In Writing Secure Code, Howard and LeBlanc note that issuing a security bulletin costs Microsoft at least $100,000, and it costs their customers collectively far more than that to implement the security patches. They also note that the US government’s CyberCrime website details recent criminal cases and the loss to organizations. Typical losses far exceed USD 100,000.”
The OWASP testing framework is built on a flexible approach and organizations can develop their own testing framework according to their testing requirements and needs. The web security testing framework can help organizations build a strategic process.
The OWASP experts have provided a general security framework that is given below. However, their purpose is not to impose it on anyone. It is recommended to mold the framework according to the organization’s security needs.
Different phases for security testing according to OWASP Testing Guide
Below are different security testing activities that can take place in the Software Development Life Cycle (SDLC):
- Before development begins
- During definition and design
- During development
- During deployment
- During maintenance and operations
Phase 1: Before Development Begins
This phase consists of different security activities which can take place before app development begins.
Before development begins, organizations can address an SDLC where security testing is prioritized at each phase.
- Review policies and standards
Ensure appropriate policies and standards for software development life cycle. Also, proper documentation needs to be done so that the development team can follow it for secure app development.
For example, an application being made in Java will follow the Java secure coding standard. And same goes for cryptography and other standards. No policies or standards can claim to end security vulnerability completely during the SDLC. However, they can minimize the risk as much as possible.
- Develop measurement and ensure traceability
Develop criteria and ensure traceability before development begins. Doing this can provide insight into the defects in both the product and the process.
Phase 2: During Definition and Design
The activities you can follow during the definition and design phase of the app are:
- Review security requirements
Security requirements are a set of prerequisites for needed security that can help set conditions for security testing. They must be reviewed during the definition and design phase so that any gaps in the requirements are identified earlier.
You can consider looking into the following security mechanism when looking for security gaps in requirements:
- Authentication and password management
- Data confidentiality
- Authorization and role management
- Code integrity
- Data validation, etc
- Review design and architecture
Looking for security gaps in the design phase is one of the most cost-effective ways and it is easy to make changes during design if any vulnerability is identified. Properly document design and architecture. It can include models, textual documents, artifacts, etc.
Reviewing in the design phase allows organizations to test whether they follow the security requirements as mentioned or not. In the event of discovered weaknesses, alternative approaches can be considered for fulfilling security requirements.
- Create and review UML models
Unified Modeling Language (UML) describes how the application will work. Once designing is sorted, build or use pre-available UML models to understand the app’s working and identify weaknesses.
- Create and review threat models
Once reviewing designing and UML models is done, consider undertaking threat modeling exercises. Create different threat scenarios and test for vulnerabilities based on those scenarios. Ensure that these threats are mitigated, reviewed, and removed from the application.
Phase 3: During Development
A code walkthrough is generally not a code review but a way to understand the flow and layout of the code. This can help security teams get a basic understanding and structure of the code that makes up the application.
Code review is a way to look for defects in the code. According to the OWASP guide, Static code reviews validate the code against a set of checklists, including:
- Business requirements for availability, confidentiality, and integrity;
- OWASP Guide or Top 10 Checklists for technical exposures (depending on the depth of the review);
- Specific issues relating to the language or framework in use, such as the Scarlet paper for PHP or Microsoft Secure Coding checklists for ASP.NET; and
- Any industry-specific requirements, such as Sarbanes-Oxley 404, COPPA, ISO/IEC 27002, APRA, HIPAA, Visa Merchant guidelines, or other regulatory regimes.
Phase 4: During Deployment
Generally, testing the requirements, analyzing the designs, and reviewing code can help resolve issues as much as possible. However, penetration testing after the application has been deployed acts as an additional check to look for security defects if any.
- Configure management testing
Penetration testing can help examine app infrastructure and how it was deployed and secured. Review configuration aspects to ensure none are left at the default setting that can cause vulnerability exploitation.
Phase 5: During Maintenance and Operations
- Conduct Operational Management Reviews
Once the application is deployed, conduct operational management reviews to check the operational sides of both application and its infrastructure.
- Conduct Periodic Health Checks
Periodic (monthly or quarterly) health checks should be conducted on the application after deployment to check if new security vulnerabilities have been introduced or not.
- Ensure Change Verification
A typical SDLC workflow is shown in the figure below:
There can be chances of certain changes in the application during the app testing phase. It is essential to ensure that the level of security is not affected by the changes made to the application.