What is Application Threat Modeling

Application threat modeling makes it possible to systematically analyse the security of an application – identifying potential threats, ranking their risk and enacting countermeasures to resolve them. we’ve taken a simple 3-step look at how to do it.

To ensure organisation-wide security, it’s essential that applications are developed with security built-in from the very beginning.

Application threat modeling makes it possible to systematically analyse the security of an application – identifying potential threats, ranking their risk and enacting countermeasures to resolve them.

To help you incorporate this best-practice into your application development, we’ve taken a simple 3-step look at how to do it.

Step 1: Decompose the Application

In order to identify an application’s weaknesses, it’s essential to understand how the app interacts with external entities. By mapping an application’s entry points, assets, trust levels and dependencies, it becomes possible to map data flows through the application’s different systems and subsystems, and pinpoint the exact location of potential vulnerabilities.

Entry Points are interfaces through which attackers can access an application and its data. It’s essential that all entry points, including multi-layered entry points, like those in a web page, are identified and documented.

Assets are parts of the application that may motivate an attack or security breach. Assets can be physical (like a list of customer information) or abstract (like an organisation’s reputation) and both need to be carefully documented.

Trust Levels are the access rights that an application will grant to its users. Recording trust levels makes it possible to map the access rights at each point of entry, and monitor the trust levels required to engage with the application’s assets.

External Dependencies are essential components of the app that lay outside of the application’s code – like servers and firewalls. Whilst these items are outside of the control of the application, they may fall within the organisation’s wider remit; and identifying these dependencies will minimise the application’s overall risk.

Step 2: Identify and Rank Threats

By decomposing the application, it becomes possible to analyse every aspect of the application’s functionality and design architecture, and identify weaknesses that could be exploited. In order to manage this process in a thorough, systematic and repeatable way, it’s a great idea to use a threat categorisation framework like STRIDE.

STRIDE categorisation outlines six common types of threats, and the security controls which are responsible for protecting against them. By analysing applications against these threat types, organisations can systematically identify potential weaknesses, and determine the efficacy of existing security controls.

Threat Example Security Control
Spoofing Accessing and using another user’s authentication information Authentication
Tampering Alteration of data as it flows over an open network Integrity
Repudiation Users denying the performance of an illegal action, in an environment where accountability can’t be identified Non-Repudiation
Information Disclosure Disclosing of information to individuals without access rights Confidentiality
Denial of Service DoS attacks against valid application users Availability
Elevation of Privilege Unauthorised users gaining privileged access status Authorisation

The security risk posed by each identified threat can then be ranked using a value-based risk model. At its most basic level, the risk of a threat is equal to its likelihood of occurrence, multiplied by its potential impact:

Risk = Likelihood * Impact

Microsoft’s DREAD system uses this principle to create a quantifiable risk score for potential threats. Assigning each risk component a value between 1 (low) and 10 (high) allows organisations to rank individual threats, and prioritise their security responses accordingly. For example:

Damage potential: 8

Reproducibility: 7

Exploitability: 10

Affected users: 10

Discoverability: 8

DREAD score = (8+7+10+10+8) / 5 = 8.6

A score of 8.6 from a maximum risk threat of 10 indicates this particular threat is high priority, and in need of an urgent response.

Step 3: Identify Suitable Countermeasures

Armed with a list of potential threats, it’s now possible to identify whether suitable countermeasures exist. Using threat categorisation, like the STRIDE system, makes it much easier to identify specific countermeasures for each threat, and prioritise their use.

Threat Countermeasure
Spoofing Appropriate authentication
Tampering Appropriate authorisation
Repudiation Digital signatures
Information Disclosure Encryption
Denial of Service Throttling
Elevation of Privilege Run with minimal privileges

Security threats without suitable countermeasures are vulnerabilities – and these require further action to remedy. The action taken will depend upon the potential risks of the vulnerability, and the costs of redesigning the application versus the costs of transferring risk (i.e. insurance) – with responses varying from no action through to the decommissioning of the application.

Get Switched on

Subscribe to our newsletter to keep ahead in the industry, and be the first to access new reports and white papers.