Whenever I talk with customers at conferences and meet-ups, I’m invariably asked the same thing about mobile application security testing: What should we test in our app and how should we prioritize issue remediation? People want guidance about how to conduct threat modeling to manage mobile app risk.
Unfortunately I can’t provide a simple answer because it depends on a lot of things. While every mobile app should follow some standard for security, variables include the function of the app, what type of data it handles, and your perspective as either a developer or user.
However, mobile application security managers and practitioners can find app-specific threat modeling guidance from the Open Web Application Security Project, better known as OWASP, a vendor-neutral community for advancing appsec.
- Mobile Top 10: In 2011, OWASP launched the Mobile Top 10 list to identify the biggest security issues to focus on.
- Mobile Security Testing Guide: OWASP developed the Mobile Security Testing Guide (MSTG) to help analysts learn how to test specific areas of mobile app security. This is a great resource but it’s the size of a phone book.
- Mobile Application Security Verification Standard: OWASP created this resource to help mobile app owners, architects and developers figure out how to approach mobile app security verification requirements and testing.
The MASVS domains are as follows:
V1: Architecture, Design and Threat Modeling Requirements
V2: Data Storage and Privacy Requirements
V3: Cryptography Requirements
V4: Authentication and Session Management Requirements
V5: Network Communication Requirements
V6: Environmental Interaction Requirements
V7: Code Quality and Build Setting Requirements
V8: Resiliency Against Reverse Engineering Requirements
We recommend using MASVS as a starting point for developing a mobile application security plan of attack. The resource translates a threat model into security requirements to standardize the level of testing necessary to manage risk. This is known as the Mobile AppSec Model.
As we test apps, it’s always important to have a baseline and understanding of why certain issues are important. Our goal with the Mobile AppSec Model is not to test less, but to help managers make better decisions on what needs to be remediated right away. With that goal in mind, the ability to determine where an app falls in the model will lead to better decision making.
While each app is different, most can fall into one of four categories of verification requirements. The level of testing varies from basic mobile app security to defense in-depth apps and those that require reverse engineering resilience as illustrated in the diagram below.
Let’s walk through a few examples of different types of apps and where they fit on the quadrant. Say you have a mobile app that lists bus public transit bus schedules. This requires only minimal security because it has limited functionality and doesn’t require much in the way of user interaction. Nor does it collect personal information, so it would be a L1.
Next, we have a business expense app that handles highly sensitive data such as receipts and transactional information. However, expense repayment is not handled within the app itself. This would require L2 security.
A popular gaming app or video streaming app would fall into the third quadrant, L1 + R. That’s because the producers want to prevent cheating or protect their streaming content. If someone figured out how to steal movies, the app maker would get into trouble.
Finally moving to the most complex apps, let’s say you have a healthcare messaging app or a financial transaction app. Not only do these require defense in depth and reverse engineering resilience to safeguard data, but are also subject to regulatory compliance. These would be L2 + R.
To assist you and fellow security analysts, architects and managers apply the mobile appsec model to their mobile app portfolio, NowSecure recently created a companion resource to MASVS. Download “A Manager’s Guide to the OWASP Mobile Security Project: Building & Executing Risk-Based Security Policy for Mobile Apps” to learn how to standardize and scale mobile app security testing.