The Software Development Life Cycle, or what is known by its acronym SDLC, is the whole process that any new development in an organization has from the idea of it until it is already implemented in production.
In recent times, what is sought is to introduce security in this process, since all development has its main phases (as shown in the following image on the left), what is tried by introducing security is to define some phases At the same time, as work is being carried out, safety is considered (as shown in the image on the right):
Software life cycle and security
In the previous images we can see that each phase has its corresponding security phase, for example, at the time that tests of the correct operation of the application are being carried out, a dynamic audit of it should be carried out in which they can be seen vulnerabilities before the production phase.
The implementation of security measures must be done from the beginning of the Software Development Life Cycle, since the cost of solving any security problem is higher the later it is detected, as shown in the following graph:
Security in Software development
In the end, in many organizations or development departments for not implementing security in them, we usually make many excuses that are obviously not valid, such as the following:
- Nobody knows how it works, therefore, they will not attack it. (An attacker will spend the time he needs to know how it works…) If no vulnerabilities have been found so far (An attacker will find one or more vulnerabilities with just a glance at it…) Nobody would be interested in attacking our application. (There are millions of bots or automated systems constantly scanning for security deficiencies…) The application is secure because it runs behind a firewall. (Obviously if it has a hardware security element it is more secure, but this fact will never imply that it is secure…) The application is secure because it uses https. (In this case the communication is secure but the development does not have to be…) If it does not run as Administrator / root, you cannot do anything dangerous.(Obviously this is a good security practice, but the fact that the user has low privileges does not indicate that the application is safe…)
Among all the possible excuses for not implementing security in the SDLC, the one that is heard the most is " There is no time to include security ", since most developments are very tight in time and it is more important to put something into production in the appropriate period to include security in each of its parts.
You have to think that "Prevention is better than cure", so it is much more productive and less compromising to prevent or detect an attack for development than to restore the state after a successful attack.
To prevent this from happening, and to develop it safely, there are several security models to be implemented, one of the most recommended that is usually implemented is the Software Assurance Maturity Model (SAMM - Software Assurance Maturity Model) is an open and flexible framework developed by OWASP.
This model serves to help organizations formulate and implement a Security Strategy for Software Development that is appropriate to the specific needs of each organization and has, among others, the following characteristics:
- It consists of several short cycles (achievable goals) and incremental iterations (final goals). Flexible and customizable, based on risk tolerance, criticality of the applications developed and the development methodology… Simple, measurable and well-defined Assurance Activities.
It is designed to help:
- Evaluate the Security Practices in Software Development existing in the organization. Build a balanced Software Assurance Program in well-defined iterations. Demonstrate concrete improvements in the Software Assurance Program. Define and measure Activities related to Software Development Security in the organization.
All these goals are defined according to the structure of the following image in which the different parts that compose it and the interrelation between them can be observed:
Software development
As can be seen in the image, this OpenSAMM methodology establishes:
- 4 Business Functions related to Software Development 3 Security Practices for each Business Function 3 Maturity Levels for each Security Practice 2 Security Activities for each Maturity Level
Therefore, all companies are advised to carry out this structure at a general level always as internal regulations and apply it to all developments that are made in them. Once it is implemented, all security will be carried out autonomously and will fall within the usual continuous processes of the company.
For more information about this model and how it is the best way to implement it in companies, we can see the latest version of it in Spanish at the following web address:
www.opensamm.org/downloads/SAMM-1.0-es_MX.pdf
Fernando Saavedra
Cybersecurity Manager
Áudea Information Security
