The Zero-Trust Mobile Security Model
Developers are waking up to the risks of blindly trusting the underlying device and OS to provide security for their apps. Communities of applications are taking steps to secure their applications in a sandbox’ed environment where malware and legitimate applications are treated equally.
Organizations are beginning to realize that they cannot rely solely on mobile operating systems or device owners to provide security. As mobile OS vulnerabilities continue to be identified in both iOS and Android, breaches of both consumer and enterprise data are on the rise. Many of the breaches are a product of direct attacks on applications that were encouraged to rely on platform security only to find themselves left completely defenseless.
“you have to assume that your operating environment is one where a significant number of your users are on platforms that can’t be patched” – Facebook CSO Alex Stamos told CIO Journal
Mobile device security models developed for iOS and Android cater to the security of the operating system, not the applications. Not surprisingly, operating system and device manufacturers prioritize the availability and security of their own functionality above that of any third party application. By forcing applications to run in a sandbox the OS deprives them of the visibility and privileges that are required to put up any sort of defense. Both the iOS and Android were built on the premise of creating an ecosystem for games and basic entertainment applications – enabling sensitive operations and secure storage was not part of the original plan.
As if the app-adverse security model isn’t bad enough, patches are issued in frequently if at all. Since handset manufacturers control update distribution and they would prefer to sell new devices over spending significant resources on patching older, unprofitable devices the OS support cycle is incredibly short.
“The security model is completely stacked against mobile applications in a way that is unprecedented in the traditional workstation (laptop/desktop) space.”
This issue has the attention of the security world as IT professionals come to understand that we’re indeed living in a “zero-trust” ecosystem when it comes to mobile devices and applications. Even the rare updated and fully patched mobile operating system doesn’t provide the security features that developers need due to the OS/device favoring and profit-oriented mobile security model.
Realistically, most devices aren’t up to date. With an 80+% global market share, Android dominates the mobile device market throughout the world but fewer than 1% of Android devices are using version 6.0, released two months earlier, and a full 70% were still using versions 4.4 and below. These numbers mean that most Android users don’t have access to security patches and security features that have existed for more than a year. In most cases these devices are susceptible to publicly available exploits that can result in full device compromise without any user interaction.
Publicly available exploit code exists on well known hacker sites the allow anyone to exploit the famous StageFright vulnerability https://en.wikipedia.org/wiki/Stagefright_(bug). This single exploit code can compromise the 70% of Android devices described above. Android is an open source operating system that has a tremendous attack surface. Even components of this operating system which are not open source are readily accessible. The same 70% of android devices are vulnerable to Heartbleed, a famous security vulnerability due to the OpenSSL library: http://heartbleed.com/.
In stark contrast to Android, iOS is a silent killer. It’s rare that incremental iOS updates are released to actually implement new features, most incremental updates are quietly patching security flaws. This is generally noticeable when small, updates are introduced such as 9.2 vs 9.2.1. Updates are an expensive costly process that require intensive testing, Apple prefers to only perform major feature improving updates – incrementals are generally a sign of vulnerabilities that forced their hand.
Apple generally slips security fixes into the update by first rationalizing the update with small, incremental feature updates or additions. Without adding “features” it will appear that the platform is insecure. The “features” are generally lackluster and therefore there is no urgency and a device owner will never know to apply the update quickly. In reality, there are critical security fixed but Apple blanketed this with features. For example, Apple recently patched a 3 year old bug that allowed hackers to steal cookies from iOS devices connected to a hotspot. This bug was fixed in the iOS 9.2.1 update along with other 13 security bugs, some of which were high or critical risks resulting in complete device compromise. One bug in particular allows any application to break out of the sandbox and compromise the device. A normal user reading Software Update descriptions would never realize this is the case.
Despite the severity of issues, a user is simply shown the provided screen when an update is requested. This screen largely describes iOS 9.2.1 as a basic availability fix for MDM application when it actually contains critical security fixes. The wording used here is extremely calculated. To a normal user, a “security update” would appear to be an improvement not a retro-active patch that fixes a previous oversight. The “bug fix” terminology pertains to the fixing of described critical vulnerabilities with the word “bug” used in favor of “vulnerability”. Compare this to the vast amount of high risk security vulnerabilities outlined in the release notes for iOS 9.2.1: For example: https://support.apple.com/en-us/HT205732.
In a mobile device world where users are responsible for patching devices, how quickly will a user apply such an update?
The Zero-Trust Model
For the first time we’re seeing developers and organizations embrace the BioEncrypt zero-trust model for development. No longer willing to rely on an OS that doesn’t provide the security features they need, developers are taking steps to secure apps, defend data, and protect users.
To protect against these issues and many other “you have to assume that your operating environment is one where a significant number of your users are on platforms that can’t be patched,” Facebook CSO Alex Stamos told CIO Journal, noting that Facebook is working hard on building security directly into its own apps. Consequently, because developers cannot inherently trust what they start with—the mobile OS—applications must become capable of safeguarding the assets they contain: the identity of the user, consumer data, enterprise data, and whatever else is of value or precious within the app. If Facebook is doing this for privacy reasons, why aren’t all applications that store mission critical enterprise data or banking information?
The Zero-Effort Solution
A zero-Trust models requires developers to research and understand the nature of mobile threats: how are apps are being attacked? How are paywalls being bypassed? How are services being appropriated and used for free by attackers? How is consumer and enterprise data being stolen and resold? The answers to these issues are complicated and require vast experience in the mobile security space. This is especially true in highly distributed mobile environments where organizations lack control of their endpoints (e.g., BYOD). This isn’t a one-time effort either, the mobile threat landscape is changing constantly and rapidly. So how can mobile app owners develop their own security without the enormous overhead of an experienced and highly-specialized security R&D department?
Open source BioEncrypt integrates with any mobile application simply and seamlessly, instantly enhancing the app’s security intelligence. By building profiles of trusted device BioEncrypt enables apps to respond to the full spectrum of user and system attack vectors using a simple TrustScore. No complex security knowledge is required and it updates automatically to account for the latest threats unique to each mobile device your application may operate on.