Mobile Attack Surface

Jim Bird and Jim Manico are working on a new addition to the OWASP Cheat Sheets family, they have a draft cheat sheet on Attack Surface in process. The Attack Surface helps you see where your system can be attacked, from the Cheat Sheet:

"Attack Surface Analysis helps you to:

1. identify what you need to review/test for security vulnerabilities
2. identify high risk areas of code that require defense-in-depth protection
3. identify when you’ve changed the attack surface and need to do some kind of threat assessment"

I would add a 4th - it helps you see where you can defend. I use the Attack Surface Model in combination with a Threat Model to identify and locate countermeasures. The Threat Model helps to identify and the Attack Surface model helps to locate. This point is important because while you can't do much to control the attacker, you can control your defensive posture.

Eoin Keary wondered if there were some special considerations for attack surface analysis on Mobile, and I think there are plenty. Mobile attack surface is one of the main areas that changes the nature of the threat and the field of choice for defenders.

Tyler Shields at Veracode blogged about the Mobile Security stack and showed a number of the key points

I have no quibble with this high level model, in particular there are logical extensions for security people to use at the OS and app layers, but at the same time the Hardware and Infrastructure layers need some elaboration to see why mobile is different. The Hardware is in motion, the Infrastructure layers include many byzantine protocols and format such as GPS, NFC, SMS and harware implementations vary greatly.

Standard use of STRIDE Threat Model + Attack Surface shows how each threat is dealt with so for apps that are using SSL you can see where its mitigating threats across the attack surface

Threat	Countermeasure	Data	Method	Channel
Spoofing	Authentication
Tampering	Integrity Hash
Repudiation	Audit Logging
Information Disclosure	Encryption			SSL
Denial of Service	Availability
Elevation of Privilege	Authorization, Hardened Interfaces

Note that the above should not be viewed as Checkbox Olympics where six STRIDE Threats times 3 attack surface pars always yield 18 countermeasures, this is basically never the case. But what it does do is show where and how countermeasures play in the stack and give you ideas on the most cost effective places to defend.

So our foundational Threat Model + Attack Surface needs some extenstion to deal with Mobile which could include new protocols like GPS, SMS, MMS, and NFC, and which will vary by HW type. Also new application distribution models through App Stores/Markets and updates. Finally there are different assumtions to be made around physical access and the like through the Lost/Stolen scenarios. So a basic extension to Threat Model + Attack Surface view could yield something like the below:

Threat	Counter measure	App  Distro	GPS	SMS	MMS	NFC	Lost/ Stoten
Spoofing	AuthN
Tampering	Integrity
Repudiation	Audit Logging
Inforomation Disclosure	Encryption
DoS	Availability
Elevation of Privilege	AuthZ Hardened Interfaces

Again, as above its not a case of Checkbox Olympics and there are limitations in what can be done in any protocol, but using this combination helps to where we can reasonably expect to place countermeasures. In addition I think a big takeaway for most people is that when you start with the view that Tyler Shields' post showed, you assume that the variability is more on the top layer, but in Mobile you need to assume there is room for much or more variability lower in the stack too.

**

Come join two leading experts, Gunnar Peterson and Ken van Wyk, for a Mobile App Security Training - hands on iOS and Android security, in San Jose, California, on November 5-7, 2012.