Mobile apps, especially those running on unmanaged devices, are increasingly under attack. Legacy approaches intended to protect them are failing. It’s time to consider a new approach.
Mobile app executable code has access to everything, including encrypted data and we can instruct it to do anything, either benign or malicious. So protecting an app’s executable code must take top priority. Now consider how mobile apps are very different than web apps – instead of executable code residing only on well-managed, secured servers – it’s distributed to unmanaged, highly vulnerable mobile endpoints in the hands of unsophisticated end users. Many of these endpoints are already compromised, making them perhaps the most dangerous place on the planet for an app’s executable code to reside and run.
It’s also important to appreciate how an organization’s endpoint attack surface grows tremendously in size. We think it’s especially true for organizations offering “public facing” mobile apps to their customers, clients, patients, and partners. For example, some retailers find that their attack surface expands by several thousand times.
The current situation
It’s bad. A recent independent study found that attackers can compromise most mobile apps from Fortune 500 organizations in 15 minutes flat.
No surprise – we had already conducted our own studies covering the top 25 mobile apps in the U.S. financial services, healthcare and retail sectors. Across a total 75 apps, our engineers successfully compromised 84% of them in 15 minutes or less.
This happens for a number of reasons. First, it’s simply way too easy to compromise a mobile app's executable code. Want to know how? Google search: “How to hack a mobile app” and see the 210 million results covering books, videos, tutorials, even malicious code samples. Second, there are way too many open vulnerabilities – over 6,000 in the Android and iOS environments. And finally, cybersecurity professionals have near zero visibility of public endpoints and absolutely no ability to control/manage them. They are left “flying blind” over this huge component of their attack surface.
The legacy approaches
There are two types of legacy approaches in use today. The first type – code hardening – ranges from basic source code obfuscation to highly complex code refactoring. Unfortunately, in practice, the bad guys don’t perform this type of mobile app hacking at the source code level. The second type – runtime application self-protection (RASP) – initially appears attractive, but consider this question: Is it prudent to depend on a compromised app to correctly report back that it’s been compromised? The above studies clearly indicate that the legacy approaches are failing.
We need a better approach
Security pros have expressed interest in the Sentinel approach. Its foundation rests on three pillars. A fully competent Sentinel must contain the following elements:
Independent: The protective Sentinel should not be “inside” or “wrapped” around the mobile app it’s protecting. Instead, it should stand alone, watching over the app from an independent perch. It also must be irrevocably tied to an independent monitoring platform. Note: staying outside the app also yields an important practical advantage – instead of requiring app development assistance to incorporate additional complex technology into their app, a well-designed Sentinel-based solution lets a CISO simply register an app for protection using a secure web portal interface. Sophisticated Sentinels will self-configure for the app they are protecting and adapt automatically for future releases.
Inviolable: What about an attack that attempts to compromise the Sentinel itself? It’s axiomatic that hackers can compromise any software. So we cannot make it impossible, but we certainly can make it wholly impractical. Here’s how: Because the Sentinel operates independently and outside the app, its entire corpus can become an integral part of the cryptographic handshake protocol with its monitoring platform. If a Sentinel gets compromised in any manner, its handshake fails, and the compromise gets detected. Note: This means that an attacker cannot just “hack” code, they must “crack” cryptography, a challenge that’s orders of magnitude more difficult.
Inimitable: Each Sentinel can be made unique and tightly bound by blockchain technology to just one single app instance. Individual app instances in the field are then effectively tethered to the monitoring platform by their own unbreakable “crypto leash.” Note: This makes it exponentially more difficult to compromise any significant portion of an installed base. For example, consider a popular banking app with 50 million users. If a Sentinel does become compromised, the attacker gains only one single instance and would have to repeat their laborious efforts another 49,999,999 time to get at the entire installed base.
There are no panaceas in cybersecurity, but it’s hard to see how the Sentinel approach would not represent a quantum leap forward in helping the good guys beat the bad buys. I encourage all cybersecurity thought leaders and solution providers to embrace this emerging approach.
Norm Klapper, chairman and CEO, AppVision
