×

Threat Modelling Labs: Now Available on SecureFlag!

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.

Diagram

What is Threat Modelling?

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:

  • Identify security requirements for the application before development begins
  • Pinpoint possible vulnerabilities and threats that could harm the application (and organisation)
  • Quantify the criticality of identified vulnerabilities to inform remediation tactics
  • Plan, prioritise, and implement remediation methods to minimise potential damage

Why Threat Modelling is Vital in the SDLC

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:

  1. Decompose the application to identify its constituent parts, understand how they interact with each other and external entities, and identify possible attacker entry points
  2. Identify the threat agents who could attack the application
  3. Identify existing security controls to reduce the threat level
  4. Quantify risks by analysing their likelihood and potential impact
  5. Implement countermeasures to eliminate or reduce each risk based on priority

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:

  • Detect software vulnerabilities early in the SDLC
  • Spot design flaws that may be overlooked during code reviews
  • Identify new and emerging threats
  • Identify and strengthen at-risk components, e.g., third-party libraries
  • Model malicious attackers’ tactics, techniques, and procedures (TTPs) to shore up defences

Challenges to Threat Modelling

Scalable, cloud-native applications with multiple dependencies on external entities

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.

More Entry Points for Threat Actors

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.

Difficulties in Selecting the Right Threat Modelling Process

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.

Hard to Validate the Threat Model

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.

Too Many Cooks Spoil the Broth

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 Best Practices

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:

  • What are we working on?
  • What can possibly go wrong?
  • What can we do (and are going to do) about it?
  • Did we do a good job?

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:

  • Potential adversaries
  • Adversary motives
  • Threat vectors
  • Type and location of vulnerable components

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 Launches Hands-on Threat Model Training Labs

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:

  • Draw trust boundaries between application entities, understanding where the data changes its level of trust
  • Identify threats for each application entity
  • Incorporate security controls into software design to mitigate the identified threats
  • Think about security considerations right from the beginning of the SDLC

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.

Threat Modeling Lab

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.