A paper by Adam Shostack is circulating the blogosphere, and it is worth a read. I’d already left MS before Adam took over as the gatekeeper of threat modeling for SWI but it is nice to see that he basically agrees with the stripped down version that we regularly did in WinCE and that I still evangilize. Mainly-

1) Draw a data flow diagram (DFD) of how data moves around for your application/feature (depending on scope of the model), and where trust boundries are crossed

2) Enumerate threats. The paper has a nice little matrix of what threats are pertinent to what elements of the DFD and while he applies the necessary conditionals about it being specific to MS and perhaps not being universally applicable, I think it is a pretty good reference in general.

3) Determine Mitigations (or decide to let a threat slide)

4) Validate mitigations that are put in place

We lived by those simple steps, rather than getting into the horrid threat trees and DREAD risk modeling and all of that other overhead. I say this having been the security guy for my area in MS, supposedly the expert, and I ignored them. I can’t imagine the average non-security guy going to that trouble. Granted, being a security guy I probably find it a bit easier to subjectively (wait, am I supposed to say qualititavely now that I am a CISSP?) determine risk from a threat than put a number on it, which is what the overhead in threat modeling was supposed to do, but I think most non-experts can still make an educated guess.

Anyway, the reason I am bringing all of this up is to illuminate one aspect that isn’t touched on much in most threat modeling discussion- Don’t just focus on your process/components. When people create a data flow diagram and start thinking about threats and mitigations they tend to focus on threats specific to their own code and how to mitigate stuff entering that code. However if we look at a vulnerability like XSS, it isn’t a threat to your own code, it is a threat to external entities (in this case, client browsers), and the best mitigation is to sanitize (HTML encode) data as it leaves your application rather than validate it as it enters (now you still need to validate it as it enters to make sure it isn’t malicious to your code, but don’t worry about flat out stopping xss with input validation if you can output encode).

Similarly, in the above web app example, a threat model would have us worry about how to authenticate the client for repudiation and information disclosure purposes, but I haven’t been to many threat modeling sessions where the team originaly considered the data flow the other direction (establishing to the client that this is the server you can trust- more on that in a post in the near future).

So as you are developing your threat model be sure to consider threats to each of the entities in the DFD. Don’t focus only on the flow into your components, and don’t consider threats to just your components, but rather look at the full ecology represented in your DFD.

~ Joshbw