The main purpose: CyberSecurity should help businesses succeed.
Structure:
1. Main goal of Secure Software Development Life Cycle (SSDLC)
2. Controls that can be implemented on different stages of the Secure Software Development Life Cycle
3. What methods are the most effective in identifying vulnerabilities based on OWASP rating
4. Example of potential implementation of the SSDLC from scratch to existing product
1) Main goal of Secure Software Development Life Cycle (SSDLC)
Secure SDLC (SSDLC) — is a collection of best practices focused on adding security to the standard SDLC. Creating a Secure SDLC process requires dedicated effort at each phase of the SDLC.
Existing approaches of building SSDLC: Microsoft, OpenSAMM, BSIMM.
Main stages of the SSDLC:
1. Phase 1: Requirements
2. Phase 2: Design
3. Phase 3: Development
4. Phase 4: Verification
5. Phase 5: Maintenance and Evolution
Cost to fix a defect by development phase
Main goal of the SSDLC: Integrating security checks as early in the SDLC as possible to reduce the risk of appearing vulnerabilities in production and thus reduce the costs of fixing the vulnerability.
Common problems during the implementing SSDLC process: complexity of
implementation, a bad balance between implementing security controls and new features delivery, poor communication between teams.
Possible Solution: Implementing the additional security measures should not be aligned on the “breaking” existing process, but on “improving” the current process. It can be achieved by analyzing the existing process, implementing additional controls in a test mode, assessing its impact and implementing it on an ongoing basis.
2) Controls that can be implemented on different stages of the Secure Software Development Life Cycle
Phase 1: Requirements
Description: In this early phase, requirements for new features are collected from various stakeholders. It’s important to identify any security considerations for functional requirements being gathered for the new release.
Activities: Requirements review, Threat Modeling
Examples:
● Sample functional requirement: user needs the ability to verify their contact
information before they are able to renew their membership.
● Sample security consideration: users should be able to see only their own contact information and no one else’s.
Phase 2: Design
Description: This phase translates in-scope requirements into a plan of what this should look like in the actual application. Here, functional requirements typically describe what should happen, while security requirements usually focus on what shouldn’t.
Activities: Design review, Threat Modeling
Examples:
● Sample functional design: page should retrieve the user’s name, email, phone, and address from CUSTOMER_INFO table in the database and display it on screen.
● Sample security concern: we must verify that the user has a valid session token before retrieving information from the database. If absent, the user should be redirected to the login page.
Phase 3: Development
Description: When it’s time to actually implement the design and make it a reality, concerns usually shift to making sure the code is well-written from the security perspective.
Activities: Static application security testing (SAST), Software Composition Analysis (SCA), Security Code review, Developers education.
Phase 4: Verification
Description: The Verification phase is where applications go through a complete testing cycle to ensure they meet the original design & requirements.
Activities: Dynamic application security scanning (DAST), Manual investigation of the developed feature, QA team education.
Phase 5: Maintenance and Evolution
Description: The story doesn’t end once the application is released. In fact, vulnerabilities that slipped through the cracks may be found in the application long after it’s been released. It also may appear in the open source used.
Activities: External pentest, launching bug bounty program, components tracking of production environment, the security team should be in line with latest trends, news, techniques and vulnerabilities.
3) What methods are the most effective in identifying vulnerabilities based on OWASP rating
Source: OWASP Code Review Guide v2, page 14
Link: https://owasp.org/www-pdf-archive/OWASP_Code_Review_Guide_v2.pdf
Based on the information above, we can made the following conclusions:
● SAST -> Injection, Sensitive data exposure
● DAST -> Using components with known vulnerabilities
● Broken Access Control -> Manual Code Review
● Other parts -> Manual pentest
4) Example of potential implementation of the SSDLC from scratch to existing product
Initial conditions: There is no dedicated security team or anyone who is responsible for application security. Security best practices are not implemented in the current software development life cycle. The company has a well-functioning process of development, testing and deployment. There are teams of Product, Development, QA and DevOps.
Reason: The company begins to attract large customers for whom the aspect of product security is important.
Goal: Build a security team or attract at least one person who will lead the Application Security process.
Action: The company hired the first person in the AppSec team.
The AppSec engineer has a lot of questions at this stage…
Let’s think about what might be a good starting point for him. The following steps can be highlighted:
1)Getting to know the team and existing processes
Result:
● Basic understanding of existing processes
● Contact of persons from different teams: Product, Development, QA
and DevOps.
2) Security requirements
Do we have the security requirements that we impose on our product? If no, we should design them based on the OWASP Application Security Verification Standard and best practices.
Result:
● Security Requirements Document created
● The Security Requirements Document is a starting point for all new
security team members
3) Investigate
The AppSec engineer should investigate the product security in line with security requirements and best practices
Result:
● New security issues discovered
● New security issues prioritized
● Discussion with the team who will fix it and in what time frame
● New security issues assigned
4) SAST
The AppSec Engineer discusses with Devops team what SAST tool can be added to the pipeline
Before it done:
● AppSec Engineer can run SAST on requested parts or whole
codebase
● Validating results with focus on Critical and High severity
Result:
● Devops team add the SAST solution to the pipeline with Security
gates, next to quality gates in test mode
● AppSec Engineer analyze the results of woking SAST solution and
disable/edit rules that gives the most of false positives
5) When new functionality is designed
● AppSec Engineer discussed with product team what features will be
further implemented
● AppSec Engineer made a threat modeling on feature functionality
● AppSec Engineer discussed with Product & Engineering team what
requirements should be presented to features to reduce risks
6) When new features deployed for verification
● The AppSec Engineer designed short guide with the simplest checks
for the QA team
● The AppSec Engineer scan new functionality with DAST solution
● The AppSec Engineer made an advanced manual security check on
new functionality.
7) Further activities
● When already discovered issues fixed, the AppSec Engineer will
design policy and work on launching the bug bounty program
● The AppSec Engineer monitor for new vulnerabilities in used
open-source components on production
● The AppSec Engineer lead all external pentest activities
● The AppSec Engineer conducts presentations and training for
developers aimed at identifying vulnerable code
Also, read DevSecOps, from what to start?
I hope you enjoyed it, please Subscribe!!!
