Methodologies and Approaches for Threat Modeling

My presentation for this year is Threat Modeling. My first stop is the 2024 Palmetto Cybersecurity Summit Feb 21-22, 2024, in Columbia SC. I’ll also be speaking at BSides Nashville May 11, 2024, and ShowMeCon May 13-14, 2024.

There are a variety of ways to do threat modeling. Deciding which one to use will depend on the organization and what is being threat modeled. I started with STRIDE which is a standard methodology for getting started. We’ll touch on the other ones but I’ve not had experience with them. The basic concept should be the same. The methodologies are used to help guide a threat modeling session through attacking and mitigating the threats discussed.

MethodologieS

STRIDE

Developed by Microsoft, STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. This model helps in identifying threats in these six categories, making it easier to systematically address potential security issues.

Repudiation is the one that always get’s me. It’s attackers getting in and performing illegal operations without leaving any sort of evidence. This is usually due to a lack of logging. The others are fairly straight forward.

LINDDUN

This is a privacy-focused threat modeling methodology designed to help identify and address privacy threats in information systems. The acronym LINDDUN stands for the seven types of privacy threats it aims to uncover: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance.

PASTA

The Process for Attack Simulation and Threat Analysis (PASTA) is a seven-step, risk-centric methodology. It focuses on aligning business objectives and technical requirements, taking into account the attacker's perspective and potential attack vectors. It is thorough and integrates well with risk management.

OCTAVE

Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) is a suite of tools, techniques, and methods for risk-based information security strategic assessment and planning. It focuses on organizational risk and security practices, making it more suited for strategic, rather than technical, threat analysis.

Attack Trees

Attack Trees provide a methodical way of describing the security of systems, based on varying attacks. It's a graphical representation of potential attacks, organized in a tree structure, showing how an overall goal (root) can be broken down into sub-goals (leaves). This is an example of an attack tree.

Example of using STRIDE

Created with the help of ChatGPT

A threat modeling tweet by @thegrugq that highlights attack surface.

Below are some examples I’ve seen discussed in a threat modeling session. The skies the limit and will be different depending on the application or process. At the very least it’s a thought exercise that helps people think about security and discuss mitigating controls. Some of these attacks are more likely than others. Within healthcare insider threat and errors are a lot higher than other industries. They’re still susceptible to external attacks but the bigger concern may already be inside the organization. Each organization will have it’s own attack surface.

Spoofing

Threat: A healthcare provider uses another users logged in session when they walk away form their computer.

Mitigation: Ensure session timeout is set to what is needed for the business use case of the application. If a user has several activities that require waiting for something to finish in the application or they need to login into other applications and then come back then the timeout may need to be longer.

Tampering

Threat: A healthcare provider accidentally modifies the wrong record for two different patients.

Mitigation: Add a, “are you sure?” pop-up. Logging and recovery will need to be in place for identification and recovery.

Repudiation

Threat: A user (patient or provider) denies sending a message or making changes to records.

Mitigation: Implement detailed logging and audit trails to track user actions and changes within the application.

Information Disclosure

Threat: S3 bucket with patient information is accidentally made available on the internet.

Mitigation: Use access controls to enforce the principle of least privilege, ensuring users can only access information necessary for their role, and encrypt data.

Denial of Service (DoS)

Threat: A ransomware attack encrypts the web server.

Mitigation: Web server and all needed systems have good backups and can be restored to get the service back online for users.

Elevation of Privilege

Threat: A user is bribed to give up their credentials to the application.

Mitigation: User IP logging to help identify when a user logs in from an abnormal location.

Approaches

At my organization I was the person doing the threat model. I was training up some of the other people on my team so they could do it and not create a bottle neck with my department. Some organizations an individual or team may not be the best approach. In this case a decentralized approach could be more beneficial where the teams are trained up on doing their own threat models.

As far as automated tooling I haven’t used a lot of it other than as a substitute for a whiteboard. I have seen the use of Microsoft’s Threat Modeling tool which will help with attacks but will require a lot more interaction. There’s not really a wrong or right answer. I’ve shown a lot of value and made projects run more smoothly and with less threat introduced by using just a whiteboard and markers. Haven’t explore the automated threat modeling space but I do believe that you can’t replace a human. A one-push threat model would be nice it’s just not that easy and as I’ve learned in the industry there is no easy button.

Threat modeling should be done as early in the process as possible. However, it is very useful for legacy applications or applications with minimal documentation. I’ve used it a lot for getting a better understanding of how an existing application or process works, especially if there’s very little documentation. These sessions usually require multiple because as unanswered questions comes up and people are tasked with doing some discovery work. Once that discovery has been made the threat model continues.

Summary

STRIDE is a good place to start with threat modeling. There are other methodologies that could be more applicable to the organization. I’ve only ever used STRIDE because it was effective for what I was doing with threat models. Walk through the chosen methodology to get an idea on the attacks possible within the application. These attacks can be simple or they can be a bit more elaborate. A few simple examples will help with getting people to think about how to attack an application or process.

Approaches to threat modeling will differ between organizations. A group of security experts can make an effective threat model but it may not be scaleable. The other option is to train people within the projects to perform the threat model. Thinking about what could go wrong will get people into the mindset of looking for problems before they happen. The earlier a problem is discovered the less costly it is to fix. Threat modeling can also be used for discovery on existing applications or processes.

There are tools available for threat modeling. The simplest and often the most effective is a whiteboard and markers. Threat modeling is like any other security program. Get it started and then mature it over time. Try new things and evaluate if it’s useful or not. Just get started.

Next we’ll go over risk management and rating the discovered threats.