Threat modelling is the latest buzz word everyone is talking about and every organization wants to revamp their information to produce a prioritized list of security improvements to the concept, requirements, design and implementation.


Organizations are constantly exposed to attacks from adversaries if successful this could prevent a system from functioning as intended or could result in the exposure of confidential information and the number of threats grows as technology changes.

What is this Modelling everyone is talking about?

Well, not the expected one! But a much more consequential where every enterprise wants to grab a share of it. So, what is all this buzz about? Let me start with a quick introduction. Threat modelling is the process to identify, communicate, and understand threats such as structural vulnerabilities or the absence of appropriate safeguards and mitigations can be prioritized. This documentation provides system analyst and defenders with a complete analysis of probable attacker’s profile, the most likely attack vectors, and the assets most desired by the attacker.

Threat ScenarioFig: 1.0 Threat Scenario

Threat modelling can be implemented to a variety of things, including systems, software, applications, IoT, networks, business processes, distributed systems, etc. It can be done at any development stage, but preferably early at the design time.

How to create a Threat Model

All threat modelling processes start with creating a visual representation of application or system being analysed. There are two ways to create a visual representation.

  1. Visual Representation by Data Flow Diagram (DFD)

DFDs are utilized as a tool for system engineers to provide a high-level visualization of how an application works within a system to move, store, and manipulate data. DFD based approach uses three main steps:

  1. View System as an adversary
  2. Characterize the system
  3. Determine the threats

The list of threats identified through DFD method is limited and thus a poor starting point for the modelling, thus imprints certain weakness:

  1. DFD does not precisely speak to structure and stream of use
  2. They examine how information is streaming instead of how the client connect with framework
  3. DFD based risk displaying has no standard methodology because of which various individuals make threat models with various output for a similar situation or issue

Fig: 1.1 DFD of an online college application

  1. Visual Representation by Process Flow Diagram (PFD)

In contrast to DFDs and limitations faced by it, Process Flow Diagrams were introduced as a tool to allow Agile software development teams to create threat models based on the application design process. It provides a visual decomposition specifically designed for illustrating how attackers think. Attackers do not analyse data flows. Or maybe, they chart out how they can travel through the different application use-cases. PFD based approach uses three main steps:

  1. Displaying the application’s use cases
  2. Defining the communication protocols by which individuals move between use cases
  3. Including the various technical controls – such as forms, cookies, sessions, or other coding elements that make up the use-case

Fig: 1.2 PFD of an online banking application

Threat modelling methodologies for IT purposes

Well certainly, you will need a methodology to model the threats independently of asset-centric, attacker-centric, and software-centric. I’ll summarize the top three methods in this post coming from a variety of sources and target different parts of the process. No one threat modelling method is recommended over another; organizations should choose which method to use based on the specific needs of their project.

1.STRIDE methodology

STRIDE is one of the most primitive threat modelling methods. This methodology is created by Microsoft and deliversanimprint for a basic set of known threats in six categories, based on its name:

Fig: 1.3 STRIDE Threat Categories

STRIDE evaluates the system detail design. By building data flow diagrams (DFDs), STRIDE is used to identify system entities, events, and the boundaries of the system. This method is easy to adopt but can be time-consuming. The number of threats can grow rapidly as a system increases in complexity. This is where our next methodology comes into the picture.

2. P.A.S.T.A.

The Process for Attack Simulation and Threat Analysis (P.A.S.T.A) is a risk-centric threat modelling framework developed in 2012. It contains seven stages, each with multiple activities, which are illustrated as:

Fig: 1.4 PASTA Threat Categories

PASTA focuses to bring business destinations and technical prerequisites together. It utilizes multiple plans and elicitation tools in various stages. This strategy hoists the threat-modelling cycle to a vital level by including key decision-makers and requiring security contribution from tasks, administration, engineering, and improvement. Generally viewed as a risk-driven structure, PASTA utilizes an attacker driven viewpoint to create an asset-driven output as threat identification and scoring.


LINDDUN (linkability, identifiability, nonrepudiation, detectability, disclosure of information, unawareness, noncompliance) focuses on privacy concerns and can be used for data security. Consisting of six steps, LINDDUN provides a systematic approach to privacy assessment.

Fig: 1.5 LINDDUN Methodology Steps

LINDDUN begins with a DFD of the framework that characterizes its information streams, information stores, cycles, and external elements. By deliberately repeating over every model component and breaking down them from the perspective of threat classifications, LINDDUN users distinguish a threat’s appropriateness to the framework and construct threat trees.


Threat modelling can help make your item increasingly secure and reliable. The post displayed distinctive risk demonstrating techniques and procedures. Some are ordinarily utilized alone, some are generally utilized related to other people, and some are instances of how various strategies can be joined. To perform threat modelling, you should be explicit in zones you need to target (risk, security, privacy), to what extent you need to perform threat modelling, how much experience you have with it, how included partners need to be inside a spry environment, contingent upon the time period of the run and how regularly the modelling is rehashed.





Sankalp Mahajan

Attack & Pen Test Team

Varutra Consulting Pvt. Ltd.