Using Attack Surface in Threat Models

Last week, I blogged about using threat models to identify and locate countermeasures. Now, I would like to add a little more detail and context. Recall, the purpose of the threat model is to map threats to countermeasures, but he catalyst comes through some part(s) of the attack surface. There are several attack surface models out there, I use a simple one where the attack surface is the sum of the data +  method + channel, that entail the ways the system can be attacked. 

So in an example Web services application we would have an attack surface that includes

• Data: XML
• Method: SOAP or HTTP Verbs 
• Channel: HTTP 

Relating the attack surface construct to our threat model yields interesting possibilities for countermeasure combinations and permutations. Let's assume you are doing security design for a REST Web service and are looking at the constraints and capabilities that REST, HTTP, XML and other standards will help you deal with threats. The combination of the attack surface model and threat model gives you a way to be more precise with mapping countermeasures to threats.

 

Threat	Countermeasure Located in Attack Surface
	Data	Method	Channel
Spoofing	XML Signature (response only)	None	TLS/SSL
Tampering	XML Signature (response only)	None	TLS/SSL
Dispute	None	None	None
Information Disclosure	XML Encryption (response only)	None	SSL
Denial of Service	None	None	None
Elevation of Privilege	Oauth	Oauth	None

This is just an example, but the attack surface is a nice refinement for drilling down on the countermeasure side of the threat model ledger. The location context gives the security designer some flexibility in finding cost effective ways to address security in the software design. In a nutshell, the threat model identifies countermeasures and attak surface locates the countermeasures in the software architecture.