You have the idea or customer requirements for the app on paper. You know roughly what it should do, what it should look like and you’ve also chosen the technologies. Now it’s time for analysis. What to start with, how to proceed and what to think about? Among other things, vulnerabilities and threats. If you do such an analysis right at the beginning, you can continuously take care of everything you need during programming, and at the end you won’t be surprised by any insecure holes.

Základom bezpečnej aplikácie je dobrá analýza - Bart Digital Products
Analysis, photo via Unsplash

The process of identifying possible problems and determining the security priorities of a project is called threat modelling. There are a number of possible approaches to looking at these potential holes in a project and each of them has its pros and cons. However, they have the same goal – to ensure that your project is protected. How does it look like in practice?

You model threats even on the way to a shop

People use threat modelling in their daily lives without realizing it. On your way to work or school you’re surely also thinking about what can go wrong along the way and how to avoid it. If you ride a bike, even out of town, you wear a helmet, because we know what our drivers are like. If you’re traveling by car at a busy time, you’re trying to find a route where there’s no traffic, so there’s no big delay or a fender bender with another car in line behind you. In essence, therefore, threat modelling is the identification and classification of threats that are likely to affect our environment.

Such modellings are particularly useful for cyber-physical systems, including the Internet of Things (IoT). Such systems integrate software technologies into physical infrastructures (such as smart cars) and are often more vulnerable to threats than traditional physical infrastructure (a car with minimal electronics is unlikely to be hacked :). Hence, threat modelling can help identify threats even in the development process and ultimately save management a ton of money.



The first methodologies of threat modelling appeared as early as 1977 and were based on the concept of architectural patterns presented by Christopher Alexander in his book “A Pattern Language”. However, Edward Amoros, who described the concept of a “threat tree” in his 1994 book “Fundamentals of Computer Security Technology”, can be considered the father of threat modelling. On its foundations, Bruce Schneier built the study “Toward a Secure System Engineering Methodology” in 1998. The tree methodology, even with the same name as the one given to it by Amoros, is still in use today.

The historically second methodology was developed in 1999 by cybersecurity experts from Microsoft, Loren Kohnfelder and Praerit Garg. It was a model specific to the Microsoft Windows development environment called STRIDE. Again, it’s a methodology that’s still used and popular. In the same year, the Institute of Software Engineering at Carnegie Mellon University introduced a method to evaluate operationally critical threats, assets and vulnerabilities – OCTAVE6.

The first book, Threat Modelling, was published in 2004 by Frank Swiderski and Window Snyder. It developed the idea of using threat modelling to proactively write secure applications. In the same year, Microsoft introduced the Threat Analysis & Modeling (TAM) tool, still in use today, which uses Data-flow diagrams (DFD) and threat trees in the style of the Schneier study. These help development teams think about potential attacks and corresponding security measures to be proactively implemented.

Analysis, photo via Unsplash

4 basic steps

The choice of a specific threat model depends on the goals and environment of your application. However, modelling as such usually involves the same steps:

  1. Identify all the vulnerabilities of your project. Is there a text input for the user? That’s a vulnerability. Logging in? Also a vulnerability.
  2. Create a list of threats based on the vulnerabilities. Text input from the user poses a risk of deploying a foreign code to the app structure, while logging in poses a threat of identity theft. If you want to make it a little easier for yourself, we recommend the threat lists from OWASP.
  3. For each threat, outline steps to prevent it. You only need points – to implement recaptcha, same-origin policy, content security policy…
  4. Prioritize. Which vulnerable spot is likely to be the most bombarded one? Which problem can do the most damage to me? In this way, you’ll know that these threats need to be given extra attention in development.

Specific methodologies are somewhat more complex, some focus on risks, others even assign specific numbers to threats according to their criticality. The most famous and oldest ones, like STRIDE or Threat trees, will be featured in the next blog from the Online Safety series in just a week.