In the last blog, we wrote about modeling and why it’s used by all tech giants. But do you need it, too? According to a study conducted at the University of Maryland, a hacker attack occurs every 39 seconds, with almost half of the cyber attacks targeting small businesses. So if you’re currently developing a small calorie tracking app for your friend or an e-shop with a few products for a client, the answer is yes.

But the question remains – should we model when we have penetration tests, static and dynamic code analysis, automated tests and a lot of other tools that should ensure that the project is bulletproof? Even here, the experts nod their heads. Why? Because it’s so much easier to fix something before you finish it than the other way around. It’s therefore worth investing time in quality analysis. And to make sure you don’t forget anything, we’re discussing the most famous threat modelling methodologies for you to use.


The name is a mnemotechnical aid representing the threat naming system:

  • Spoofing: Can an attacker gain access using a false identity?
  • Tampering: Can an attacker edit data that passes through the application?
  • Repudiation: If an attacker denies having done anything, can you prove otherwise?
  • Information disclosure: Can an attacker access private or potentially harmful data?
  • Denial of service: Can an attacker cause a failure or limit the availability of an app or a web?
  • Elevation of privilege: Can an attacker assume the identity of a privileged user?

It’s currently the most advanced method for modelling threats. It’s used for purely cyber and cyber-physical systems.




Process for Attack Simulation and Threat Analysis (PASTA) is a risk-based threat modelling method developed in 2012. It aims to combine business objectives and technical requirements. It’s a sequence of steps:

  1. Definition of objectives
  • Business objectives and security requirements (GDPR, etc.)
  • Business Impact Analysis (BIA) – identification and evaluation of potential business problems due to complications (natural disasters, exit of a supplier or of investors, but also a hacker attack)
  1. Definition of the technical scope
  • Limitations of the technical environment, infrastructure dependence, applications and software
  1. “Dissecting” the application
  • Identification of use cases, definition of application entry points and access levels
  • Creating a Data Flow Diagram (DFD)
  1. Threat analysis
  • Analysis of the probability of attack scenarios (how often can I expect attacks?)
  • Regression analysis of security incidents (how do attacks occur?)
  • Correlation and intelligence threat analytics (how sophisticated are these attacks and what can they do to my application?)
  1. Vulnerability analysis
  • Threat mapping for existing vulnerabilities using threat trees
  • Ranking threats from the most critical to the least critical
  1. Attack modelling
  • Modelling of attacks on development environment, libraries, frontend inputs, etc.
  1. Analysis of risks and impacts
  • Quantification of the commercial impact of possible attacks
  • Identification of countermeasures and risk analysis, strategy to mitigate it

This method “elevates” the threat modelling process to a more strategic level, as it also includes the business side and calculates possible losses resulting from security breaches. At the same time, the application is looked at from the attacker’s point of view as well (attack modelling) and offers, among others, a very useful output – a list of threats ranked by their criticality that will help you properly prioritize.


The Common Vulnerability Scoring System (CVSS) was created by the National Institute of Standards and Technology (NIST). This method scores vulnerabilities according to their severity on the basis of three basic metrics: base, temporal metrics and environmental metrics.

Each group contains several data, it’s subsequently evaluated and, finally, the results of the three are combined into final numbers indicating the criticality of the threat. There’s an online calculator for the calculation itself (fortunately). The CVSS score is therefore derived from the values you assign for each metric. Which one means what can be found in the documentation.


Attack trees

Attack trees are one of the oldest and most used methods to model threats to cyber, cyber-physical as well as purely physical systems (for example, modelling a potential attack on a security vault). Initially, trees were applied as a separate method, but today they’re combined with other methodologies, such as STRIDE, PASTA and CVSS.

An attack tree is a diagram that shows attacks on a system in the form of, of course, a tree; the top is the target of an attack and the leaves are ways to achieve that target. For each goal, you should create a different tree – the result will then be a forest of attack trees, which presents a complete analysis of system threats.


There are other methodologies and, of course, countless combinations of them. Whichever one you choose, we advise you to stay calm. It certainly isn’t right to just indiscriminately code and ignore the risks, but to evaluate every possible line in the console and wonder whether it’ll be a potential threat, may cause you to never finish your app. It’s also unwise to dig backwards into old projects and try to fit a model onto them – rather focus on a good analysis of new features and other projects you’ll embark on.