Secure Software Development: SSDLC in Software Development

Secure Software Development: SSDLC in Software Development

As the developed software may be used 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 secure 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.


Recently Experienced Software Based Security Incidents

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 Information: 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.


Integrating Security into Secure Software Development Process

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.

enisa threat profile

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 security software development 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 secure software development lifecycle 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:


S-SDLC (Secure - Software Development Life Cycle) Processes

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.


21 Secure SDLC Best Practices

best practices for secure development

Here are some safe software development best practices for you.

  1. The application to be developed should store the user passwords to be used in the authentication step by hashing.
  2. Access to data deleted from the application to be developed should be prevented.
  3. The application to be developed should prevent access to its pages or services that are closed to anonymous access without authentication.
  4. The application to be developed should include a 2-factor or 3-factor authentication mechanism to guarantee the user's data.
  5. The application to be developed should include the use of captcha against brute force attacks. After the number of failed attempts exceeds a specific value, the account must be locked, and there must be a separate security mechanism to activate it again.
  6. The application to be developed should be designed in a consistent and less informational manner so that the attacker cannot extract information from the error messages during the authentication phase.
  7. The application to be developed should be designed to include a strong password policy when determining the password for the users.
  8. The application to be developed should be designed in such a way that the httponly and secure parameters are active for the cookies released by the application.
  9. The application to be developed must generate the SessionID value with a randomness that is not easy to predict and must be complex.
  10. The application to be developed should be designed to expire for users who do not operate for a certain period of time.
  11. The application to be developed should be designed in such a way that the user can only access information that he/she needs to know and prevent access to the information of other users.
  12. In the application to be developed, the controls on the client-side should be minimized; if possible, all controls should be made on the server-side.
  13. In the application to be developed, it is recommended that authorization be role-based.
  14. The application to be developed should contain identity management screens that contain admin or user with admin authority, and external access to these screens should be prevented.
  15. The application to be developed should include the function of making the registration of this user passive when any user leaves the job.
  16. Development, testing, training, and live environments should be isolated from each other, and the databases of these environments should not be used together.
  17. The application to be developed should use version control systems to provide backup and versioning.
  18. The application to be developed should make the log structure in real-time and should be documented regularly in case of any security breach.
  19. The application to be developed should not allow any injection by filtering data entries against harmful injections that can be tried by attackers. It is recommended to apply a whitelist approach instead of a blacklist during data filtering.
  20. In the application to be developed, it is recommended to use CSRF-token to prevent cross-site request forgery.
  21. If the application to be developed will include 3rd party libraries, the latest versions of these libraries that do not contain vulnerabilities should be used, and their updates should be made regularly.


Static and Dynamic Code Analysis

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:

  • FxCop, Gendarme, StyleCop (.net), CodeCrawler (C#)
  • CheckStyle, Findbugs, Hammurapi, PMD (Java)
  • NodejsScan (NodeJs), JsHint (Javascript)
  • Rips (Php)
  • YASCA (.Net, Java, C/C++, HTML, JavaScript, ASP, ColdFusion, PHP, COBOL)
  • Visual Code Grepper (C++, C#, VB, PHP, Java and PL/SQL)
  • Graudit (Sadece Linux) (ASP, JSP, Perl, PHP, Python)
  • Code Warrior (Sadece Linux) (C, C#, PHP, Java, Ruby, ASP, JavaScript)
  • Awesome-static-analysis Supports many languages.)
  • Bandit (Python)
  • FlawFinder (C/C++)

Detailed information can be found here.


Dynamic Code Analysis Tools:

  • Nmap (Can be used to scan the network.)
  • Wireshark (Can be used to listen to the network.)
  • OpenVAS (Can be used to scan for network vulnerabilities.)
  • OpenSCAP (Can be used to scan computer-based vulnerabilities.)
  • OWASP Zap, Nikto, Vega (Can be used to scan for vulnerabilities for applications.)
  • Sqlmap, Scuba (Can be used to scan databases for vulnerabilities.)