Threat Modeling Within Software Development Lifecycle

< Back to Blog Home

Building security in the SDLC – a time and cost-efficient security solution beyond a simple application validation requirement

Software is the backbone of every application. Application performance and longevity is dependent on how well software is built, as well as how secure it is. Historically, security in the software has been mostly considered a requirement to be validated with functional testing during the last phase of the SDLC. However, the software development lifecycle is a complex process, that encompasses different phases such as software functional requirements, software design, coding, building the software to an executable, integration with other software libraries, and building to create an executable, functional, quality testing.

Implementation of fixes for the issues identified at the final stage of testing requires time and resources. Building in risk-centric security from the inception of the software is a cost-effective proactive approach to creating secure software and application.

The process, often referred to as secure software engineering, allows for embedding software security activities during the different phases of the software development lifecycle, such as requirements documentation, architecture design, coding integration with other libraries, and building the execution and testing. Implementing secure activities throughout the SDLC builds a more secure software foundation and makes sure that cybersecurity culture is woven into the development process. It also allows you to identify and rate vulnerabilities according to their technical risks and remediate them accordingly in the process. It eliminates issues with backtracking to implement fixes, failing testing, and not meeting requirements.

Proactively securing the application in the SDLC is an offensive approach to security, which presents fewer opportunities to threat actors to exploit vulnerabilities, and the organization has the least risk of these being exploited.

 Importance of embedding threat modeling into SDLC

Identifying security issues in software prior to these issues being exposed into the production environment is an important factor for mitigating the possibility and the impact of the cybercriminals targeting these vulnerabilities.

Steps to secure an application with threat modeling (PASTA):

1. Identify the potential threats and threat actors to the application.
2. Identify the functions of the application and its objectives.
3. Analyze the assets that can be targeted by cybercriminals
4. Determine the type of attacks and attack vectors that can be used and the type of vulnerabilities that can be exploited by these vectors
5. Set the security measures that can be put in place to mitigate the risks

The main goal of embedding threat modeling is to identify potential risks as early as possible, so that they can be managed by designing, implementing, and testing countermeasures throughout the SDLC.

Advantages of Embedding Threat Modeling in all the Phases of the SDLC are:

1. Risk management. It allows risks to be managed proactively from the early stages of SDLC.
2. Security requirements. Deriving the security requirements to mitigate potential risks of vulnerability exploits and targeted attacks against application components.
3. Secure design. Ability to identify security design flaws, their exposure to threat actors and attacks, and prioritize fixing them by issuing new design documentation prior to the next phase of the SDLC.
4. Security issue prioritization. Determining the risk exposure and impact of threats targeting issues identified during secure code reviews and prioritizing them for mitigation.
5. Security testing. Deriving security tests from use and abuse cases of the application for testing of the effectiveness of security measures in mitigating threats and attacks targeting the application.
6. Secure release of applications after development. Allowing business to make informed risk decisions prior to releasing the application based on the mitigation of high-risk vulnerabilities and assertion of testing countermeasures that mitigate specific threats.
7. Secure release of application after an incident. Determining and identifying additional countermeasures that can be deployed.

Designing for security and for attack resilience: secure architecture, training and awareness, security assessments and testing

Threat modeling within the SDLC builds attack resilience. It helps identify potential threats and attack vectors that can be used against the security controls, which allows to proactively design countermeasures to protect them.

At the architectural level, a threat modeling exercise can include the threat analysis of these threats and attack vectors as well as the analysis of the architectural components that can be attacked, such as user interfaces, databases, and server components, which include web and application servers and the data flows between them.

By following step-by-step application threat modeling methodology (PASTA), it is possible to analyze the exposure of application components to different threats and determine the type of measures that can be deployed at different architecture levels to mitigate such threats.

The assessment of the secure architecture of an application also represents an opportunity to design applications that are complaint with the organization’s infosec requirements to protect sensitive data in storage and in transit, as well as implementing necessary access controls. It also ensures government regulations compliance.

Additional benefits of the application threat modeling integrated as a part of SDLC:

1. Threat modeling bridges a gap between information security and engineering teams. It gives an opportunity to educate engineering teams about application security standards, security architecture, and vulnerabilities, as well as security risks and countermeasures to take into account.
2. Threat modeling is used to communicate technical risks to application development stakeholders, so they can make informed risk management decisions and prioritize mitigation efforts toward the vulnerabilities with a highest risk values.
3. Threat model helps determine the possible exposure of vulnerabilities which allows for visualization of data flow. Threat model can be used in secure code review to determine whether the issues identified in the software components might be exposed to the potential internal or external attack vectors.
4. Security testing also benefits from threat modeling embedded into the SDLC. For example, penetration testing runs a suite of common attack vectors against the application. Performed during the development lifecycle, it can identify exploitable design flaws in time to prevent costly repair and time loss, as well as ensure proper security controls are implemented.

Integrating Threat Modeling within the Different Types of SDLCs

“When to use iterative development? Only on projects you want to succeed.”

Martin Fowler, UML Distilled.

Here we take a closer look at the implementation and benefits of the threat modeling in different types of Software Development Lifecycle: waterfall, interactive, agile, and security enhanced.

Threat Modeling and Waterfall SDLC

