Threat Modeling Techniques & Examples

Earlier this year, ethical hacker Alex Birsan found a back door into the systems of more than 35 major tech companies, including heavyweights like Tesla, Netflix, Uber and Shopify.

His discovery, which made waves in the world of cybersecurity, showed that he could get his own code to run on these companies’ internal systems by uploading it to public repositories using dependency names he uncovered by digging into publicly available code.

“People created these nice packages that you can automatically download and get the latest and best, but they forgot to think about what could go wrong and cover those cases,” said Izar Tarandach, a principal security engineer at Squarespace and co-author of Threat Modeling: A Practical Guide for Development Teams. It’s a pattern of “things happening perhaps too fast or perhaps too widely, and nobody stopping the train and saying, ‘Wait, what could go wrong here?’”

What Is Threat Modeling?

Threat modeling is a structured process of identifying potential security and privacy issues within an application. The process includes creating system representations for given use cases and highlighting possible ways in which things could go wrong. Numerous threat modeling frameworks exist, including the popular STRIDE, which was developed at Microsoft; LINDDUN, a privacy-centric framework; and continuous threat modeling, an explicitly developer-friendly approach. Data flow diagrams are sometimes used to create system representations, as are sequence diagrams and process diagrams.

Threat modeling slows the train and asks that question. It asks, more specifically, what might go wrong with an application from a security perspective.

That question forms the crux of the Threat Modeling Manifesto, a hyper-streamlined guide put together by more than a dozen experts. Threat modeling involves a couple of key components — drawing representations of the system and coming up with potential concerns — and it should ask four high-level questions, according to the manifesto.

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

The simple checklist belies threat modeling’s sometimes-unwieldy reputation. Uninitiated development teams may mischaracterize the process as a bureaucratic millstone — perhaps reinforced by the fact that dozens of (often vaguely militaristic-sounding) framework options exist.

But “threat modeling doesn’t need to be difficult,” stressed Adam Shostack, a contributor to the manifesto and author of Threat Modeling: Designing for Security. “Just asking the four questions is a great way to get started.”

Threat modeling has proven malleable too. Decades-old frameworks are fluid enough to fit the shape of whatever newer development practice they sit in, right up to CI/CD and just-in-time coding and beyond. It can be done “across a range of development methodologies, and the techniques and tools are evolving to support the evolution of development practices,” said Matthew Coles, also a co-author of Threat Modeling: A Practical Guide for Development Teams. “There is no barrier to entry to threat modeling today, other than misunderstanding.”

We asked a panel of experts to explain how teams can maximize the value of threat modeling while also making sure it doesn’t hamstring application and feature delivery. They also walked us through several prominent threat modeling frameworks and tools, including some resilient, long-standing options and a few emergent newcomers.

Our Panel of Experts

Adam ShostackL Threat modeling consultant and author of Threat Modeling: Designing for Security. Shostack is a former program manager at Microsoft, where he led development of Software Development Lifecycle threat modeling tool.
Izar Tarandach: Principal security engineer at Squarespace and co-author of Threat Modeling: A Practical Guide for Development Teams.
Matthew Coles: Senior principal product security engineer at Dell Technologies and co-author of Threat Modeling: A Practical Guide for Development Teams.
All three are contributors to the Threat Modeling Manifesto.

Threat Modeling Requires Buy-In From Everyone Shipping a Product

Izar Tarandach: You can’t depend on one person [to threat model]. Systems today are so wide and deep that you need the view from the whole team. The best scenario is to get as many people as possible in a room and have them hash out, first, the model aspect. You have to get to a representation of what the system is that everyone can agree on. Once you have that recognition, then you move to threat elicitation, where you can use any number of different techniques to figure out what could go wrong.

The modeling part answers the first question: “What are we working on?” Threat elicitation goes to “What could go wrong?” Then bring both together and answer the third question: “What can we do about it?” Are we going to change the way the system was designed? You already have a system in hand that you can test, that you can throw whatever threats you identify against. Then you ask, “Did we do a good enough job?” — which covers very different levels. Did we do a good job modeling, eliciting threats, mitigating threats and closing the loop?

