Organizing threat modeling magic

I was inspired to develop and share my thoughts after Adam’s previous post (magical approaches to threat modeling) regarding selection of the threats and predictions. Since a 140 characters limit quickly annoys me, Adam gave me an opportunity to contribute on his blog, thanks to him I can now explain how I believe in magic during threat modeling.

I have noticed that most of what I do, because it is timeboxed due to carbon based lifeforms constraints, needs to be a finite choice selection from what appears to me as an infinite array of possibilities. I also enjoy pulling computer related magic tricks, or guesses, because it’s amusing and more engaging than reading a checklist. Magic, in this case, is either pure luck or based on some skills the spectators can’t see. I like when I think I’m having both.

During the selection phase of what to do, there’s a few tradeoffs that have been proposed such as coverage, time and skills required. Those are attack based and come from the knowledge of what an attacker can do. While I think that those effectively describe the selection of granular technical efforts, I prefer to look at what are his motivation rather than the constrains he’ll face. And for all that, I have a way or organizing it and showing it.

 

Attack Tree

When I think about the actual threats of a system, I don’t see a list, but rather a tree. That tree has the ultimate goals on top, and then descend into sub-goals that breaks down how you get there. It finally ends up in leaves that are the vulnerabilities to be exploited.

Here’s an unfinished example for an unnamed application:

A fun thing to do with a tree is to apply a weight on a branch. In this case the number represent attacker made tradeoffs and is totally arbitrary.

If you keep it relatively consistent to itself, you end up with an appropriate weighting system. For this example, let’s say it’s the amount of efforts you estimate it takes. You can sum the branches in the tree and get sub-goals weight without having to think about them.

And from that we can get a sum for the root goals:

But then how do I choose to prioritize or just work on something?

I could just say, well I’m going to do the easiest things to do, maybe because finding an SQLi in the application is easier than finding a slow API request, so better start looking at that first.

But regarding to decision, I often decide to do the most common human behavior: just don’t do it myself.

With the help of the tree, I just let the actual business reality do the selection on which root goals to pick. By that I mean the literal definition of reality, although nowadays people seems to forget what it really means:

“reality · noun · 1. the world or the state of things as they actually exist, as opposed to an idealistic or notional idea of them.”
– Google Almighty

I never ask the business line if they think they’ll have SQLi, but rather, if they worry more about denial of service or information stealing.

One advantage of that, is that those decisions are at the root goals. The tree is a hierarchy; the higher level you are, the bigger impact you’ll have. Like spinning a big cog wheel versus a smaller one:

3 gears

If you were to pick on each vulnerability at the time, you’ll spin your working wheel a lot, while just really advancing the root goal a bit. Work on doing the selection on the root goals, then you’ll see that it’s impact is far greater for about the same amount of time. That’s efficiency to me.

And that’s how I turn magic into engineering 😀

Of course, in order for it to be proper engineering, the next step would be to QA it. And at that point, you can fetch all the checklists or threats repository you can find, and verify that you covered everything in your tree. Simply add what you have missed, and then bask in the glory of perceived completeness.

 

For the curious practitioners, I’ve used PlantUML in order to generate the tree examples as seen above. The tool let you textually define the tree using simple markup and auto balance it for you when you are updating it. A more detailed example can be found on my Threat Modeling Toolkit presentation.


Also published on Medium as an experiment.

Author: Jonathan Marcil

Sr. Application Security Engineer at Blizzard Entertainment. Opinions, idiolect and views are my own and does not represent the ones of my employer.

2 thoughts on “Organizing threat modeling magic”

  1. Thanks Jonathan for writing this up. Frankly, I’ve been struggling with integrating it into my models of the world. That’s my problem, but I think I’ve finally resolved why I have trouble.

    First, “I just let the actual business reality do the selection on which root goals to pick.” There are ways in which this is great; as we discussed, the business does the work which matters to it. But it’s not particularly prescriptive, and one of the things I’ve learned about scaling is that a lot of people like prescriptive. I mean, you wouldn’t make a game in which the players can just build their own world! More seriously, maybe some people like less prescriptive, and can work in that creative space.

    Second, I think that I do have a disagreement about unitless costs on your graph; I want those numbers to be grounded somewhere, other than the defender’s estimates of attacker tradeoffs.

    1. Thanks for reading and giving feedback on the post!

      I think you’ve pin-pointed something that I have not explained regarding my vision/philosophy: I see a difference between Threat Modeling and Threat Intelligence. Threat Intelligence for me it’s the actual knowledge bits, and Threat Modeling is the methodology that organize that knowledge as well as its related to the targeted system.

      I’m then not being prescriptive on purpose because I wish to concentrate on the methodology and leave details on the interpretation on what is going on to domain expert or research related to Threat Intelligence. That by itself is incomplete, but gives flexibility.

      That way, the numbers can have the units you want. If you wish to have the units based on a detailed risk analysis, or anything else as long as it’s consistent for all numbers, you can! For the root goal selection, it should also come from risk management/analysis. Overall this process should reflect what the business wants, hence my stance of not giving my own opinion on it.

      That all said, in a real situation I agree that you must combine the knowledge and methodology to be complete, and thus giving prescriptive recommendations at some point. At least that’s what I do when I thread model something, as more than often, you are not provided with a clear threat intelligence analysis as a intake for the threat modeling process.

      I guess it depends on where the “threat modeling person” places itself. If that lone actor or team does have the threat intelligence knowledge, they can do it. But if they don’t, they better rely on others in order to be more aligned with reality and not misguide the efforts.

      Let’s say that if I were to make a game here, I would have it more open world and then wait to be amazed by what people (could make using their talent, skills and dedication. Conversely, I wouldn’t mind having people buying the same game if all they want is to kill spiders or play in the playgrounds others have designed.

Comments are closed.