Mobile App Shielding, originally known by the less friendly name RASP, which stands for runtime application self-protection, has become a popular feature in mobile banking. Security and regulatory compliance requirements, particularly the PSD2 standards on Strong Customer Authentication, are driving demand for App Shielding solutions that claim to protect mobile runtime (SCA).
Wherever there is a demand, supply will soon follow. As a result of the proliferation of smaller mobile app protection solutions, the industry has become fragmented. I mean, how could it be? At first glance, all of the goods appear to be identical. The list of value propositions is relatively similar, and it is frequently duplicated from numerous websites.
App Shielding is used for app security rather than app audits.
Before we go into detail about the things you should look for, we’d like to ask you a question:
Why are you thinking about investing in App Shielding? Is it because you want to check off green boxes in your yearly security audit report, or because you want to do both and prevent attackers from posing a threat to your app’s users?
If you fall into the first group and your motivation is purely formal, you should stop reading now. You may probably choose any cost-effective solution, create an information fog around the auditor, and pass with flying colors despite providing inadequate protection against genuine cyber threats.
If, on the other hand, you’re in the second group, and you’re using App Shielding to really block attackers, you’re presumably aware that the technology must function under harsh settings. The mobile device has already been substantially hacked, and there is a proactive bad actor in place that is deliberately attacking your banking app. As a result, the App Shielding solution must rely on hacks at the cutting edge of the iOS and Android platforms.
Tip 1: Native Module Low-Level Implementation Is Required
Make mobile programming languages compile into high-level executables that are unstable. On iOS, Swift code is compiled into an executable bundle that is toughened in some way. However, Objective-C code that generates dynamic dispatch after compilation, as well as Java or Kotlin code on Android that compiles to bytecode /.dex, may be readily decompiled into readable source code. Obfuscation of the code is a partial solution.
Obfuscation, on the other hand, is only a slight annoyance to a skilled hacker’s eye. It’s not just static analysis that’s a difficulty, but also dynamic analysis “in real-time” (examining a running app). When code is written in a high-level mobile programming language, the executable is vulnerable to memory management and runtime failure.
This is why the best App Shielding systems employ a native core implementation written in C/C++ to obtain total memory management control, stronger resilience against runtime manipulation, better resistance to reverse engineering, and — as a bonus — superior performance (with advanced App Shielding, speed also matters).
Tip 2: No-code delivery and automated app bundle processing
You should generally stop listening if the App Shielding solution pitch stats with “Integrate with just a handful line of code.” If you need to manually integrate and start an SDK, you’ve already lost the war. The protection is applied too late in the lifespan of the mobile application.
Opposite to that, by automatically modifying the app bundle either during build time (as a compilation step) or after it (modifying existing *.ipa or *.apk files), you gain the advantage of changing the actual app bundle. This allows hooking into the narrow time slot during which an app is loading, for example, while the Zygote process fork occurs. This means that the protection is active before the attacker can perform any malicious activity that would draw your app protection pointless.
Naturally, many powerful App Shielding systems offer an extra SDK as an add-on that enables for more fine-grained handling of certain scenarios and security-sensitive circumstances. The automated implementation, on the other hand, remains at the heart of their operation.
By simply inserting the App Shielding into your CI/CD pipeline, you will obtain a more efficient delivery as a part of your DevSecOps principles.
Tip 3: In well-defined scenarios, exclude some mobile app users.
A vendor that guarantees that no users will be barred from accessing the app once it has been protected with App Shielding is most likely executing App Shielding incorrectly. A lack of in-depth expertise, especially in the most essential areas that address security corner situations, is frequently the reason for such a promise. Assuming a device has been extensively changed, app protection can only terminate the mobile app, so eliminating some app users.
We discovered that roughly 5 out of every 100k app users has their device so severely customized that no security measures can be guaranteed to operate. This is usually a mix of device jailbreak/rooting and additional hacks, such as hacker tooling installed on the device (Frida, Cydia Substrate) and active injection scripts.