RelatedWhat Is Fuzz Testing? A Guide.

Matthew Coles: We generally work with folks called security champions — developers who also have some security experience or training and understand the value in this exercise. And they partner with a security team or do it on their own. That’s the entry point into the development team. From there, we want to make sure when an exercise is done — especially that first modeling piece — that we’re having a number of different aspects of the development organization be available.

Everyone comes with different biases and information. Developers and architects will have a specific understanding, but QA, customer support, tech writers all may drive other threads of conversation. It isn’t just a developer and architect sitting in a room. Threat modeling is a conversation. Even if nothing gets written down but you still have an exchange of ideas and understanding about the system, then the goal has been met.

You Might Be Threat Modeling Without Even Realizing It

Adam Shostack: A lot of folks have questionnaires that they apply, which say, if you’re doing one of these things, then you need to threat model. But in fact, the questionnaire is a threat model. It’s not a very creative one. But implicit in it is, what are you working on? Personally identifiable information (PII)? Financial data? What can go wrong? Are you deploying something new? Is this adding a new end point, a new API or a new listener? What these questionnaires do is a form of threat modeling.

If you think about the four questions without any of the [added] structures that we might apply, you can threat model in 60 seconds. What are we working on? Here’s my sprint plan. What can go wrong? I don’t think there’s any security stuff here. And you can present this as part of a standup and be done in a minute. Sometimes it makes sense to go deep; other times, it makes sense to [just] ask those questions. To me, it’s all threat modeling.

Threat Modeling Does Not Necessarily Demand DFDs

Coles: Different modeling techniques can be used. Ultimately, you want a representation of the system. Data flow diagrams (DFDs) show what components exist and how they talk to each other, specifically in terms of direction of travel, plus security control information. Is this interface encrypted? Is it authenticated? Does it talk to a database?

You get that from a DFD, but you can gain the same information from other model types — an adequately annotated sequence diagram, fishbone diagrams, or process diagrams. The notion that DFDs equal threat modeling is untrue.

“It helps to have a diagram because people are very visual, but that isn’t strictly necessary for threat modeling.”

In threat modeling in code, for example, we don’t actually build the model; we build the model in code, meaning we use a descriptive language to describe a system, but we don’t actually have to build the model in order to do analysis. You can [even] describe the system in written text and still get a complete model that you can then analyze: “This process is a web server that authenticates users and writes data to a database, and the database is connected over an encrypted channel, and I use prepared statements.” I have a model and can derive threats from that without ever drawing anything on a whiteboard. It helps to have a diagram because people are very visual, but that isn’t strictly necessary for threat modeling.

Threat Modeling Should Be Done at the Design Stage, but It’s Never Too Late

Tarandach: The closer you are to the moment of design, the cheaper [a fix] is. [But] at any time in the lifecycle of a product, you are able to start threat modeling.

That’s why we came up with the idea of continuous threat modeling. At any point of the life cycle, you can come up with a baseline threat model, and from then on, you start modeling every story. Figure out if the story has a security value. For example, if my story is, as a user, I would like to have wonderful documentation, that doesn’t have a lot of security. But if the story is, as a user, I want to be able to delete all my backups, that has security value.

So in that case, we have a framework where the developer can ask a series of questions and get security patterns out of it, not only to be able to fill in the threat model, but, over time, incorporate those design mitigations in the process of writing the story.

Find out who's hiring.

See all Developer + Engineer jobs at top tech companies & startups

View Jobs

Threat Ranking May Be Counterproductive

Shostack: Formally ranking a threat — high, medium or low, or assigning a number — doesn’t have the payoff we hope. So many have stressed prioritization that people feel compelled to do it. And I like to bring it up in a retrospective and ask, “How useful was that energy?”

