Principles / 03 Develop a threat model for your application

A threat model is designed to identify three key elements:

Parts or components of your mobile application that an attacker is likely to target.

Modes of attacking your mobile application.

Security and protection mechanisms you can employ to deter the identified threats.

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 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:

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:

• e.g. business logic; proprietary algorithms; cryptographic keys; API keys; databases; media files

• e.g. authentication; payments and transactions; in-app purchases; access to DRM-protected content; access to private 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.

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:

These include:

External components refer to those that are not integral or specific to the application, but which nevertheless interact with it directly, including:

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:

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.

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.