In this article, we’ll provide the ultimate threat modeling example using multiple methods, including Data Flow Diagrams, Attack Trees, and STRIDE. This approach allows us to use many different threat modeling methods to gain (additional) insights into a real-world example.

The main question we’re asking ourselves is: Will the use of multiple threat modeling methods & diagrams help with our overall threat modeling activities?

The example that we’ll be threat modeling:

• A banking application with new crypto features. So think about the typical banking application, with added cryptocurrency features like buying & selling bitcoin, buying other coins, and using different marketplaces.
• Typical features included in a banking application (like user management, performing transactions, viewing balance overviews, etc.).

We’ll use the following threat modeling methods and diagrams: Data Flow Diagrams, Attack Trees, and STRIDE.

The following example will also answer Shostack’s four threat modeling questions:

• What are we working on? (with the help of the data flow diagram and attack tree)
• What can go wrong? (with the help of STRIDE)
• What are we going to do about it? (with the help of STRIDE)
• Did we do a good job?

Note that this threat model will not be an exhaustive list of (all) threats & requirements for banking apps or crypto. Rather, we focus on the methods and examples of results.

If you’re interested: Check out our threat modeling framework!

Let’s get started!

Data Flow Diagram for High Level Threat Modeling

A Data Flow Diagram (DFD) is a great way to understand the big picture without getting too involved in the details. Understanding the context is crucial when working on threat modeling and security topics.

Here’s a quick recap of the symbols used in a DFD:

• Data Flow:
  • Consists of an arrow symbol.
  • Depicts data flowing from the source to the destination component. Data can also flow two ways, which is shown by two arrows (one on either side of the arrow). Data Flows should only include data moving from one component to another and not include data transformation or alteration.
• Data Store:
  • Consists of two lines, or a database symbol (you can choose from both options).
  • Depicts a storage location of information used by the system. This is typically a database, a file, or some other data storage solution. Data going to the Data Store typically means data being saved. Data going from the Data Store typically means data being read.
• Process:
  • Consists of a circle, or a rounded rectangle.
  • Depicts applications or processes that apply logic and/or change data. The Process is typically where important logic or reasoning occurs, and is thus the ‘core’ or ‘center’ of the Data Flow Diagram.
• Interactor:
  • Consists of a rectangle.
  • Depicts an endpoint (person or system) that interacts with or uses the process. An Interactor is external to the system in scope. An Interactor can be an individual person or system, but it can also be an entity such as a ‘Customer’, or ‘Third Party.
• Trust Boundary:
  • Consists of a dotted line, multiple dotted lines, or a dotted rectangle.
  • Depicts a boundary between trust zones (i.e. the boundary between trusted and non-trusted zone). The Trust Boundary clearly shows what trust can imply for the boundary’s components. Trust is an important concept of threat modeling.

Now let’s use that in our banking with crypto example:

What does the Data Flow Diagram tell us:

• The banking app allows users to perform banking on smartphones. Users can use the iOS and Android versions.
• Key features (not all):
  • View & edit personal information.
  • View transactions.
  • Make a transaction.
  • Request a loan.
  • View & edit loan details.
  • Buy and sell crypto.
  • View crypto owned crypto assets.
• There are various components involved, i.e., the banking application at its center & the banking database, and 4 (external) actors: Banking Customer, Customer Service Agent, Crypto Exchanges, Loan Exchanges.
• We have identified some Trust Boundaries, between the Banking Customer & the Banking app, and between the Banking App & the Banking Database.
• We have already identified some high-level threats (see table below).

Threat 1	Features can be abused if they do not have effective checks (i.e., a transaction must only allow values based on available funds, cannot be negative, etc.).
Threat 2	Customer Service agents have the ability to make significant changes to customer data, transaction information, etc. These can be abused.
Threat 3	Banking databases can be abused directly, thus circumventing application layer controls (i.e., controls on transactions).
Threat 4	Crypto exchanges may abuse market position(s), which could negatively affect banking users.

Attack Trees

Attack trees are a great way of exploring potential abuse cases for the features of the application.

We can use an attack tree for each major feature. Many threats and security requirements in an attack tree seem obvious, but they are often not explicitly defined and may contain weaknesses.

An attack tree will tell you what can go wrong (which is one of Shostacks four questions). Each node represents one thing that can go wrong (which is an attack). Each node is related via branches, allowing for a visual representation of connections or relations. This allows attack trees to show the relations between attacks and attack types.

Attack Tree for Personal Data Features

In this case, we look at most applications’ personal data features, such as viewing or editing personal data (think your name, address, location, associated accounts, telephone number, etc.).

Threat 5	Edit other users (data). An authenticated user may be able to access other users data if there is a weakness in the authorization model and checker.
Threat 6	Edit user without authentication or authorization. An unauthenticated user may be able to access & edit users data if there is no check on the existence of the current user.
Threat 7	View other users (data). An authenticated user may be able to view other users data if there is a weakness in the authorization model and checker.
Threat 8	View without authentication or authorization. An unauthenticated user may be able to view users data if there is no check on the existence of the current user.
Threat 9	Edit other users via obscure feature. There may be obscure or old features that allow access to user data.

Attack Tree for Crypto Features

In this case, we look at most applications’ personal data features, such as viewing or editing personal data (think your name, address, location, associated accounts, telephone number, etc.).

In this case, we look at the crypto features of the banking application. This is the main use case of this threat modeling example. Just to remind you, this won’t be an exhaustive list of crypto-related threats.

