Since joining SensePost I’ve had a chance to get down and dirty with the threat modeling tool. The original principle behind the tool, first released in 2007 at CSI NetSec, was to throw out existing threat modeling techniques (it’s really attack-focused risk) and start from scratch. It’s a good idea and the SensePost approach fits nicely between the heavily formalised models like Octave and the quick-n-dirty’s like attack trees. It allows fairly simple modeling of the organisation/system to quickly produce an exponentially larger list of possible risks and rank them.

We’ve had some time and a few bits of practical work to enhance the tool and our thinking about it. At first, I thought it would need an overhaul, mostly because I didn’t like the terminology (hat tip to Mr Bejtlich). But, in testament to Charl’s original thinking & the flexibility of the tool, no significant changes to the code were required. We’re happy to announce version 2.1 is now available at our new tools page. In addition, much of our exploration of other threat modeling techniques was converted into a workshop of which the slides are available (approx 30MB).

The majority of the changes were in the equation. The discussion below will give you a good idea of how you can play with the equation to fundamentally change how the tool works.

There are 5 values you can play with in the equation:

1. imp – the impact of a risk being realised
2. lik – the likelihood of the risk occurring
3. int – the value of an asset (represented by an interface to that asset)
4. usr & loc – the measurable trust placed in a user & location respectively

The current default formula is:

In English that translates to: The risk is equal to; the average of the impact of the attack and it’s likelihood, combined with the value of the asset (exposed through a particular interface), and reduced by the trust of the user performing the attack and the location they are performing it from.

We felt there were two problems with this equation:

1. It doesn’t acknowledge impact as linked to value. e.g. You can’t have a huge impact on something of low value.
2. It doesn’t see trust as linked to likelihood. e.g. a trusted user in a trusted location is less likely to commit an attack.
3. It double weights trust with location and user trust counting at full weight.
4. It’s maybe a little far from semi-consensual views on the subject

After much internal wrangling, and some actual work on modeling fairly complex stuff, we came up with a new equation. While we feel this works better, it does mean the way things are modeled changes, and hence backwards compatibility with existing models is broken (but you don’t need to use this equation). The new equation (consider the risk= implied) is:

Once again in English: The risk of an attack is; the likelihood of the attack reduced by the average of both the trust in the user & location, combined with, the value of the asset reduced by the potential impact of the attack (value at risk). (The 0.2 & 2.5 are just to make it fit the scales. Specifically, the 0.2 is because the scale of the entities is 1-5 and we’re looking to make a percentage, and the 2.5 is to fit the 0-25 scale on the final graph.)

The key change which breaks backward compatibility here is that impact now becomes a moderator on value. i.e. the impact of an attack determines how much of the asset’s value is exposed.

The way things are now modeled, interfaces represent the value of a system. For the most part, all a system’s interfaces should have the same value, because as we often see, even minor interfaces that expose limited functionality can often be abused for a full compromise. However, the actual attack (called threats in the tool) determined how much of that value is exposed. For example, a worst-case XSS is (depending on the system of course) probably going to expose less of the system’s value than a malicious sysadmin publicly pwning it (once again, dependent on the system and controls in place).

Unfortunately, there’s still no provable way to perform threat modeling, but we feel we can go quite far in providing a quick and useful way of enumerating and prioritising attacks (and hence defenses) across complex system.

In a future blog post, I hope to cover some of the really cool scenario planning the tool can let you do, and the pretty graphs it gave us an excuse to justify budgets with.

[ Credit to the Online LaTeX Equation Editor for the formulas, although if you’d like to copy paste the formula described above into the tool, here’s an ascii version:

( ( ( lik * ( ( ( (6 – usr) + (6 – loc) ) / 2 ) * 0.2 ) ) + ( int * ( imp * 0.2 ) ) ) * 2.5 )

]