Principles / 03 Develop a threat model for your application
A guide to mobile application protection
- Introduction
-
Principles
Overview - The big picture
- What needs protecting
- Develop a threat model for your application
- The four layers of mobile application protection
What is a mobile application threat model?
A threat model is designed to identify three key elements:
Assets
Parts or components of your mobile application that an attacker is likely to target.
Threats
Modes of attacking your mobile application.
Controls
Security and protection mechanisms you can employ to deter the identified threats.
Why you need a threat model
A mobile application threat model provides you and your team with complete visibility of your app from a security perspective. It shines a light on the assets, how they might be attacked or compromised, and how you can protect them. This in turn allows you and your team to develop and deliver a safer mobile application for your end users.
A threat model also stops security vulnerabilities from getting all the way into the final product as early as possible. It can act as a solid foundation for testing and QA teams to write proper test suites. This helps to make sure that every line of code you write is safe and that all required or necessary security controls are in place and are working properly.
Having a threat model is also evidence that you’ve put robust security measures in place and have thoroughly considered protection throughout the mobile application lifecycle. This can help you to achieve industry compliance with regulations. And it can act as reassurance for your end users that you take security seriously.
Should you decide you need support from a third-party vendor to help protect your mobile app, a threat model can act as a requirements checklist, too. It can work as a quality gate to help you filter, compare, and choose the most appropriate protection solution.
The mobile application threat modeling processes
The best threat models are those created in a way that makes it convenient and easy for you and your team to understand them and communicate them with one another.
Try to position your threat model from the attackers' perspective. As difficult as it sounds, you have to attempt to step into their shoes and think the way they would think. That’s why asset-centric threat modeling is the most effective and realistic approach you can take.
It consists of the following steps:
Identify assets that might be targeted by attackers and are worth protecting
The first step is to identify exactly what needs to be kept secure and protected.
As mentioned elsewhere in this guide, assets can be divided between three main categories:
Internal data and intellectual property (IP)
e.g. business logic; proprietary algorithms; cryptographic keys; API keys; databases; media files
Restricted functionalities
e.g. authentication; payments and transactions; in-app purchases; access to DRM-protected content; access to private data
Sensitive user data
e.g. personal identifying information (PII); authentication credentials; location data; biometric data; user-created content
All apps contain internal data and IP in their binaries; many provide restricted functionalities to authenticated users during runtime; and the majority process or provide access to sensitive user data.
The precise balance of assets and their relative value to the attacker will vary from app to app. An important element of devising a threat model is to identify the exact assets, their value, and the threats they face, starting with how they may be accessed by an attacker.
Analyze your mobile application and points of exposure
The next step of the threat modeling process is to gain some understanding about how your system is built, and identify potential points of exposure for assets. It’s crucial for you to understand the internal and external components of your mobile app, including any data that may flow through it or which is contained within. This process is often called decomposition.
Internal components are:
- Embedded directly within your mobile application (the app package or bundle), or
- Provided by the OS or platform solely for your mobile application to use.
These include:
- Code files and executables: These represent the very core of your mobile application. Code files and executables contain all necessary business logic required for your application to function properly. In a native Android application this will be packaged in Dalvik Executable (DEX) and Executable & Linkable Format (ELF) files, as well as native libraries (.so files). In a native iOS application it will be in the form of Mach object (Mach-O) files. And for hybrid apps this extends to files containing JavaScript, (compiled) Dart code, plus assemblies depending on the framework used.
- Non-code application resources: All non-code files required for your mobile application to provide its functionality to end users. This typically includes user interface (UI) files and application metadata.
- Runtime memory: This refers to a virtual memory region of your mobile application. A space typically used to contain the application runtime (like Android Runtime or Objective-C runtime for iOS), all code files and non-code resources loaded from your application container (binary), string data, and system libraries requested by your mobile application.
- App-specific storage: In Android and iOS, mobile applications are sandboxed (or isolated) from each other. The OS provides your mobile application with a dedicated and private storage space that can only be accessed by your mobile application. This space is typically used to store data at rest, from non-sensitive ones such as user preference and configuration files to sensitive ones like persistent authentication tokens.
External components refer to those that are not integral or specific to the application, but which nevertheless interact with it directly, including:
- Interprocess communication (IPC) mechanisms: An OS component that handles the communication between your mobile application process and other app processes or system processes. Any type of communication including: transmitting or sharing data to, accessing data from, calling functions, methods, or entry points of, other processes will go through this component. In Android, this process is typically handled under the hood by a component called Binder.
- Remote endpoints: Components that enable apps to communicate with external servers and data stored remotely.
- Shared storage: Storage space that is available and accessible to every app and service on a device. Typically, the shared storage is used for any data that can or should be accessible to other apps and stored even if the user uninstalls your mobile application.
Once you have all the information you need about your mobile application, you can start to model it. You can represent it in a visual form like a diagram, a table, or any other way that makes it convenient for you and your team to understand it and reference it collectively.
Here’s an example:
| Component Boundary (Attack Surface) | Component Name | Typical Asset(s) targeted by attackers |
|---|---|---|
|
Internal |
Code Files and Executables |
|
|
Internal |
Runtime Memory |
|
|
Internal |
App-specific storage |
|
|
External |
Remote endpoints |
|
|
External |
Shared storage |
|
|
External |
IPC drivers |
|
What needs protecting
At this stage it might be helpful for you to refer back to our page about What Needs Protecting for additional assets that you can identify or discover from your mobile application.
Identify how attackers might target your mobile application assets
Now that you’ve identified your app’s assets and how they might be exposed, you can begin to assess how attackers could target and exploit them. The following pages in the Threats section of this guide are there to help you learn more about this topic. And resources such as the OWASP Mobile Application Security Testing Guide provide more information on how security testers (and attackers) probe apps for points of exposure.
Identify the appropriate security controls and mitigation techniques
Once you have a list of assets linked to the tools and techniques attackers use to exploit them, the next step is to identify the appropriate security and protection measures required for prevention and mitigation. Be careful though not to take a simplistic check-box method in threat mitigation. The best approach for protecting your mobile application is via a holistic and multi-layered defense that combines secure development with specific threat detection and comprehensive in-app protection.
For example, data-at-rest encryption might deter attackers with elevated privileges from compromising sensitive data in the file system. But detection of privilege escalation can also be implemented to prevent the app from operating with any sensitive data if privilege escalation (via rooting or jailbreaking) is detected.
And keep in mind that these protection measures themselves also need to be protected. After all, a root detection module is next to no use if it is not combined with protection against dynamic instrumentation frameworks and binary modifications. That’s why it’s crucial to focus on multiple mutually reinforcing layers of security and protection.