The large app sec vendors are only now starting to recognize the mobile gap in their portfolio - that an SDK in mobile apps is needed to eliminate the growing mobile threat. But SDKs differ in how they gather and use contextual signals. This blog shows how to choose the right one and integrate it with your app security quickly to eliminate the threat from hacked apps and devices. For some time the large application security vendors (i.e. legacy WAF providers) have been enhancing their bot and API offerings by buying promising startups and (somewhat) integrating them into their existing products. API security vendors, bot management startups, RASP startups have all been acquired in an attempt to create what Gartner called a WAAP (Web Application and API Protection). These vendors have however been neglecting the real and current danger presented by mobile apps.
How App Security Vendors Have Enhanced Their Non-Mobile Offerings
Just some examples: F5 bought Volterra (API Security and Shape Bots). Akamai bought Noname and Neossec (API Security). Imperva bought Prevoty (RASP), Distil Networks (Bots) and Cloudvector (API Security). RADware bought ShieldSquare (Bots). The list goes on…
Unsurprisingly, the technical integration and market positioning of these new offerings did not always go to plan - it's never been easy to integrate acquired companies and some enterprises are better than others at doing this. However, in principle, most of the big app security players now present the Gartner WAAP vision to their customers: an integrated cloud-based (i.e. back end) solution covering bot management, API and DDos protection as well as a traditional WAF. In fact, “one stop shopping” is a key element of their value proposition.
These back end tools may be effective for web bot detection, but may lead to false positives as they rely on behavioral patterns that might flag certain legitimate interactions as suspicious - leading to service disruption for genuine users (e.g. Captcha etc.). On the other hand, some threats may pass unhindered due to a lack of contextual information from the client environment.
This leads us to the real issue: All of this is based on one premise: that all threats can be observed, managed and blocked from observing the requests and traffic arriving at the backend APIs or servers. And as we will argue, even with the most sophisticated AI and ML analysis, this premise is wrong for mobile apps and the devices they run on.
Combining the two can be very effective however. You can actually easily build defenses that continue to use the backend app security you have and inject best-in-class mobile protection.
The Need for a Mobile SDK to Provide Comprehensive Protection
Mobile originating traffic is now well above 50% of internet traffic. Customers are starting to understand the risk and are requesting enhanced protection against mobile originating threats. Mobile apps are easily modified and the environments they run in can be hacked, exposing them to a multitude of runtime threats.
Attackers can easily generate traffic that mimics the behavior of a mobile app by sending HTTP requests that are similar to those sent by authentic applications. Attackers might even log in as a valid registered user in those cases, and perform automated tasks, such as content scraping and other web attacks, from their attacked HTTP client tool.
You can only reliably counter threats from your mobile applications by using a Mobile SDK in your app. This can provide continuous verification of contextual information from the app and the client environment and the only way to get this information effectively is by embedding an SDK in the mobile app.
Two Different Kinds of SDK for Bot Detection
When it comes to mobile SDKs for bot detection, there are two primary approaches: 1) analyzing user behavior signals which try to distinguish human behaviour and 2) software-identity signals which detect problematic software and manipulation on devices.
User-Behavior Signals
This is by far the most common approach, usually trying to adapt techniques which have become common in browser-based human behavior detection and trying to use CAPTCHA type challenges. User-type approaches sometimes try to capture nuanced behavioral patterns of sophisticated bots that closely mimic human interaction. This can be hard to do and processing and analyzing large volumes of behavioral data in real-time requires significant computational resources, potentially impacting overall system performance. Also, this approach, by its very nature, generates false positives and negatives and managing these without disrupting user experience is always a challenge.
When evaluating such an approach, it's important to look at the richness of behavioral signals collected and to try to understand the analysis in order to evaluate the risk of false positives/negatives. This can be difficult because vendors tend not to provide details of what is captured and ML approaches by their very nature are obscure. Requesting false positive/negative statistics from existing installations may provide useful data. Any approach to presenting user challenges should also be carefully evaluated in terms of user-experience. Performance impact overall must also be carefully evaluated.
Software-Identity Signals
Device-based signals can offer certain advantages in accuracy and provide a more deterministic approach in general. This approach can accurately identify known problematic software or configurations on a device, providing clear indicators of bot activity. Device and app fingerprinting techniques can effectively recognize repeated automation attempts from the same device, even if other characteristics change. Often however, such mobile SDKs collect only minimal data about app interaction (in order to avoid issues with managing user identifiable data).
When evaluating such an approach, it is important to understand the quantity and quality of the checks performed on the device environment. Some solutions only verify if devices are rooted or jailbroken and provide no other data. On the other hand performs dozens of checks on the device. Different client environments such as iOS, Android and HarmonyOS should be covered. You should also check how legitimate users with uncommon software configurations (e.g. gamers) might be incorrectly flagged as bots - this means it's important that a solution provides granular management in real time of the checks available to be able to address different use-cases and threats. Finally the vendor's approach to identifying new emerging threats, and the ability to deploy updates to address these immediately should be assessed.
Are There Mobile Specific Offerings from Akamai, Fastly and Others?
Some of the big app security vendors have realized mobile security is a gap in their portfolio as their customers ask for better defenses against mobile originating traffic and are either developing their own SDKs or partnering in an attempt to fill the gap.
This section describes the approach of some key large app security players to approaching the issue of blocking mobile attacks. It does not assess the overall security offering from these companies (e.g. WAF, API Security etc) but instead focuses on their mobile offering.
Akamai has a client-side Mobile Performance App SDK which selects edge servers and content versions based on network conditions. They also have a separate Bot Manager SDK which is only available to registered customers, presumably when they flag a mobile coverage issue not addressed by the server side Bot Manager. This SDK seems to gather signals about user behavior (clicks etc.) for the Bot Manager, rather than perform deep analysis of potentially dangerous activities in the device environment.
Imperva provides a mobile SDK which works with the server-side Advanced Bot Protection (acquired from Distil Networks). This SDK performs some rudimentary checks on the device environment (jailbroken or not, presence of an emulator) and permits the back end to easily distinguish mobile traffic. Imperva also has a server-side RASP product which competes with their WAF offerings but it doesn't work with mobile apps and does not work with ABP.
F5 provides a mobile SDK which allows app attestation but which only detects whether devices are rooted or not, without any deep contextual analysis about the device environment.
Google has cloud based Apigee API protection as part of their WAAF offerings and a separate solution, Firebase for app development, hosting and providing authentication services. Firebase App Protect uses an SDK in applications and integrates app integrity signals from Apple or Google Play attestation and is therefore subject to the limitations of these solutions.
Fastly, AWS, Azure do not provide mobile SDKs and do not have solutions which provide mobile specific defenses.
In general these solutions are far from being best-in-class, either because they are limited to behavioural signals or because they collect very limited contextual information about the device.
The good news is all these solutions provide a way to integrate more robust mobile security by adding validation of tokens coming from a mobile SDK. We will show how that's done easily and effectively but first lets dig a little deeper into how mobile app protection works in practice.
It's worth noting that Cloudflare have followed this path.
