Avoid Mobile Application Security Pitfalls -2

Secure the Development Life Cycle

Mobile application security testing is the main component of a secure life cycle. Before conducting the testing itself, it is useful to create a scope document for the app, listing the permissions used, the level of sensitivity of data and the use case. For example, is the app published on a commercial app store where it can be downloaded by consumers, or will it run on managed mobile devices, where a UEM performs compliance checks? This information should be used to determine how much time the team will spend making the app secure and what kind of additional protection may be used. Additionally, it is mandatory to perform a threat modeling exercise.

Perform Application Security Testing

To ensure secure coding best practices are followed and identify any vulnerabilities introduced in the application, enterprises should conduct security testing on the application. Keeping in mind that a mobile application is composed of two portions: the app that resides on the mobile device and the back end. There are two levels of mobile application security testing. The first one analyzes the mobile app’s source (the portion on the device), byte or binary code statically. This testing will allow issues such as unsecured storage to emerge. The  OWASP Mobile Top 10 can serve as a list of what should be identified in this phase as a minimum. SRM leaders should ensure to test the entire app, including any libraries it may be using.

One peculiarity with mobile application development is that even the most mature organizations will conduct it in a DevOps fashion. Often the apps will be written within a line of business, and there will be weekly refreshes. This requires a mobile app security testing solution that is easy to run and fast to provide results. The second level of mobile AST is composed of not only the code residing on the mobile device but also its interaction with (one or more) back ends. Some vendors will provide the first level as a free service and the second one as a paid service.

For critical applications, organizations should perform penetration testing periodically. This exercise may identify risks that the automated solutions may not be able to. For instance, the app or its back end may be vulnerable to specific techniques such as API scraping or password spraying, which an automated scanner may not run. This effort should focus on the business logic of the application.

Externalize Security Controls

Unless there is significant security internal know-how, organizations should avoid creating and implementing their own security controls. Most of the security issues identified with mobile apps are linked to incorrect implementations of cryptography, authentication and other security functionalities. SRM leaders should instead identify and standardize key security components. Look at your existing multiexperience development

platforms and access management solutions for functionality such as integrity checking, jailbreak/root detection, authentication, authorization, tokenization and encryption. MX platforms and Git environments can also help set up and govern the application development and deployment process.

Some organizations with enough internal expertise and resources have managed to correctly build their security controls in-house. Carefully reflect on the effort you can dedicate in the long-run before taking that route. Over time, with new attacks and threats and respective new defenses, controls will become obsolete and inefficient, requiring ongoing maintenance that can become overwhelming. In fact, we have observed organizations that have built their own controls, only to have to dismantle them and look for external functionality. For workforce-facing apps, some of this security functionality can be provided and standardized via UEM tools.

When Needed, Go Beyond the Basics

When applications are critical, SRM leaders may need to go beyond the security controls illustrated so far. To identify candidate apps for these measures, there are three signs to look for:

The app carries highly sensitive data or can be used for transactions.

The app is public, either because it is published on a commercial app store or is a consumer app.

The app has a significant portion of the software logic that resides on the device.

Harden Applications Against Reverse Engineering

Apps, especially ones published on commercial app stores, are frequently the victim of reverse engineering. Attackers reverse engineer applications to understand how the application works and how it can be attacked, to steal the data within the app, and also to clone the application. In this last case, also called “repackaging,” the attacker adds malicious behavior and then reissues the app. Unaware users may think they are downloading and using the legitimate app, accidentally handing over their banking credentials, for instance. Application hardening can make it more difficult for attackers to reverse engineer an application.

Code Obfuscation

To protect from repackaging, SRM leaders can use code obfuscation. Obfuscation scrambles (rather than encrypt) the code, making it harder to review and repurpose the code. There is not a single technique, but a multitude, from renaming portions of the code or changing its sequence to adding unused code and many others.

Obfuscation is a dissuasive measure. In most cases, a determined and skillful attacker will be able to recompose the application, but the effort and time dedicated may not be worth it.

White-Box Cryptography

This term refers to the set of techniques used to hide and protect sensitive application data such as keys and credentials stored in an app on a device. This can be used as an alternative when someone does not want to rely on native resources such as the previously mentioned iOS Keychain. This can be the case when, to increase adoption, the organization wants to allow its app to run on jailbroken devices, which cannot benefit from iOS Keychain protection. In other cases, the rationale for white-boxing is that the attacker sees the default location for credentials on a device as the first place to try to attack. Therefore, moving the credentials elsewhere avoids these attacks, despite all the fortifications that credential storages have on devices.

Mobile App Monitoring

For completeness, an alternative or addition to hardening the app against reverse engineering is to scout for modifications and cloned versions of the applications. 

Verify the Environment Can Be Trusted With Anti-Tampering Controls

Public-facing apps need to be able to verify whether the device they run on can be trusted, and to what degree. To do so, SRM leaders can add anti-tampering controls to the application. Typical functionality are checks for the presence of a debugger (one of the tools used when conducting reverse engineering) or an emulator, in addition to checks for jailbreak or rooting.