What Every Developer Should Know About Threat Modeling


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 threat modelingIzar 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 threat modelingMatthew 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 threat modelingAdam 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.

RelatedBurnout in Cybersecurity Is on the Rise. That’s Because It’s an Unwinnable Game.


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…


Read More:What Every Developer Should Know About Threat Modeling