Security SOW review
Oleksii Popov
CTO | Delivering Scalable Software Solutions in Cloud, AI, Data | Leading Education Initiatives
As technology continues to advance, the need for secure software development has become increasingly important.
But there is not so much information on how to work with security projects from a technical manager's point of view.
I would like to share specific focus points needed to prepare a good security project Statement Of Work (SOW) and how to include security questions in your project lifecycle.
Secure Development Lifecycle
A key component of the software development lifecycle is security.
Secure development seeks to ensure that a product is not just protected from "common threats," but also that its level of security is predictable and meets its specific needs. Every product is handled uniquely, and throughout the development process, specific efforts are made to detect and mitigate vulnerabilities unique to that product. Threats to confidentiality, integrity, and availability, as well as their corresponding mitigations, are gathered based on industry standards, best practices, and any unique requirements of the product being developed.
Best practices from OWASP and PCI DSS compliance requirements should be taken into account right away and have an impact on subsequent security-related actions.
How to achieve it? The answer is simple: the development team should be trained for it. Prior to beginning development, mitigations should be considered, and the security impact should be monitored. Security testing activities should also be included.
A good strategy is to utilise OWASP Code Review Guide to effectively find vulnerabilities.
Security code reviews examine modifications that may have an impact on data privacy, compliance with security regulations, or the use of security features like encryption, authentication, and authorization. The individuals in charge of the project's security (security advisers, security champions) conduct security code reviews.
High-priority factors to check:
- Code structure
- Input/output processing
- Data persistence, data footprint
- Security context
- Transport
- Resources consumption
- Multithreading and race conditions
- Exception throwing/handling
- Logging
If possible, it should also do:
- Impact analysis for introduced functionality
- Threat models are reviewed for existing features.
- Attack surface review
- Review of 3rd party dependencies
- Review of mitigation plans
- Deployment model assessment
- Documentation review
领英推è
DevSecOps
At the heart of secure development is the idea of DevSecOps, which promotes a balance between human intelligence and automation.
DevSecOps is a combination of development, security, and operations. By integrating automation, agility, feedback loops, and cross-functional cooperation into the SDLC, it aims to accelerate the delivery of secure, high-quality software. To enable secure software development, DevSecOps uses the same DevOps concepts and prioritizes the following:
- Security should be the responsibility of everyone involved in the development process.
- Use automation whenever possible.
- ???Shift Left - philosophy highlights the value of testing and evaluating code quality at the start of the Software Development Life Cycle (SDLC) instead of being performed only at the end of the process.
- Check dependencies for vulnerabilities.
DevSecOps approach makes the process of eliminating security issues context-specific and effective. Appropriate tooling is:
- SAST - Static Application Security Testing
- DAST - Dynamic Application Security Testing
and more complex:
- RASP – Analyze & Self-defense at Runtime
- IAST - Interactive Application Security Testing
- SCA - Software Composition Analysis
- By understanding and utilizing appropriate tooling, teams can continuously leverage their existing SDLCs to create a secure product.
Following this article, you already understand what important processes should be added for a secure development project. Let’s go back to an RFP/RFI/SOW review.
Secure SOW checklist
When responding to RFP/RFI/SOW questionnaires related to security, there are several criteria to consider. Threats and respective mitigations in confidentiality, integrity, and availability should be gathered based on industry standards, best practices, and the particular requirements of the product under development.
You can check out my article, where I gave an overview of what SOW is and how it should be cooked prior to sign-off.
Checklist for security RFP/RFI/SOW documents:
- Integrating security requirements into the system is not omitted as long as functional and non-functional requirements are met in the design and verification phases.
- Information security reviews of business requirements are carried out as part of the security development process (security/privacy assessments) by the development team or a separate application security team.
- Privacy requirements are clearly defined.
- Unauthorised disclosure of application configuration information - connection strings, encryption keys, and other sensitive data are thought to be found in the application configuration. Thus, both the hazards of information disclosure and tampering must be prevented from affecting the configuration files.
- Software vendors must guarantee code integrity. The code is shielded against unauthorized changes while it is being developed. Testing and code reviews maintain the integrity of the code.
- Analysis of software security risks. An impact analysis is done, and every change is evaluated and reviewed before being implemented. With the application owner's approval, all changes are made.
- Required security features must be included in the application design.
- Security verification tests. Security features must be built, validated, and tested in accordance with this requirement. The security testing team can be involved in this process.
- Approval and use of production data for testing purposes are clearly defined.
- Developer access during testing is restricted to certain groups only.
- Only the tools and components that are necessary are configured in the production environment. It cannot be used for debugging or development.
- Acceptance testing is defined.
Implementing a secure development practice along with DevSecOps principles is crucial for creating secure software products. By considering industry standards and best practices when responding to RFP/RFI/SOW questionnaires related to security, teams can ensure that their products meet necessary security requirements.