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 Examples |
|
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.
Think that your organisation might need professional help to threat model its applications? Request a free consultation, and we’ll see if we can help you.
