Why You Should Consider Mobile Threat Monitoring

When interacting with Guardsquare customers and prospects, we’re often surprised by the number of companies still in the dark when it comes to visibility into the security of their app after it has been released. During such discussions, I like to refer to the analogy with other monitoring tools, like crash and performance reporting, which are commonly used by all. Using these tools makes total sense because it allows app developers to intervene with hotfixes when observing spikes, such as when there is a significant increase in the number of crashes reported on certain device types or OS versions. Or, mobile development teams could choose to define UX improvements for future release cycles based on observations around usage and performance of the app.

Why not do the same when it comes to your app’s security? That’s where mobile threat monitoring comes in. Mobile threat monitoring allows developers to do the same thing as crash and performance monitoring tools, but from a security point-of-view. This enables app developers to react in real-time against imminent threats and give them the broader insights necessary to enforce their app’s security in future releases.

Introducing ThreatCast

In 2020, we launched our mobile threat monitoring console ThreatCast. How has the journey been so far? Just like our customers, we have learned a lot. While developing the initial product, we were unsure what to expect regarding the types of threats and the amount of data we’d uncover.

That’s why our initial focus was on the tool’s ease of integration to keep the barriers for adoption low. All it takes for users to get started with ThreatCast is to register the app in the dashboard, include the generated API-key within the DexGuard or iXGuard configuration file, and update the config file as part of the regular build cycle. ThreatCast will start automatically monitoring once the build is deployed.

As you can see, ThreatCast is straightforward to integrate and can immediately provide in-depth visibility into your app’s security after publication. Our customers are using these threat monitoring insights in a variety of ways to improve their mobile app security posture. Here are three different customer stories that showcase the usefulness of mobile threat monitoring.

Use Case: Feeding real-time threat monitoring data into an internal anti-fraud system

The security team of a large European bank reached out because they wanted guidance for allowing or disallowing the usage of their apps on rooted and jailbroken devices. While the related escalated privileges don’t have direct implications on their app, the privileged access to things like system files could lead to specific attack scenarios.

The company was a long time Guardsquare customer, but had only used our products for static app protection and hadn’t implemented any runtime protections for their app. So we suggested they start enabling RASP detections in their app in combination with threat monitoring. The initial focus was on quantifying the threat by monitoring only, so the developers enabled RASP checks without crashing the app upon a detected integrity violation.

Since ThreatCast was simple to integrate, the company actively started threat monitoring by the next release of their app. For a couple of release cycles, they were just collecting data and were surprised by the relatively low number of rooted or jailbroken devices connecting. In fact, less than 1% of the app’s active users were using rooted devices. Based on the initial insight, whether to allow or disallow their usage did not seem that essential.

But then the company dug deeper into the data and observed a recurring pattern: There was a strong correlation between the usage of a rooted device and the detection of a binary tamper attack originating from the same device. A significant population of the rooted phone users seemed to be using the escalated privileges of their device to access system files and modify system libraries before executing a direct attack toward the app.

With the next release of their app, the company implemented the user identifier to accompany the threats so the developers could identify malicious actors and take immediate action against them. Additionally, the company started feeding the data into its anti-fraud system with real-time feeds from mobile threat monitoring, enabling them to build more fine-grained fraudulent-user profiles.

Thanks to ThreatCast, the company’s main lesson learned was that they do not necessarily need to make the app crash for every rooted or jailbroken device, but as a precaution, they could limit the usability of the app on rooted or jailbroken devices. The company continues to block users and transactions in real-time thanks to the data from ThreatCast.

Use Case: Sunsetting older app releases and shortening release cycles based on insights from threat monitoring

A popular app containing premium features got hacked frequently, and it had a direct impact on the company’s revenue. For example, mods unlocking the app’s premium content for free often appeared on obscure stores.

The organization became a Guardsquare customer to implement application hardening and utilize threat monitoring to figure out what was going on after the app was published. Thanks to ThreatCast’s capability to identify the locations of the attacks in their code, the company was able to reinforce the security config of their app with every release. And they continue to do so.

In addition, they learned that attackers are not only targeting the latest version of their app, but also older versions. With this knowledge, the company decided to sunset the older versions, only allowing its users to use the three latest releases. Since DexGuard and iXGuard use a polymorphic approach, every release will be obfuscated differently. That means every new app release resets the clock for attackers, forcing them to restart their reversing engineering efforts from scratch. As a result, sunsetting older releases on a regular basis has been a very effective measure. The company also decided to shorten its release cycles based on insights from ThreatCast, such as how long it takes attackers to perform specific attacks against their app.

Use Case: Internal efficiency-gain by opening up threat monitoring console to own Customer Support team

A large financial institution was already using ThreatCast for a while, but the company’s support team was getting occasional complaints from end-users about the app crashing. The support team was totally in the dark about the exact reason for the crashes, so all they could do was to take a note of the complaint and forward it to the mobile engineering teams to investigate what went wrong.

This not only led to unhappy customers, but was also frustrating for the developers who already had a hard time meeting release schedules and were confronted with these types of hiccups.

Since the usage of a threat monitoring tool like ThreatCast is very straightforward, the customer decided to open up the dashboard to its support team. Doing so allowed the support team to simply enter the internal customer ID in the search field to see all related security incidents of that user at a glance. This enabled the customer service representatives to reply to customer complaints on the spot. The ThreatCast data explained not only why the crash occurred, but also how it was observed. Opening up ThreatCast to another department within the organization led to faster response rates for end-users and resulted in reduced stress levels for the mobile engineering team.

Consider Mobile Threat Monitoring

Here are three key takeaways from mobile threat learnings based on visibility gained from ThreatCast:

1. Enrich your data for more actionable insights. When looking for patterns and connecting dots between individual events, the actual threat data is important but the so called metadata also matters. This metadata could include which app version is being used, on which type of device, where in the code the threat was detected, etc. These data enrichments, which are basically limitless when you integrate the data from our threat monitoring console with your other backend systems, will provide you with the necessary insights to define multiple threat profiles of those actors with a fine level of granularity.
2. Consider discontinuing or sunsetting old app versions. Older app versions still remain vulnerable to attacks as long as you keep supporting them. It is great that you improved the security of your app in later versions based on insights from threat monitoring, but an attacker will always look for the easiest entry point. As long as you don’t force the user to upgrade, they will likely stick to the version they currently have. Insights from threat monitoring can of course help you with the decision of obsoleting some older versions at some point, without necessarily forcing all your users to upgrade on the spot with every app release.
3. iOS is not safer than Android. Of course more restrictions apply to the platform itself and the variety of devices that can use it are limited, but, despite Apple’s continuous efforts, jailbreaks still exist for every iOS version. Even worse, using a jailbroken device really is not a prerequisite for many common attacks, like premium feature unlocking or in-app memory tampering. But having access to the escalated privileges of a jailbroken phone is often an enabler to install specific DBI tools and sideloaded apps. From the data we see from ThreatCast, the same types of attacks occur on both platforms, only they usually take a little longer on iOS compared to Android. Creating this awareness within your company can simply start by enabling threat monitoring for your iOS app and observing what's happening.