What is Threat Modeling Within the Software Development Lifecycle?

Taking a closer look at building security into the software development lifecycle (SDLC) with integrated threat modeling.
What is Threat Modeling Within the Software Development Lifecycle?

The software development life cycle (SDLC) is a crucial foundation of cybersecurity. Threat modeling forms a pivotal part of identifying and curtailing potential risks threatening an organization’s information and systems. A systematic analysis of possible threats allows organizations to proactively introduce security measures to safeguard their assets.

Building Security in the Software Development Life Cycle

Software is the backbone of every application and threat modeling can help streamline it. Application performance and longevity are 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 SDLC phase.

‍However, the software development life cycle is a complex process, that encompasses multiple 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 risk-centric security from the inception of software development is a cost-effective proactive approach to creating secure software and applications.

‍The process, often referred to as secure software engineering, allows for embedding software security activities during the 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 for threat actors to exploit vulnerabilities, and the organization has the least risk of these being exploited.

Importance of Embedding Threat Modeling into the Software Development Life Cycle

Identifying security issues in software before these issues are exposed in the production environment is an important factor for mitigating the possibility and the impact of 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.

‍At VerSprite, we recognize the role and importance of embedding threat modeling into the software development life cycle phases. Our wealth of experience and industry-leading solutions equip organizations to effectively tackle their security challenges.

Advantages of Embedding Threat Modeling in all SDLC Phases

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

‍The 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. A threat model can reassess potential new threats and security risks, allowing stakeholders to make informed decisions about whether to implement the changes or determine new countermeasures.

Software Development Life Cycle and Attack Resilience

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.

Secure Architecture

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.

Training and Awareness

By following the 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.

Security Assessments and Training

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

Additional Benefits of the Application Threat Modeling Integrated as a part of the Software Development Life Cycle

  • 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 consider.
  • 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 the highest risk values.
  • A threat model helps determine the possible exposure of vulnerabilities which allows for visualization of data flow. The threat model can be used in secure code review to determine whether the issues identified in the software components might be exposed to potential internal or external attack vectors.
  • 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 the Threat Model Framework with Waterfall Software Development Life Cycle

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

Martin Fowler, UML Distilled.

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 the integration of security activities such as threat modeling.

Breakdown of benefits of the threat model by phase:

Requirement phase: At the beginning stage, a 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 helps to identify security requirements to mitigate the risks to the application.

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.

Coding phase: For 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, the threat model derives a suit of security tests that can be executed against the application to identify potential security issues. This way, countermeasures can be redesigned and reimplemented before the application is released into production.

‍A 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 models can reassess potential new threats and security risks, allowing stakeholders to make informed decisions on whether to implement the changes or determine new countermeasures.

Software Threat Modeling and Interactive Software Development Life Cycles

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:

Inception phase: The time and cost of the threat modeling are estimated and incorporated into the scope of the projects, business, and functional requirements.

Elaboration phase: The architecture of the application is defined. 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.

‌‍Construction phase: In this 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.

Transition phase: The application moves from the development environment to production. From a 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 Software Development Life Cycle

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 production. These phases also referred to as “sprints,” are executed more than once at subsequent iterations. Since each sprint represents an 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 before 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 Software Development Life Cycles

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. It aims 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, which include secure architecture, design, 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.