We pick up something like CVSS and say, “Oh, my gosh, this [threat] is a CVSS 9.2. We’ve got to fix it.” [CVSS is a prioritization framework that ranks vulnerabilities on a 0-to-10 scale.] And engineering says, “Wow, that’s like six sprints, and we’ve got these business features, so no.” And we get into a fight. And that absorbs energy we could be using to fix six or seven other things that might also be important, but lower on the CVSS scoring.

On the other hand, regulated industries, like medical device makers, have to threat rank. Because they’ve got to serve the regulators.

Threat Modeling Frameworks to Know

The list of frameworks is long and ever-growing. Below is a representative sample of those currently being used in the field, based on our interviews. We’ve also included attack trees, which are a historically important model, even though few experts use it today.

STRIDE

STRIDE is a leading threat modeling framework, developed at Microsoft and introduced in 1999. STRIDE refers to:

Spoofing - Pretending to be someone or something else.
Tampering - Modifying some information or data.
Repudiation - Claiming some action that was done wasn’t, or vice versa.
Information Disclosure - Accessing unauthorized information.
Denial of Service - Shutting down resources necessary to stay provide service.
Elevation of Privilege - Allowing someone to do something unauthorized.

Shostack: The reason STRIDE has had staying power is twofold. First, it covers a lot at a nice level of abstraction. It’s specific enough to prompt you to think about a problem, like spoofing or tampering, while being abstract enough to not say “tampering with files” — so you can cover tampering with databases, with networks, with configuration and so on.

Also, it’s a mnemonic, which helps you remember it. In my courses, I also teach kill chains as a method for threat modeling, usually MITRE ATT&CK, and, to be honest, I have to go back and look to remember what the stages and columns are. With STRIDE, you can do it even without [formally] introducing it. You can talk about spoofing relative to X, versus pulling up a website and using its checklist. The instant you do that, you’re making it scary and slowing down the conversation.

MITRE ATT&CK

Shostack: MITRE ATT&CK is a kill chain set of tactics. For threat modeling, you replace STRIDE with initial access, execution persistence, and you say: “How can an attacker persist? How could they escalate privileges? How can they evade defenses? Where in the attack matrix does each occur?” I see many people succeed with STRIDE and kill chains, so I recommend that people start there.

More Threat Modeling Frameworks to Know

Continuous Threat Modeling: A developer-friendly framework that deprioritizes extreme security expertise and accentuates nimbleness.
LINDDUN: A seven-step privacy-centric threat modeling framework, developed by the DistriNet Research Group. LINDDUN GO offers a streamlined entry point into the methodology. LINDDUN is a mnemonic for the following threat categories: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness and Non-compliance.
INCLUDES NO DIRT: A specialized framework designed for healthcare environments that builds upon STRIDE and LINDDUN.
TARA (Threat Assessment and Remediation Analysis) from MITRE: This framework is sometimes used in government exercises and in the automotive industry.
Threat Libraries: This approach references one or more catalogs of common threats. Notable examples include OWASP’s Top Ten Web Application Security Risks and Solove’s taxonomy of privacy categories: activities, collection, dissemination and invasion.
PASTA (Process for Attack Simulation and Threat Analysis): A seven-stage framework, first outlined in 2012 by co-creators Tony UcedaVelez and Marco Morana.

Attack Trees

Shostack: Attack trees are a way of thinking about how an attacker achieves some goal or does some damage. You start out with a goal, such as turning off Colonial Pipeline’s ability to move oil. I could do that by turning off electricity, or by cutting cables, or by installing ransomware. Turning off electricity and cutting cables are both denial of service. So I’ll make a denial of service subhead in the tree [diagram], then think about other ways to achieve that goal.

What else could I do to stop them from working? I go through and draw [each concern] into the tree or outline as a way to organize my thinking. This was a big advance in 1994, but it’s not as useful as asking: “How could someone engage in lateral movement? How could someone engage in discovery?” — which a tool like ATT&CK gives us.

Attack trees tend to be hard to build as a practical matter. They rely on a lot of expertise, so I no longer teach them as a method unless someone really wants them for some particular reason.