Intent-Based Protections for Your Mobile App

Guardsquare’s recent guided configuration announcement introduces a market-changing approach to app security, streamlining the traditionally complex process of configuring high-level protections. With this intuitive, intent-based security selection, developers no longer need to sift through dense manuals or grapple with complex protection syntax. Instead, they can focus on what they do best—coding and innovation—while Guardsquare optimizes security, quickly achieving the highest level of protection in less than a day. This blog delves into how this powerful configuration capability simplifies the path to robust app security, empowering teams to safeguard their applications with minimal setup effort.

In a previous post, we emphasized the importance of profiling your mobile app as a first step to achieving a successfully protected application. By default, Guardsquare will apply a core level of protection for your app, which is a good starting point as it creates a broad haystack of core obfuscated code throughout your application’s code base. However, in order to protect your app’s most sensitive code or data, further input is required. That is why applying intent-based protection configuration is so crucial to a well-protected build.

The purpose of explicitly defining your desired configuration is to:

• Select the most sensitive areas of code that require additional protection and the strings and assets inside your application that should not be visible during static analysis of your application;
• Enable the desired runtime protection techniques to apply dynamic protection for your application as well as configure the reaction strategy.

Let’s tackle them one by one.

Code and data

The selection of code entities (classes, methods, fields), especially those needing additional levels of protection, requires some careful consideration because there is a good reason that we do not automatically apply the more advanced obfuscation techniques by default throughout the entire code base. Applying the more advanced protection techniques will have an impact on the size and performance of your application. As such, striking the right balance between security, performance, and size is important.

For this step, you, as the app developer, are the subject matter expert and need to make conscious selections based on your in-depth knowledge of your application’s code base, especially the first-party code base. We’ve made that step easy by allowing you to search and select the specific code entities for your application directly. Based on your selections, we’ll ensure these security sensitive entities of your application receive additional obfuscation protections.

As every application has its own functionalities and characteristics there is no one-size-fits-all approach that guarantees optimal security coverage for all applications and use cases.

In the end, the level of protection of your application depends on how well you protect your most valuable assets, secrets, and code. Even if your application has broadly applied obfuscation techniques, adversaries are always on the lookout for the weak spot that could serve as an entry point to prepare for an attack. If that spot is not well obfuscated, it will be identifiable to an attacker.

How do I know which classes and methods require additional protections?

As a general guideline, prioritize quality over quantity. Generally speaking, the number of secure entities requiring optimal protection against static analysis is rather limited, usually, and really depends on your application’s use case. Think about various paths in your code and specific data to protect against static analysis.

• Users and the device are authenticated
• Payment transactions or in-app purchases are initiated or accepted
• PII is being exposed or processed
• Scores or other key-values are being calculated
• A proprietary algorithm has been implemented
• Sensitive data, like API keys or in-app secrets, are being loaded and exposed

• API and encryption keys or other in-app secrets
• URLs and API-endpoints towards your backend, in case your backend is non-public
• Assets or resources that should not yet be publicly accessible

To gain a common understanding of what matters most in terms of security, it might be a good team exercise to collectively identify such entities and data. Also, input from your security team will definitely help in this matter.

RASP

Our general guidance is to enable as many runtime protection techniques as possible that safeguard the integrity of your application and the environment in which it is running. Then, focus on the applied reaction strategies.

RASP checks sprayed throughout your application should be seen as an alarm system, safeguarding your application’s integrity and also when executing in a possibly hostile environment where the attacker controls the mobile device. As such, the runtime protections are orthogonal to the static obfuscation techniques, and both RASP and obfuscation strongly reinforce each other.

Based on the in-depth profiling done in the initial step of the guided workflow, the injected code snippets should not impact performance, and have minimal effect on the size of the app. Your main decision should focus on the desired reaction strategy for specific threats, such as crashing the app, reporting the threat to a backend, or providing some user facing message in the app. While an app-initiated crash does not provide the optimal UX to the end-user, it remains the safest option for protecting your app against the most invasive threats like hooking or debugger related activities.

To achieve a good understanding of the threat landscape that your app is facing after being released, it is important to consider collecting the different signals at runtime for visibility into the environment. These collected threats can give you meaningful insight on what tampering is taking place on your application, on which devices and by which application users. To do this, you can leverage Guardsquare’s threat monitoring solution, ThreatCast, or you can opt to implement your own monitoring solution by configuring a callback function that will automatically get invoked upon the detection of an integrity violation.

Every mobile app developer can be a secure developer

The introduction of Guardsquare’s guided configuration approach shifts the developer’s focus away from digesting manuals, learning about protection configuration syntaxes, and applying the necessary filter lists blindly, toward intuitive, intent-based security selections within the developer’s code base, without the need to learn in-depth technicalities about our security products. As such, it empowers every mobile app developer to quickly become a secure developer.