Software can be developed using different types of SDLCs. Waterfall SDLC is a traditional linear software engineering process that follows each of the phases sequentially, starting from the initial requirements phase, following through the design phase, the coding phase, and the final testing phase.

This type of software development is one of the best suited for integration of security activities such as threat modeling.

Breakdown of benefits of the threat modeling by phase:

• Requirement phase. At the beginning stage, threat model identifies threats against the functional use cases of the application by considering a threat agent, such as an attacker trying to abuse the application functionality. It then derives a set of abuse cases that map to each of the use cases with an abuse functionality. This help to identify security requirements to mitigate the risks to the application.
• During the design phase, threat modeling identifies specific threats against the components of the architecture, such as the user interfaces, the data processes, the data flows, and the data in storage. At this stage, threat modeling reveals security gaps in the design of the security controls, as well as design weaknesses.
• In the coding phase of the software development threat modeling determines the risk of the security issues identified in the source code after either a manual source code analysis or an automatic source code static test for vulnerabilities.
• Testing phase prior to production. Threat model derives a suit of security tests that can be executed against the application to identify the potential security issues. This way, countermeasures can be redesigned and reimplemented before the application is released into production.

Threat model, embedded into the SDLC, is also beneficial after the application is deployed in the operational environment, as it helps to maintain security during subsequent releases and before change management events. Threat model can reassess potential new threats and security risks, allowing stakeholders to make informed decisions whether to implement the changes or determine new countermeasures.

Threat Modeling and Interactive SDLCs.

An example of an interactive SDLC is the Rational Unified Process (RUP). RUP is an extensible software development process that consists of four sequential phases (inception, elaboration, construction, and transition) and disciplines that are used throughout the phases (requirements, analysis and design, implementation, testing, deployment, configuration, and change management). RUP differs from a waterfall process in that each phase encompasses several iterations of a complete development cycle.

Security objectives, included in each phase of RUP through threat modeling, can be validated at each RUP milestone and used as a security checkpoint during the iterative development of the application.

Threat modeling within Interactive SDLD by phase:

• In the inception phase, time and cost of the threat modeling is estimated and incorporated into the scope of the projects, business and functional requirements.
• Architecture of the application is defined during the elaboration phase. This is where the bulk of the requirements is elaborated and threat modeling helps provide security requirements, based on the abuse cases. Through threat modeling exercises the security controls are also validated and designed to mitigate the risks of specific threats.
• During the construction phase of the RUP SDLC the application software is developed. Here, the source code is reviewed for any vulnerabilities, using the results of threat modeling exercises, such as the identification of security design flaws in the application architecture.
• The application moves from the development environment to production during the transition phase. From security perspective, the focus of this phase is to validate with security tests that the security controls of the application function as required and are acceptable for deployment as well as that the application does not include any known high-risk security issues that prevent release into the production environment.

Threat Modeling and the Agile SDLC

With the Agile software development methodology, applications are developed by refining the application requirements, design, implementation, and testing phases through different iterations until the final application is ready to be released into the production. These phases, also referred to as “sprints,” are executed more than once at subsequent iterations. Since each sprint represents incomplete design, it poses challenges to the threat modeling as it lacks security checkpoint enforcement and does not have a complete scope for assessment.

Due to these constraints, integrating threat modeling into the Agile SDLC may not be as effective as secure architecture design reviews integrated as a part of the Waterfall SDLC to identify security flaws in the design before starting implementation.

Nonetheless, certain threat modeling activities can be integrated into the Agile SDLC:

• Agile stories, actionable statements describing a piece of business functionality, can be integrated with a threat modeling activity to identify threat scenarios and derive security stories. They will in turn define the security conditions for validation with security tests. The validation of security stories can be a part of the system integration tests as a part of the final application security acceptance review before releasing the application in production.
• The security stories introduced ahead of each sprint can drive the documentation of the security requirements as well as secure design prior to each sprint.
• Application security assurance review, performed between system testing and the release phases, provides an opportunity to drive threat analysis to make sure there are no vulnerabilities that can be exploited by known threats identified at the initial threat modeling.
• Security tests can be integrated with the system tests to validate that the software functions as intended and is free of vulnerabilities.

Threat Modeling and Security Enhanced SDLCs

Security Enhanced SDLC is a software development process that incorporates security activities to enhance the security of the application by design, development, and deployment.

Microsoft Software Development Lifecycle (MS SDL) is one of the examples of the security enhanced SDLC. Its aim is to minimize the security-related vulnerabilities in the design, code, and documentation and to detect and eliminate vulnerabilities as early as possible in the development lifecycle.

MS SDL incorporates threat modeling and mitigation as some of the Secure by Design guiding principles, that include Secure architecture, design, and structure, Elimination of vulnerabilities, and Improvements in security.

Software security is complex and paramount to the continuity of the application and, at times, business. Threat actors always look to exploit weaknesses found within the structure of the software. Vulnerabilities that were introduced in the development stages can undermine entire business operations. Security must have a multifaceted approach that goes beyond mitigating risks discovered after production, or worse – having cybercriminals discover them. Introducing threat modeling at early stages of software development is not simply an offensive cybersecurity approach that effectively saves time and resources, it helps build stronger application foundation which work for business continuity.

To learn more about integrating threat modeling (and PASTA methodology) as a part of your business plan, contact us.