Threat modelling tools and alternative threats

Question

From looking at threat modelling tools which are available (Microsoft SDL for Threat Modelling is probably the prime example) they seem to consider only threats at a low level, and I get the feeling that they are aimed primarily at developers.

On systems threats are not just from attackers, threats on the cloud can include location or service based threats (eg, laws may require certain kinds of data to be kept within certain jurisdictions, an alternative security problem but an issue nonetheless). This kind of threat is also not 'low level', such as the ones identified in the tools mentioned, but more medium level. These kinds of threats do not seem to be represented in any tools that I can find, and nor are those threats which come from sources other than attackers. My questions are the following:

1. Is 'threat modelling' as a process considered to be one which views threats from a low level only, and one aimed at developers? Because this is the understanding I get from seeing how these tools work. Or is it just that because these tools are used primarily by developers, they have come to prioritise the viewpoints of developers and like minded people?

2. Am I perhaps missing tools which provide information about other kinds of threats? Perhaps tools which consider a higher level view of threats and vulnerabilities? Or those which consider threats from non attackers as well as from attackers? I know that manual processes such as STRIDE and DREAD can allow people to identify threats at whatever level they want, but I am more interested in knowing about tools which might do this.

Answer 1

You're right that the Microsoft tooling is aimed at developers. When we developed the v3 SDL tool, we wanted to focus in on what the developer would likely know about. Managing jurisdiction is a requirement that's going to come from somewhere else. So to your question 1, the current Microsoft threat modeling tooling focuses on developers and prioritizes their needs, and As I discuss in my book, threat modeling is something anyone can do, and everyone should. Unfortunately, the models of attacks outside the very technical are not as well developed.

[Apparently, I'm not allowed to comment, so I'll add a bit more here to your question 2. It's very helpful to define a scope of "other kind of threats." One thing that can sink a threat modeling process is a succession of threats about which you can't do anything. Many of the threats you'll find with STRIDE can be addressed by developers. So what scope are you looking for in #2?]

Answer 2

Microsoft had the wrong terminology when using the word "threat" in "threat modeling". Cigital replaced this incorrect terminology with "Architectural Risk Analysis", which is a much better description. The best model for working with risk analysis is Factor Analysis of Information Risk (FAIR). One only then needs to apply the concepts to app development or software construction.

For tools in this area, be sure to check out

• https://github.com/mozilla/seasponge
• http://babydragon.azurewebsites.net
• http://myappsecurity.com