To prevent threats from morphing into serious attacks, it’s crucial to “bake in” security into software from the beginning of the software development lifecycle (SDLC). Early identification and mitigation of application security risks are essential to make the application more secure. Here’s where threat modelling comes in.
OWASP describes threat modelling as a way to “identify, communicate, and understand threats and mitigations” to software applications. It provides a systematic and structured way to find threats early and minimise the possible damage they may cause if realised.
It is a proactive process to:
Threat modelling provides a structured approach to map potential threat scenarios and identify application weaknesses before a threat actor can exploit them. Thus, it enables organisations to adopt a security by design approach in the SDLC, which is a complete departure from the traditional security as an afterthought approach.
Along the way, they will follow a systematic process that consists of these fundamental steps:
One of the primary goals of threat modelling is to “think like a hacker”; viewing our technological stack through this lens can allow us to identify where our application is at risk and then implement measures to mitigate or eliminate such risk accordingly.
Threat modelling is one of the most critical steps in secure application design and development because it helps organisations to:
Modern applications are overwhelmingly cloud-native, microservice-based, and scalable. It’s not always easy to understand their external dependencies or gain complete visibility into the entire application ecosystem. Consequently, teams struggle to incorporate these expanded topologies and scope changes into the threat model, which makes it harder to identify and mitigate risks.
Modern applications are more exposed to the Internet, which creates more entry points for adversaries. Consequently, threat modellers need help to create Flow Diagrams (DFDs) and Process Flow Diagrams (PFDs) to model threats and implement appropriate countermeasures.
Since many threat modelling tools and processes are available, selecting the right tool and process can be challenging. This selection is a particularly serious problem for small teams that lack security and threat modelling specialists.
Threat modelling is about more than just creating the threat model; it’s also essential to implement appropriate remediation strategies. Unfortunately, this is where many teams fall short, with many identified threats remaining open to exploitation by attackers due to inadequate or non-existent remediation.
While it’s usually helpful to incorporate the inputs of multiple stakeholders during a threat modelling process (see next section), this practice can also harm the organisation. Such a “group exercise” means that no single person possesses the required knowledge about the entire application, diluting the threat modelling process. To avoid this issue, someone must gather information from all stakeholders and ensure that everyone involved in app design, development, or testing is always on the same page.
Threat modelling is usually done during the planning and design stages to ensure that the application is secure by design. However, applying it continuously throughout the SDLC and refining it at each phase is advisable. This way, developers can find vulnerabilities as they arise and fix them before they become substantial security risks later. It also helps to prevent costly and time-consuming reworking later in the SDLC, which could delay production and time-to-market.
Another good practice is to adopt the 4-question framework originally conceived by Adam Shostack in his book “Threat Modelling: Designing for Security” and recommended by OWASP:
Focusing on these questions makes the threat modelling process more efficient and allows teams to concentrate on finding and mitigating the most severe threats.
The most effective threat models incorporate inputs from multiple stakeholders. It’s useful to ask anyone involved in design, development, or deployment for inputs about the following:
Also consider adopting a widely-accepted threat modelling methodology, like STRIDE, PASTA, TRIKE, or OCTAVE.
Finally, organisations can benefit by providing hands-on threat modelling training to their dev teams. And for this, a platform like SecureFlag is ideal.
SecureFlag is the world’s first-ever platform providing hands-on threat modelling training. Learners have now access to a new series of virtual labs to learn how to:
The goal of this hands-on approach is to get developers thinking about security from Day 1 and keep security in mind as the application gets closer to release.
In the modern digital economy, threat actors are everywhere, but threat modelling is an effective way to protect software assets. The best way to leverage threat modelling is to train developers on appropriate methodologies, dependencies, vulnerabilities, etc.
However, old-fashioned classroom training is insufficient to improve their ability to address these modern threats. In the SecureFlag platform, all labs run in real, virtualised development environments, so users can learn how to identify and remediate threats by doing instead of simply seeing.
Today’s teams need hands-on training and practice, which is precisely what the SecureFlag platform provides through its newly released hands-on threat modelling labs. For more information about SecureFlag’s training offering contact us.