1 Raindrop: Using Threat Models

Threat models are a very good way to make implicit security threats and mechanisms, into explicit threats and mechanisms, so that you can write requirements, build, and test that they do the job you intend. As a starting point, I like to use a modified version of STRIDE, which among other things cleanly maps threat to mechanism. This way when starting a new project, for example with SOA Web services, you can identify where the standards will help you.

Threat	Mechanism	Example Standard
Spoofing	Authentication	WS-Security
Tampering	Digital Signature, Hash	WS-Security + XML Signature
Dispute	Audit Logging	None
Information Disclosure	Encryption	WS-Security + XML Encryption
Denial of Service	Availability Services	None
Elevation of Privilege	Authorization	None

Threat models are misunderstood, they are not about modeling threats. As defensive programmers, we have little to no control over threats, our job is to find and fix vulnerabilities. So why bother with threats and threat modeling at all then? It turns out that vulnerabilities are basically passive weaknesses, and the threat is the catalyst that exercises the vulnerability so that we can 1) identify it and 2) deal with it.

So the end result of threat modeling is not a list of threats, but rather a list of countermeasures. And not just a generic list either. The active ingredient (threat) gives us a way to locate where the countermeasure can/should live in the architecture.

Further, if we are comparing approaches early in architecture/design phases of building software, the threat model is a structured back of the cocktail napkin way to compare/contrast approaches. For example if we are looking to build out a set of Web services and are choosing between SOA style (WS-*) and REST style, we may want to look at the readily available implemented standards that each software security stack supports

Threat	Mechanism	Example SOA Standard	Example REST Standard
Spoofing	Authentication	WS-Security	XML Signature (response only)
Tampering	Digital Signature, Hash	WS-Security + XML Signature	XML Signature (response only)
Dispute	Audit Logging	None	None
Information Disclosure	Encryption	WS-Security + XML Encryption	XML Encryption (response only)
Denial of Service	Availability Services	None	None
Elevation of Privilege	Authorization	None	None

Threat modeling gives a concrete structure to a fairly abstract subject like analyzing software security capabilities in services, but as you see its not about the threats its about the security architecture elements. This is just an illustrative example not a complete threat model, but it does give an effective, context-sensitive way to look at tradeoffs in security architecture. In this example, SOA/WS-* has potentially more coverage the security mechanisms work on both the request and response side. In the next series of posts, we'll look slicing and dicing the threat model a layer deeper and how we can use it secure our services.

Update: Using Attack Surface with Threat Models