This blog post is also available in German: https://blog.exxeta.com/2019/08/19/so-sorgen-sie-fuer-mehr-sicherheit-im-software-development-lifecycle/
SDLC stands for Software Development Lifecycle. An SDLC is essentially a series of steps or phases that provide a framework for developing software and managing it throughout its lifecycle. Although there is no specific technique or a single way to develop applications and software components, there are established methods used by enterprises and there are models available to manage different challenges and goals. These methods and models are typically based on a standard, such as ISO/IEC 12207, which lays down guidelines for the development, sourcing and configuration of software systems.
To develop a high-quality software product that meets the needs of the customer or end user, companies must choose the Software Development Life Cycle that is best for them. There are different SDLC’s. The choice of SDLC varies from company to company. Each company has its own procedures and policies, which also differ in terms of requirements and infrastructure. A software development process describes a theoretical and conceptual representation of software development. Software development is a progress through a number of different phases such as requirements analysis, design specification, programming, testing and maintenance. With the help of development processes, companies can efficiently divide the work, assign different activities to the software development team, estimate budgets and deadlines or the time period. To be competitive on the global market, companies and organizations have practiced and implemented various software development processes such as waterfall, spiral model, rapid prototyping, agility and others over the past four decades. (JAGLI & Yeddu, 2017)
A secure SDLC is essential for organizations in all industries. Weak or no security practices result in insecure and vulnerable code. By integrating activities that describe security practices, the architecture can be improved. Synonymous with Secure SDLC the secure software lifecycle is also known as S-SDLC. And there is also the well-known Secure Development Lifecycle (SDL) framework from Microsoft, to which we also refer.
A stronger focus on application security makes economic sense. This does not only affect the high IT security incident costs, but also helps to increase the enterprise value. It is well known that the late elimination of vulnerabilities in SDLC leads to higher IT expenses and opportunity costs.
Several SDLC challenges have been observed by different companies. Some of these observations are:
- – According to a Microsoft security report, about 10% of the vulnerabilities revealed by October 2016 were operating system (OS), the other 90% application level.
- – The IBM Internet Security System’s X-Force 2016 report found that only 11% of all vulnerabilities revealed in 2008 were among the top five software vendors (Microsoft, Oracle, IBM, Apple and Cisco).
- – The National Institute of Standards & Technology (NIST) estimates that code fixes performed after release cost 30 times more than code fixes performed during the design phase.
- – NIST estimates that 92% of all security incidents are due to software issues.
- – A Research from Cigitial shows that application security vulnerabilities are almost evenly distributed between coding errors and design errors.
These results show the extent to which the application layer is affected by attacks.
A solid SDLC strategy provides high-quality software, fewer vulnerabilities, and better time and resources. A strategy helps develop and maintain software. Tools enable the integration of automated security testing into the SDLC process.
In the literature there are different classifications of the phases of the SDLC. These different classifications range from four fairly general phases to the six phases shown in figure 1. This is because phases four and five are often summarized as “test and maintenance”. A division into seven phases is possible as well. Since the software lifecycle is regarded as a complete endless loop, the activities after deployment, i.e. during operation, also make sense for a complete picture. In this chart, the sixth phase “Operation and Maintenance” for the Secure SDLC has been added in order to understand the security measures that occur after deployment and to convey a holistic picture of the Secure SDLC.
A major difference that distinguishes Secure SDLC from the traditional development process is that tests take place continuously and automatically throughout the SDLC.
The OpenSAMM project can be used to develop an integrated security strategy. The OWASP Software Assurance Maturity Model (SAMM) supports the entire software lifecycle, including development and procurement, and is technology and process independent. It is deliberately designed to be developable and risk oriented (Deleersnyder, Win, & Glas, 2017, p. 2). SAMM defines the individual security measures on the basis of the company functions and can therefore be used right from the start in the planning phase to set up the process for continuous improvement of security across all phases (Tatlı, 2012, p. 805).
Figure 2 illustrates the company functions according to SAMM and the respective security measures. The four business functions (Governance, Construction, Verification and Operations) are at the highest level. In each business function, certain security measures are to be implemented in order to achieve a certain security level in this business function. There are three security practices under each business function. (Tatlı, 2012, p. 805)
Phases of the Secure SDLC
This chapter focuses on the phases of the Secure Development Lifecycle. In the following subchapters, the individual phases are explained and the measures for integrating security are explained.
Phase 1: Requirement Analysis
The first step is to map a planning process. During this phase, a company must identify the release topic, content, and timeline. This typically includes activities such as collecting end user requirements, determining user stories to be included in the release, and planning release phases.
Key aspects in this phase include ensuring that an application meets business requirements.
Defining Security & Privacy Requirements
The need to take security and privacy into account is a fundamental aspect in the development of secure applications and systems. Regardless of the development methodology used, security requirements must be continuously updated to reflect changes in required functionality and the threat landscape. The optimal time to define security requirements is, of course, at the initial design and planning stage, as development teams can integrate security to minimize disruptions. Factors that affect security requirements include regulatory and industry specific requirements, standards such as encryption procedures, historical incident auditing, and known threats. (Microsoft, 2019b)
Phase 2: Design
In contrast to the “Security by Design” principle, security is often neglected in the development of applications. According to Gartner, up to 50% of vulnerabilities can be avoided during the design phase (Stackpole & Oksendahl, 2010, p. 199).
During the design phase, the architecture and design of the solution are checked using threat modeling techniques. Threat actors and possible threat scenarios should be listed for each of the components. For example, a threat scenario could be a potential data integrity problem because there are no authentication controls on the device. After listing the threats, countermeasures can be evaluated and recommended.
The key aspects at this phase include:
- – The commitment to threat modeling and security design
- – Choice of programming languages, frameworks, and libraries to use in the development process
Threat modeling is a process by which potential threats can be identified, enumerated and prioritized from the perspective of a hypothetical attacker. Microsoft offers the Microsoft Threat Modeling Tool as a free tool.
The Threat Modeling Tool is a core element in the Microsoft Security Development Lifecycle (SDL). It enables software architects to identify and mitigate potential security vulnerabilities early on if they can be resolved relatively easily and cost-effectively. (Microsoft, 2019a)
Security Design Review (SDR)
An SDR is a detailed analysis of the most important systems with a focus on the overall system security. This includes, for example, following best practices. For example, if authentication procedures are implemented using standards such as OAuth and protection mechanisms such as 2-factor are supported, and if technical protection mechanisms such as OWASP Proactive Controls are integrated into the application architecture right from the start, fewer errors occur during the development phase (Stackpole & Oksendahl, 2010, p. 199).
Phase 3: Development
This phase comprises the actual development and creation of the application – while at the same time fulfilling all the requirements defined in the planning phase.
The key aspects in this phase include:
- – Training developers in secure programming
- – Finding and fixing errors and security vulnerabilities in the code during writing
- – Using the open source components in a secure way
Static code analysis (SAST)
An important security measure is static code analysis. The aim is to analyze the source code for unsafe methods, such as obsolete hashing algorithms or non-verified user input. Among other things, pattern matching can be used to detect vulnerabilities in the source code. There are numerous tools that perform static code analysis, even fully automated in the CI/CD build process. Already in the development environment (IDE), static code analysis tools such as .NET Security Code Scan can support.
In a code review, a program section is proofread after or during development by one (peer review) or more (multi-eye principle) reviewers in order to find possible errors, simplifications or test cases. Code reviews are an established and adequate means of software development. The aim of this security measure is to check compliance with Secure Coding Guidelines , which are taught through Secure Coding training courses. OWASP offers the OWASP Secure Coding Practices and the OWASP Code Review Project as useful tools.
Phase 4: Testing
During this phase, the team tests the code against the requirements to ensure that the product meets them and works as expected. The fourth phase involves performing all types of performance, quality assurance, and functional tests, as well as non-functional tests such as user experience tests. While testing traditionally took place after the development phase, best practice organizations are moving to continuous automated testing throughout the SDLC.
Key aspects in this phase include:
- – Testing the application against security policies using various testing methods, including static, dynamic, software composition analysis and manual penetration testing
- – Perform a comprehensive range of performance, functional, unitand integration tests using the same language and protocols of the systems under test
- – Adding security tests as part of the final quality checks
Security Test Cases
Security test cases include the testing of certain test cases that would also be used by an attacker. The OWASP Testing Guide and the OWASP Cheat Sheets provide helpful material for this. This allows frequent attacks to be tried out and processed using a checklist. The Cheat Sheets are great reference books when you’re about to implement a task. The secure way can be looked up depending on the framework and language used. An exemplary test case from the Testing Guide would be the vulnerability “Error Handling: Disclosure of sensitive information”. This vulnerability occurs when errors are provoked in the application. A further test case is the spying out of used libraries (also known as footprinting/banner grabbing) and the investigation based on this for already reported CVE (Common Vulnerabilities and Exposures) entries.
Dynamic analyses (DAST)
Vulnerability scanning tools and fuzzing attacks can be used to automatically attack the application from outside. Vulnerability scanners like OWASP ZAP and w3af can attack the running application. These scanners use different attack vectors (fuzzing) and enter them as user inputs, which are processed by the application. Using scanning tools such as the OWASP ZAP API, dynamic analyses can be automatically integrated into the development process.
Phase 5: Deployment
In the release phase, a team uses the software on production servers. This includes bundling, managing and deploying multiple complex releases across multiple environments, including private data centers and clouds, as well as public cloud resources.
Key aspects in this phase include:
- – Monitoring the progress of a release and its components
- – Moving away from manual approval processes to an automated process where software approval is based on a business decision
- – Creating security tests as part of the final quality checks
Final Security Review (FSR)
As the product approaches completion, an important question needs to be answered: Is the product ready for use from a security and privacy perspective? The aim of the Final Security Review (FSR) is to answer this question. The FSR is performed by the central security team and is a critical part of the SDLC. A helpful tool is an independent penetration test, which can be performed by an external service provider.
Application Security & Monitoring Response Plan
Part of this security measure is the creation of an Incident Response Plan (IRP) and the implementation of an Incident Response and Management System (IRMS). An IRP is a set of instructions that helps the IT team identify, respond to and resolve security incidents. The company’s information, and therefore its reputation, can be contained by an infrastructure for which an incident response is developed and implemented. This can be done, for example, through plans, defined roles, training, communication to quickly detect an attack and effectively mitigate the damage. Thus, the presence of the attacker can be eliminated, and the integrity of the network and systems restored. An IRMS can be implemented in conjunction with risk management.
Phase 6: Operations and Maintenance
During this phase, a product is in production and is used by customers. Monitoring the performance and user experience of the application is essential for continuous improvement. A company ensures that operational data is made available to developers and testers.
Key aspects in this phase include:
- – The ongoing review and monitoring of applications in production
- – Re-evaluating applications for performance, security and usability as they are updated or changed
Incident Forensics includes step-by-step tracing of an attacker’s actions and forensic analysis of possible security breaches. In the case of a cyber-attack, it is a matter of securing and preparing evidence that can be used in court. In case of an incident, uncompromised log files help to pick up the attacker.
Security monitoring is about identifying potential threats before they occur. This involves collecting event data from different operational levels and analyzing it in real time. The OWASP AppSensor can be integrated at the application level. This defense mechanism is called Runtime Application Self-Protection (RASP). RASP is a security software that is integrated into the application or linked to the environment. This enables attacks at the application level to be detected and directly blocked. Since RASP runs at the application level, the monitoring system has insight into the processes within the application. The application behavior can be analyzed precisely. This makes it possible to react in real time.
Deleersnyder, S., Win, B. D., & Glas, B. (2017). SOFTWARE ASSURANCE MATURITY MODEL. A GUIDE TO BUILDING SECURITY INTO SOFTWARE DEVELOPMENT, OWASP Foundation. Retrieved from https://github.com/OWASP/samm/raw/master/Supporting Resources/v1.5/Final/SAMM_How_To_V1-5_FINAL.pdf
JAGLI, D., & Yeddu, S. (2017). CloudSDLC: Cloud Software Development Life Cycle. International Journal of Computer Applications, 168, 6–10. https://doi.org/10.5120/ijca2017914468
Kesäniemi, A. (2009). Code Analysis. Automatic vs Manual, OWASP Foundation. Retrieved from https://www.owasp.org/images/5/53/Ari_kesaniemi_nixu_manual-vs-automatic-analysis.pdf
Lobačevski, J., & Arteau, P. (2019). Security Code Scan. Security static code analyzers for .NET. Retrieved from https://security-codescan.github.io
Microsoft. (2019a). Microsoft Threat Modeling Tool. Retrieved from https://docs.microsoft.com/de-de/azure/security/azure-security-threat-modeling-tool
Microsoft. (2019b). What are the Microsoft SDL practices? Retrieved from https://www.microsoft.com/en-us/securityengineering/sdl/practices
Stackpole, B., & Oksendahl, E. (2010). Security Strategy: From Requirements to Reality. CRC Press. Retrieved from https://books.google.de/books?id=ziGJGMhryA0C
Subramanian, S., & M., B. S. (2017). Security Assurance in the SDLC for the Internet of Things. Secure SDLC Steps to Address Common Coding Flaws and Software Vulnerabilities. Retrieved from https://www.isaca.org/Journal/archives/2017/Volume-3/Pages/security-assurance-in-the-sdlc-for-the-internet-of-things.aspx
Tatlı, E. İ. (2012). OWASP Anleitungen und Tools für Secure SDLC. Datenschutz und Datensicherheit – DuD, 36(11), 805–809. https://doi.org/10.1007/s11623-012-0276-2
Javan works as an IT security consultant specializing in application-level pentesting. He lectures Secure Coding at the DHBW Karlsruhe and studies M.Sc. IT Security Management at the Aalen University.Show all posts by Javan Rasokat