Digital attacks are more and more frequent, and the first step in securing your app is understanding the threats and how to counter them.

Threat modeling is an approach that analyses the security of an application. It is a structured way to identify, quantify and mitigate the security risks in an application.

You are about to read a short briefing I wrote for myself some time ago, made up from information I’ve collected by dissecting several other articles. The idea behind this article is for it to act as a reminder and to be as short as possible but still hold relevant information.

So with that being said, let’s write the most common definition of threat modeling:

Threat modeling is a security process with goals to identify objectives  and vulnerabilities and then define countermeasures to prevent or lessen  the effects of threats to the system.

I’ve also read that threat modeling gives answers to these four questions:

  • What are we working on?
  • What can go wrong?
  • What are we going to do about it?
  • Did we do a good job?

And I couldn’t agree more. That’s why threat modeling is composed of four parts, where each part answers one question:

  • Decomposing the application.
  • Determining the threats.
  • Determine counter measures and mitigations (reducing the danger).
  • Rank threats.

Decomposing the application

The goal of this step is to understand the application by decomposing it into parts and seeing how those parts interact with external entities. The way to do this is to gather information and documentation by mapping the application’s entry points, elements/assets and dependencies.

  • Decompose the application by drawing a diagram of various components in the  application. You can do this with Data Flow Diagrams.
  • Identifying  entry points — Software entry points may serve as entry points of an  attacker( login pages, search fields, HTTP requests etc.). It is essential that all entry points are identified and documented.
  • Identifying  the elements/assets — that have a value, and therefore a risk of being  attacked. An asset can be in a form of data like a list of customer  information, it can also be in different forms: overall application  availability, organizations reputation.
  • Dependencies  are parts of the app that lay outside of the application’s code. As  these items are outside of your control they may pose a threat if they are not properly maintained so identifying these dependencies will minimize the application’s overall risk.

Determining threats

Determining threats can be done by threat categorization STRIDE. STRIDE is an  approach from the attackers perspective, and it is used to determine  threats. While there are other approaches such as ASF (Application  security framework — an approach from the defenders perspective to  determine countermeasures), in this article I will be focusing on  STRIDE.

STRIDE categorization outlines six most common types of threats and their countermeasures.

STRIDE

  1. Spoofing identity — Impersonating someone or something else.
  2. Tempering with data — Modifying some data on disk, network, memory.
  3. Reputation — Denial of proof of some action.
  4. Information disclosure — Exposing information to someone not authorized to see it.
  5. Denial of service — Deny or degrade service to users.
  6. Elevation of privileges — Unauthorized gaining of more rights than originally intended.

Determining countermeasures

Every threat from STRIDE has a countermeasure.

  1. Authentication (for Spoofing) — Establishing a verifiable identity.
  2. Data protection (for Tempering with data) — Maintaining data and ensuring consistency of data and methods that work on data.
  3. Confirmation (for Reputation) — Every action against the application must be logged.
  4. Confidentiality ( for Information disclosure) — Restricting access to system and data.
  5. Availability(for Dos) — Leverage levels of redundancies.
  6. Authorization (for Elevation of privileges) — Limiting access to data, actions and services.

Rank Threats

To  tackle the problem of ranking threats Microsoft devised a risk  assessment model called DREAD, a model which provides five rating  categories for each threat. In the beginning they used the rating from 1  to 10, ex. for every threat in each category a rating from 1 do 10  would be given.

However,  as different people selected very different numbers, there was a shift  away from DREAD ratings within high number ranges towards some simpler  classification with 4 different levels of risk:

  • 1: low
  • 2: medium
  • 3: high
  • 4: critical

Sum of all ratings for a given threat is used to prioritize it among other threats.

The categories to rank for every threat are:

  • Damage — how bad would an attack be?
  • Reproducibility — how easy is it to reproduce the attack?
  • Exploitability — how much work is it to launch the attack?
  • Affected users — how many people will be impacted?
  • Discoverability — how easy is it to discover the threat?

For  every threat in each category a rating from 1 do 4 is given and the sum  of all ratings for a given threat is used to prioritize it among other  threats.

Up until now we decomposed the application, analysed functionalities,  determined possible risks and identified weak points that could be  exploited. Then we determined the countermeasures and used DREAD to rank  the risks. The only thing left is to act accordingly in solving those  risks.

Thank you for reading! Check out more articles like this on my freeCodeCamp profile: https://www.freecodecamp.org/news/author/goran/ and other fun stuff I build on my GitHub page: https://github.com/GoranAviani