As the developed software may be using in medical information systems, critical infrastructure systems and financial systems, it is essential to develop software securely. Increasing software security vulnerabilities reveals new approaches to developing secure software. In the software development process, security should not be adopted as the last thing to do; security should start as soon as the software development idea is formed and continue until the latest copy of the created software disappears.
If critical operations are performed, and critical data is stored in the use of the developed software, both the rate of cyber attacks on these systems and the capacity of the people who will perform the attack are higher. To give an example to this subject; While the attacker of the application to be used in sectors such as retail, food, and tourism may be a young child who wants to test himself, people who attack applications used in industries such as health, e-government, defense industry, critical infrastructure systems, finance, insurance, logistics, etc. may be cyber terrorists who has high technical skill; so it is vital to protect essential data kept after secure software development and development.
The critical security vulnerabilities that arise today are mostly software-based. The reason for this is that security is not integrated into this process during the software development phase, and security is seen as a product, not a process. This wrong approach causes great financial damages and prestige losses for the company/institution.
Here is some example of software based security breaches or incidents:
OpenSSL HeartBleed Vulnerability: According to the explanations, the vulnerability was caused by a forgotten dimension control in the procedure called HeartBeat in the OpenSSL library. This forgotten lack of dimension control gives up to 64k data that the server or client randomly keeps in their memory to people who are not the real owners of the data due to unauthorized access.
Disclosure of Sensitive İnformation: With this most common security vulnerability, as a result of the developers not properly filtering user inputs, sensitive data such as user databases of many large companies and their customers' credit card information have passed into attackers' hands.
Debian OpenSSL Security Vulnerability: In this vulnerability, the developers removed a few lines of code as unnecessary. However, when this part is removed, the PRNG of OpenSSL ceases to be random and becomes easily produced. A minor software bug has affected millions of servers.
Logic Bomb Attack: America managed to blow up the Siberian gas pipeline by adding a code to its computer system.
Each software has a lifetime. After the end of this life, the new software is offered to the customer/institution with the necessary renewals, and changes in the software, and this process is continuous. Thus, this work must have a severe systematic, and security must be integrated into this routine. This requirement leads to the need for S-SDLC (Secure Software Development Life Cycle).
At this stage, the model defined by ENISA and threat modeling systems is known as STRIDE model come to the fore. Among these systems, STRIDE model is an acronym for the Microsoft-based threat modeling system. Its name comes from the initials of Spoofing, Tampering, Repudiation, Information Disclosure, Denial of service, Elevation of privilege. An example of a threat profile assessment by the model defined by ENISA is given in the figure below.
Choosing the appropriate secure software development maturity model is of paramount importance to guide security issues throughout the development life cycle. Today, studies such as SAMM, BSIMM2, NIST 800-64, CLASP, and Microsoft SDL come to the fore in terms of secure software development maturity models. Especially SAMM (Software Assurance Maturity Model), created by OWASP, is an open-source framework and presents an example model that can be adapted according to the structures and security needs of organizations. With SAMM, you can determine the security level of your current software process and create a roadmap for what you need to do in the future to produce more secure software. SAMM also provides draft documents and tools that can be used for this purpose.
The OWASP ASVS project, which is also an OWASP project, is a project that reveals the status of your application in terms of security. Detailed information about SAMM and ASVS can be found at the following links:
Like SDLC (software development life cycle) processes, we can summarize the S-SDLC (secure software development life cycle) processes under six headings:
Security Training: Employees in a software development team, such as developers, testers, and program managers, should receive appropriate software development security training to remain informed about security fundamentals and the latest security approaches.
Requirement / Risk Analysis: The software development life cycle begins with the requirement phase. This stage aims to determine the software requirements that fulfill the demands of the customer/institution and to reveal them clearly. In short, the type of applications, the method of access, the criticality level of the data they process, etc. are requirements that vary according to the criteria. With the determination of software needs, studies are carried out to determine security requirements. After the decisions are made, the software requirement and security requirements are analyzed together. After the analysis, controls, methods, and tools are determined, and the requirements are documented.
Design and Threat Modeling: In the design phase, interaction points are defined first. These identified points of interaction are of great importance in understanding the software's workflow and provide in-depth information about security issues that may arise. The purpose of security design is to reduce the attacker's working area by minimizing the attack surface.Threat modeling is an essential point in the secure software phase. Secure design modeling provides information about which attacks a software can be exposed to, the category of the person to attack, which critical areas can be attacked, and the weakest point of the software.
Application Development / Source code analysis: It is crucial to write secure code during the Application Development phase. If not done, all efforts will be wasted, and the cost will increase further in the future. The secure code writing stage represents the stage in which the threats in the threat model specified in the design phase and the general security rules are taken into account. Lack of these can lead to security vulnerabilities. Common mistakes (OWASP Top 10) and example descriptions (Webgoat insecure web application) can be examined at this stage.Static code analysis can be used to detect vulnerabilities. The code written by the developers is analyzed with the help of automated tools.
Verification and Test: The application developed by the developer team must be subjected to verification and testing stages before it is published. The security test scenarios that the software is subjected to are designed to defend the software against possible attacks successfully. The software developed is subjected to internal/external penetration and security tests according to its criticality and access levels. The test team reports the detected security vulnerabilities to the developer team, and the development team fixes the vulnerabilities.
Distribution, Monitor and Observation: Vulnerability tracking should continue after the development of the software is completed and distributed to the end-user. Wrong configurations made directly affect application security. Regular penetration tests should be performed for highly critical applications. In case of any problem, an alarm should be generated, and a log review should be possible.
Here are some safe software development best practices for you.
Along with the secure software development process, indispensable requirements for security such as threat modeling, risk analysis, security training and documents, structural analysis, source code analysis, penetration tests are integrated into the software process as a whole. Static code analysis also plays an important role in this process and ensures that the software is analyzed at coding time, and possible errors are detected without running the software. Any errors that will not be noticed during the software's running or will be noticed late can be found by static code analysis. Static code analysis, which can also be done through review, is accelerated today since it is more convenient in terms of time and economic cost with automatic code analysis tools.
In dynamic code analysis, the control process is performed by running the software. The primary purpose of dynamic analysis is to detect errors that may occur during runtime. Software, the performance of the hardware it uses, or the security vulnerabilities that will occur after the input it receives are the best examples of errors that may occur during runtime. Dynamic analysis should be done after the software development process is completed, and the static code analysis is performed because it is possible to solve the findings after dynamic analysis in a more straightforward way after static code analysis.
Today, many automated tools analyze the static and dynamic code. These tools can reduce the security risks that may occur, but cannot provide complete security. Continuous improvement is required in the software.
Open Source Static Code Analysis Tools:
Detailed information can be found here.
Dynamic Code Analysis Tools: