Van Wyk: Building Your Threat Modeling Process

by Daniel Maloof | Mar 14, 2017

Tuesday, March 14, 2017 By Ken Van Wyk, IANS Faculty

Ken van WykIt’s not often that a new “cool” thing comes along in information security and we’re able to say we’re already doing it. But that’s the case with threat modeling – well, at least in part. You are doing threat modeling, right? If your answer is “no,” perhaps you just know it by a different name. Maybe you call it a design/architecture review, or something completely different.

Well, whatever you call it, let’s take a look at threat modeling and why it’s so important for infosec teams.

Threat modeling is the process of critically reviewing a system’s design for potential security defects – plain and simple. There are a few industry processes that allow us to follow a rigorous methodology, including Microsoft’s STRIDE and DREAD, as well as Synopsys’ (formerly Cigital’s) Architectural Risk Analysis (ARA).

Or, as fellow IANS Faculty Adam Shostack describes in his excellent book, “Threat Modeling: Designing for Security,” we can follow a more simple and intuitive approach and still get good results.

But, why bother? Aren’t we already doing static code analysis and rigorous security testing? Shouldn’t those processes find any security mistakes we’ve made in our software? Well, partially. It’s a question of perspective.

Static code analysis can be effective at finding implementation bugs such as failing to adequately filter data input, which can result in various cross-site scripting (XSS) and related data injection attacks. Its shortcoming, though, is that it fails to see business-relevant architectural flaws, such as relying on client code (e.g., JavaScript or Objective-C) to make security decisions. If we do our threat modeling well, we can find those sort of design failures before they cause us real grief later. Design failures, after all, can be among the most difficult and costly problems to fix.

Threat Modeling in Practice

So how, exactly, do we do this threat modeling thing and in what ways might we already be doing it?

Basically, it involves four steps:

  1. Model it
  2. Find threats
  3. Address threats
  4. Validate threats

Easy peasy, right? Well, let’s dive into each of those steps a bit and see for ourselves.

Model It

This is where we describe our system. One of the best things about threat modeling is that it allows us to take either a big- or small-picture view of our systems, but we must be able to clearly describe our design. This can take the form of a component diagram – either physical or logical – or things like data-flow diagrams. Be sure to clearly describe the component interconnections within your application. These inputs make up what we call the “attack surface” of the application (or the portion of the application we’re presently considering).

Find Threats

So, taken by itself, this piece seems a bit like “… and then a miracle occurs,” right? But there’s obviously a lot more to this, and there are a few things that can make this step go a bit more smoothly.

For starters, zoom in on one component at a time. Also, make sure to critically consider who has access to each component, including those who are authorized and unauthorized. Then, consider what would motivate the bad guys to attack. What is their goal? What are their expected technical capabilities? Can they, for example, write serious malware that can withstand reverse engineering for a considerable amount of time? In other words, make your threat scenarios real.

It’s also important to include key personnel such as your incident response operations team, your threat intelligence people, your principal design team and the business owners of the application being reviewed. Encourage the team to brainstorm and record everything they come up with.

This is also where Microsoft’s STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial-of-Service, Elevation of Privilege) model can be helpful. Use it as a checklist to catalyze conversations about individual scenarios.

Address Threats

This is where you decide what, if anything, you’re going to do about each threat you’ve uncovered. Start by prioritizing them. Microsoft’s DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) methodology can be helpful here. Use it to prioritize your threat list. Some companies prefer a quantified approach here, but I’ve found that the threat model team can do this step pretty intuitively using simple levels of quantification like low, medium and high priority. Of course, don’t neglect to factor in the costs of each potential remediation.

Validate Threats

Finally, it’s a good idea to prove that the threats and their remediations are based on facts and not just “gut feel.” Make sure each threat scenario is something your attackers can actually achieve, and that each remediation will truly protect your business.

Knowing Where to Begin

So, perhaps you never called this threat modeling, but I’ll bet you were already reviewing your business applications at some level prior to rolling them out. Maybe your process is too simplistic, though. Perhaps a more rigorous threat modeling process like the one I’ve outlined here can be helpful.

Either way, I say give it a try. Threat model a small application first and see how the process works for you. You may need to tweak it a few times before you get it right, and that’s all good. In Adam Shostack’s book, he encourages us in Chapter 1 to do a simple threat model first, before even getting into processes like the one I’ve described above. That’s great too!

Ultimately, in my experience with threat modeling, the two most important ingredients for success are a talented and willing multi-disciplinary team and a huge white board. Sure, the former might be a bit tougher to come by, but don’t even think about underestimating that white board! 



Ken Van Wyk is president and principal consultant at KRvW Associates and an internationally recognized information security expert, author and speaker. He’s been an infosec practitioner in commercial, academic, and military organizations and was one of the founders of the Computer Emergency Response Team (CERT) at Carnegie Mellon University.

Sign up for Updates

We’ll send you short and sweet notifications about our content and events.