This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
SAMM - Security Testing - 2
|
For the latest project news and information, join the mailing list and visit the OpenSAMM website. |
|
|
|
Security Testing - 2
| Objective: Make security testing during development more complete and efficient through automation |
Results
- Deeper and more consistent verification of software functionality for security
- Development teams enabled to self-check and correct problems before release
- Stakeholders better aware of open vulnerabilities when making risk acceptance decisions
Add’l Success Metrics
- >50% of projects with security testing and stakeholder sign-off in past 6 months
- >80% of projects with access to automated security testing results in past 1 month
Add’l Costs
- Research and selection of automated security testing solution
- Initial cost and maintenance of automation integration
- Ongoing project overhead from automated security testing and mitigation
Add’l Personnel
- Developers (1 days/yr)
- Architects (1 day/yr)
- Managers (1-2 days/yr)
- Security Auditors (2 days/yr)
- QA Testers (3-4 days/yr)
Related Levels
Activities
A. Utilize automated security testing tools
In order to test for security issues, a potentially large number of input cases must be checked against each software interface, which can make effective security testing using manual test case implementation and execution unwieldy. Thus, automated security test tools should be used to automatically test software, resulting in more efficient security testing and higher quality results.
Both commercial and open-source products are available and should be reviewed for appropriateness for the organization. Selecting a a suitable tool is based on several factors including robustness and accuracy of built-in security test cases, efficacy at testing architecture types important to organization, customization to change or add test cases, quality and usability of findings to the development organization, etc..
Utilize input from security-savvy technical staff as well as development and quality assurance staff in the selection process, and review overall results with stakeholders.
B. Integrate security testing into development process
With tools to run automated security tests, projects within the organization should routinely run security tests and review results during development. In order to make this scalable with low overhead, security testing tools should be configured to automatically run on a routine basis, e.g. nightly or weekly, and findings should be inspected as they occur.
Conducting security tests as early as the requirements or design phases can be beneficial. While traditionally, used for functional test cases, this type of test-driven development approach involves identifying and running relevant security test cases early in the development cycle, usually during design. With the automatic execution of security test cases, projects enter the implementation phase with a number of failing tests for the non-existent functionality. Implementation is complete when all the tests pass. This provides a clear, upfront goal for developers early in the development cycle, thus lowering risk of release delays due to security concerns or forced acceptance of risk in order to meet project deadlines.
For each project release, results from automated and manual security tests should be presented to management and business stakeholders for review. If there are unaddressed findings that remain as accepted risks for the release, stakeholders and development managers should work together to establish a concrete timeframe for addressing them.