Threat 10	Crypto (is) not assigned to (the) user. The buy feature needs to ensure that the user, upon paying for crypto, actually has the crypto assigned to the user. An external exchange cannot be trusted without verification.
Threat 11	Higher purchase price. The purchase price needs to be validated at the point of purchase and funds transfer. The price should not vary from the confirmation price.
Threat 12	Lower selling price. The selling price needs to be validated at the point of purchase and funds transfer. The price should not vary from the confirmation price.
Threat 13	Crypto sold, funds not assigned. A user, upon selling crypto, must get funds assigned. An external exchange cannot be trusted without verification.
Threat 14	Incorrect price. Pricing of crypto must be as accurate as possible and must be correct within an agreed-upon margin.

You can add as many attack trees as needed to cover the various features of the application or solution.

Using STRIDE to Define Threats

STRIDE helps us to think about potential threats by breaking them down in 6 threat types:

• Spoofing is a type of threat whereby an attacker maliciously impersonates (or pretends to be) a different user (or system). You can also use Spoofing more loosely during STRIDE threat modeling to classify threats related to users and access rights.
• Tampering is a type of threat whereby an attacker maliciously modifies data. You can also use Tampering more loosely during STRIDE threat modeling to classify threats related to the security of data.
• Repudiation relates to the ability to prove or disprove that an action or activity was performed by a specific user (or not). Repudiation is thus a type of threat whereby an attacker denies having performed a malicious action.
• Information Disclosure is a type of threat whereby the attacker gains access to information that should be confidential or secret (and not available to an attacker).
• Denial of Service is a type of threat whereby an attacker will prevent a system (or application) from working for valid users. This is often achieved by overloading a system with fake requests so that no time or resources remain for legitimate users.
• Elevation of Privilege is a type of threat whereby an attacker will elevate their current level of access privilege. This can include elevating access privileges where an attacker has no privileges at all (i.e., not a user) or elevating access privileges where an attacker already has ‘some’ privileges (i.e., a basic user).

In our crypto banking application, we can identify the following STRIDE threats:

Threat 15	Information Disclosure An attacker may attempt to identify information related to other users, within the application. This could target personal details, banking transactions, or crypto transactions. Especially crypto transactions may have data sources that can be exploited (for example with crypto exchanges). Countermeasure Make an inventory of all confidential personal & transactional data sources (i.e., personal data, banking transactions, crypto transactions). For all sources, ensure the related features secure the data sufficiently. Affected Components, Systems, or Areas Banking app, any features related to confidential data.
Threat 16	Tampering A user may try to alter the account balance information via one of the forms, or other data entry options. Countermeasure The system must validate account balance information from central databases, and not rely on user input for account balance. Affected Components, Systems, or Areas Account balance feature.
Threat 17	Spoofing An attacker, when purchasing crypto, could pretend to be another user in the system right at the point of purchasing. Countermeasure Re-validate the user prior to the purchase moment. Affected Components, Systems, or Areas Crypto purchasing feature.
Threat 18	Repudiation A user may purchase crypto, and then try to argue that they did NOT purchase the crypto (i.e., because the value may have decreased). Countermeasure Upon purchase of crypto, identity of the user must be verified, a log entry must be created, and the purchase transaction must be stamped. Affected Components, Systems, or Areas Crypto purchasing feature.
Threat 19	Spoofing A user, when performing a transaction could try to perform the transaction using user ID information from other users. Countermeasure When performing a transaction, the system must check the identity of the user via re-authentication. Affected Components, Systems, or Areas Banking transaction feature.
Threat 20	Elevation of Privilege(s) Normal users (customers) may attempt to gain access privileges from backend users (helpdesk employees). Helpdesk employees have various features that normal users don’t have. For example: the ability to view data from many users. Countermeasure Ensure that end users (customers) do not have access to helpdesk features. This should be enforced within the features in scope, but also by restricting access to helpdesk features to within the corporate network (and not accessible from the internet). Affected Components, Systems, or Areas Helpdesk features.
Threat 21	Denial of Service Attackers may flood the public/internet-facing application with requests in a DDoS attack. Countermeasure Ensure that sufficient DDoS protection is used. Affected Components, Systems or Areas Public facing banking app.
Threat 22	Denial of Service An attacker may make many bogus crypto transactions which flood the transaction solution (which has more limited capacity, compared to the standard internet-facing application). Countermeasure Ensure that the crypto transaction system (which is not internet-facing), has a message queuing system or similar. Affected Components, Systems or Areas Crypto (exchange) transaction system.

What are the Results of Using Multiple Threat Modeling Methods & Diagrams?

We’ve created three types of diagrams and threat modeling methods: Data Flow Diagram, Attack Trees and STRIDE.

As a result, we have a good understanding of the system and potential threats, which are far better than just using a single method.

By analysing our overall results we can see that:

• The Data Flow Diagram is good at providing a high-level understanding of the threat model scope (in this case the banking app, and crypto features).
• The Attack Trees deep-dive the features of the application. This provides the types of actions that users can do (and the related threats of those actions & features). This allows us to look at features rather than just architectural or design choices.
• The STRIDE analysis deep-dive into threats along the six STRIDE types. The threats are less focused on the features & actions. STRIDE remains helpful for thinking of threats that are not immediately obvious.

Overall, we can conclude that using a combination of methods is superior to just using one.