Threat Modelling in DevSecOps

Threat modelling is an essential component of DevSecOps that provides insight into the threat landscape and how threat actors could exploit potential vulnerabilities in your organisation. Typically being conducted during the planning or design phases of the Software Development Life Cycle (SDLC), threat modelling provides DevSecOps teams with the information they need to guide security control implementation or make design changes that protect against identified threats. 

Fundamentally, threat modelling helps DevSecOps teams make informed decisions that enable security principles to be embedded effectively across the DevOps lifecycle. When done correctly, threat modelling ensures security controls are not just an afterthought but truly integrated across all phases of the SDLC. 

In this blog, I’ll look at the importance of threat modelling in DevSecOps, different methodologies you can use, and who the key stakeholders are when threat modelling. 

The Importance of Threat Modelling in DevSecOps 

The reason threat modelling is so useful, especially early in the DevSecOps lifecycle, is that it provides you with confidence in your design choices and the knowledge that unknown weaknesses are not being introduced.  

Threat Identification 

DevSecOps is often a fast paced and heavily automated lifecycle; it is easy for threats to be overlooked. Threat modelling focuses on identifying and understanding threats as early as possible, enabling your teams to take appropriate action to protect your applications, infrastructure and wider organisation.  

Without conducting threat modelling early in the DevSecOps lifecycle, weaknesses and vulnerabilities will likely be missed which threat actors can then seek to exploit. This could potentially lead to data breaches, availability issues, or financial loss (as a result of regulatory fines, loss of service, or share price impact). 

Confidence in Design Decisions 

The output of threat modelling enables DevSecOps teams to make informed and confident design decisions. Threat modelling gives them a better understanding of the implications of architectural choices, helping inform their approach to design, deployment and coding practices. 

Deciding between different design options can be difficult without a real understanding of how threat actors could compromise the system that is being designed. Threat modelling bridges this gap and provides knowledge of associated threats, which translates into more informed decision making and providing confidence in the selected approach. 

Calculating Risks 

Understanding the risks associated with any proposed change is important and this is made more achievable and accurate by threat modelling. Although threat modelling doesn’t define risks, it does provide an understanding of threats, which can then be used as a basis to calculate risk using your organisation’s risk assessment approach. 

Risk is a quantifiable measurement of a threat actor exploiting a vulnerability, and threat modelling helps to understand what vulnerabilities threat actors can exploit and how. Identifying these threats is the first step in understanding your organisation’s risks, and is the core of a threat informed, risk lead approach. 

How to Threat Model in DevSecOps 

Phase 

For the output of threat modelling to be effective, it must be available at the very beginning of the DevSecOps lifecycle. As such, threat modelling should be performed in the design or planning phase. This ensures informed decisions are made, which reduces the likelihood of these decisions having an impact on delivery.  

Methodologies 

There are a number of different threat modelling methodologies that you can use, all with different approaches, purposes, and outcomes. I want to discuss two main methodologies which can be used across almost any use case. 

STRIDE 

The first methodology to discuss is STRIDE (Spoofing, Tampering, Repudiation, Denial of service, and Elevation of privilege). STRIDE is a useful approach to threat modelling across the five different domains and helps to provide a strong understanding of the threat landscape.  

STRIDE is focused on data flow and understanding how data moves throughout the environment or design that the threat model is being applied to. Whilst helping to provide substantial insight into various threats, STRIDE takes a relatively short amount of time and is useful in situations where there is minimal resource available for threat modelling. It’s also useful in situations where a small change has occurred which meets the requirements to trigger a threat modelling activity but is unlikely to introduce significant threats. 

PASTA 

PASTA (Process for Attack Simulation and Threat Analysis) is a more detailed threat modelling framework which is more technical and focuses on building an understanding of every element of identified threats. PASTA uses multi-layered modelling techniques - including threat enumeration, attacker profiling, and attack simulation - to help understand an organisation’s true exposure to identified threats and guide them in effective security control implementation. 

PASTA requires much more time and effort to do correctly and is more conducive to a risk output, but overall will give a more detailed view of the identified threats than STRIDE. You may uncover very similar threats using STRIDE and PASTA, but you will understand the threats in far more detail when using PASTA. This additional detail helps with prioritising security control implementation to protect against the identified threats. PASTA is suitable for situtations where a significant change has been made to designs which require a very detailed understanding of the threat landscape and where you have the time to perform an exhaustive threat modelling exercise.  

Stakeholders in Threat Modelling  

Threat modelling is a largely collaborative exercise which leverages the expertise of different roles and stakeholders across the SDLC to contribute to the identification of threats. This helps provide differing perspectives and skillsets which results in more effective and comprehensive threat identification. Below is a list of different roles and their responsibilities. 

Security Experts 

These roles bring deep expertise in identifying and mitigating security risks, ensuring your chosen threat model addresses realistic attack vectors. They understand the wider picture and can bring that to the table, helping you align with best practice and any regulatory requirements. These roles will ultimately guide the calculation of risks following threat identification, so it is a priority to have them involved at this stage. 

Designs secure systems and identifies architectural weaknesses in their day-to-day role. They will be pivotal to defining controls to mitigate threats.  

Works to stop threats from exploiting vulnerabilities. They will be perfect to evaluate threats and vulnerabilities based on the model. 

Developers and Engineers 

Developers and engineers can ensure that technical details, such as APIs, integrations, and configurations, are accurately represented in the threat model. 

Understands how code interacts with system components and can pinpoint areas of concern. 

Provides insights into system configurations setup to things like networks or virtualisation. 

Product and Business Stakeholders 

These roles understand what the product needs to achieve for the business and can ensure threats that could impact business operations or user trust are identified and prioritised. 

Ensures the threat modelling aligns with the project’s objectives, user requirements and business objectives. 

Identifies potential risks from a business impact perspective and will have a finger on the pulse of business requirements and vision.  

Operations Teams 

Their operational experience helps identify threats related to system maintenance and incident handling. 

Understand deployment, monitoring, and maintenance processes. The current infrastructure pipeline and how it all gets deployed.  

Provide insights from all of their experience of past incidents and potential attack scenarios. 

When threat modelling, you will ideally bring together some representation from each of these roles to ensure the most rounded and comprehensive output.