Clean water & secure SDLC

June 28, 2021 - sdlc application security secure sdlc

Hi. In this post, I would like to write a few words about the secure software development life cycle. Why is it worth implementing and what is the deal with the water?
To the point.

Software Development Life Cycle

Taking into account that the SDLC concept is commonly known so, in a nutshell: The software development life cycle (SDLC) is a framework that development teams use to produce high-quality software systematically and cost-effectively. The SDLC consists of the stages:

planing
requirements
design
development,
testing
deployment & maintenance

All of it looks pretty well in theory but there is one disadvantage of SDLC in terms of security, namely some security-related activities may appear or not. The lack of security activities causes what follows:

Expensive software development. The later vulnerabilities are found, the costs to fix them will be greater.
Friction between developers and the security team. Security slows down the work of developers.
Increased risk of threats - the lack of security activities in development process increases the risk of vulnerabilities not being detected and later can be exploited.

secure SDLC

Could we do something better? Yes, secure SDLC comes with the help.

What is Secure SDLC?

Imagine you are at the river and have two bottles, one with a water filter. You take water from the river. One bottle without a filter is full of micro-plastic particles - security bugs, the other has almost clean water. This is how you can imagine the difference between SDLC and secure SDLC. Secure SDLC is a bottle with a filter that stops most of the pollution.

Secure SDLC brings security assurance activities to every stage of the Software Development Life Cycle. The secure SDLC aims at putting additional security layers in the development process. Secure SDL contains five core components:

Requirements: This stage involves a risk assessment. In this phase the group of specialists (developers, security specialists, product owners) discover the possible risk connected with the software and establish security requirements. This is an extension of the ‘Requirements’ stage of SDLC. Every phase of the secure SDLC should be an ongoing process during software changes. It will help to illustrate possible risks.
Design: This phase identifies potential surfaces of attacks and countermeasures for them. This step, known as Threat Modeling, basically allows the developer team to find answers to 4 questions:
- What are we building?
- What can go wrong?
- What are we going to do about that?
- Was our job good enough? There are many ways to approach this, brainstorming or using a structure model(STRIDE, Kill Chains, CAPEC and others). Also software architecture has to be reviewed and appropriate security requirements have to be defined.
Implementation: The implementation phase concerns writing secure code. In this stage, engineers will write high-quality code based on their knowledge, threat modeling, secure practice guides and static application security testing tools. This step is completed along with the ‘Development’ phase of the SDLC.
Verification: This phase is the completion of the ‘Testing’ stage of SDLC. In this phase, unit and integration tests should be extended to security test cases to validate both positive and negative requirements for security controls such as authentication, access control, input validation & encoding, encryption, user and session management, error handling, auditing and logging. Also, dynamic application security testing (DAST) should be implemented and manual security testing should be conducted.
Release: The last step takes place when all the security activities are confirmed and developers have completed activities from the SDLC (Deployment and Maintenance). As soon as the software is released it is sent to the production environment and then the users can interact with it securely and productively. After that, we should be prepared for handling security incidents. So it is important to have an incident response plan. This topic is very broad, but in short is a set of instructions to help IT staff detect, respond to and recover from security incidents.

Matters that are worth attention in the context of the effective implementation of security SDLC:

Security awareness - understanding of the basis of security for the business team and application security training for developers is crucial for the success of the secure SDLC. Only because of this is it possible to achieve team commitment and understanding for security related activities. Also developers learn to think like a hacker. They can analyze a project's code from an attacker's perspective throughout all phases of software development and detect security gaps.
Automated security tools - almost all security-related activities should be integrated and automated in your pipeline. Also proper tuning and automated security tools allows for eliminating a lot of questions, doubs in the development process.
Non-functional requirement - security is seen as a non-functional requirement (NFR), related to the state of the system, rather than functional areas of the system. Agile teams are focused on delivering new functionalities expected by the customer, so it is worth explaining why we will add additional safety steps in the process and what benefits it will bring.

Conclusion

Above I described general lifecycle phases that cover end-to-end security of the SDLC.

It's worth becoming familiar with various frameworks (link in the References section), approach of secure SDLC before taking a decision on implementation - relay on standard on build own secure SDLC program. The most important thing, before starting your secure SDLC program, should be approved by stakeholders. I believe that it is worth implementing a secure development life cycle. Secure SDLC allows us to catch many security bugs before code of application will be deployed to production. Thanks for that, we can save time and money.

References