The Dangers of Outsourcing Mobile Security

Two stories broke recently revealing vulnerabilities in the security infrastructure for Android and iOS respectively. While vastly different in their nature, both point to a fundamental lesson that the enterprise must learn – don’t rely on mobile device OEMs or mobile OSs for enterprise grade security – ensure you are in direct control of security for sensitive corporate information including encryption and access control.

Two separate yet significant approaches to compromising encryption on Android and iOS broke in the news recently. The Android vulnerability, discovered as a result of a compromised Bitcoin transaction, is most directly relevant to encryption. In short, the Android operating system does not properly seed the PRNG (pseudo-random number generator) used by the built-in cryptography APIs. Randomness is essential to ensure that (a) encryption keys cannot be guessed, and (b) an attacker cannot successfully guess the contents of intercepted, encrypted messages. In short, any app that relies on these vulnerable APIs for its essential encryption functions is flawed, including everything from Bitcoin to a vast array of enterprise-targeted mobile apps developed by third party and in-house developers.

On the iOS side, a group of researchers at Georgia Tech successfully submitted an app with malicious capabilities and intentions to the Apple App Store. What the researchers discovered is that the cornerstone of Apple’s App approval process is a static analysis of the app code. How does malware posted to the App Store implicate iOS encryption? Well, the link here is indirect – malware installed on a device can exploit an OS vulnerability to “jailbreak” the device; once “jailbroken” the OS can no longer be trusted, and an untrustworthy OS should not be used for encryption nor should it be trusted to report on its own health and safety when a device management solution tries to determine if it is “jailbroken” or not.

The wake-up call for the enterprise is not in the nature of these attacks themselves – it is in the remediation they require. Enterprises have become adept at managing security vulnerabilities with all of their major vendors, and IT understands that vulnerabilities are a fact of life. The key to vulnerability management is to act on them quickly and effectively once identified. Here we come to the core issue.

Employees access corporate systems with a broad variety of Android and iOS devices. IT can neither upgrade the operating system on Android nor can it influence which apps are admitted to the Apple App Store. IT’s only viable strategy for remediating vulnerabilities in the mobile ecosystem is to attempt to block access to corporate systems or to blacklist access to specific apps. Neither approach is attractive. Locking broad swaths of employees out of corporate systems is not a particularly productive answer. Similarly, attempting to maintain an accurate malware blacklist is destined for failure (see anti-virus).

IT’s best (and only) strategy in a mobile enterprise is to retain complete control of the components of the mobile software stack that matter most. Encryption and access control are the building blocks of the mobile security infrastructure, and the software implementing these two operations must be as firmly in IT’s control as is possible. In practice, this means that a software-only container, which includes its own full stack implementation of all cryptography functions and all secure network protocols (e.g., a full SSL/TLS stack), should be the only software trusted to handle sensitive corporate data and to authenticate corporate users. This strategy is not perfect because no software (including the container itself) is perfect, but it restores control to IT when vulnerabilities are discovered.

As IT quickly loses control of the endpoint devices that employees choose to access corporate systems and data, IT must consider carefully when and where it is essential to retain control and how to do so. When security really matters, a secure container approach is the only answer. The question from there is how to deliver a first class mobile experience while still retaining the protections that a software container affords. As without a rich and compelling user experience, users will be reluctant to take advantage of the mobile app irrespective of its level of security.

– Seth

Containerization and Securing the Data

Containerization-BlogLocks2

Last week I attended a session of IT professionals which posed the question, Is MDM Enough?

The three panelists were in CIO and Managing Director roles. Each one was currently using a respected Mobile Device Management solution which he or she had licensed 2 or 3 years ago. To a person each one said, “If I were to do again now, ‘containerization’ would be the focus.”

This illustrates the state of enterprise mobile security today. BlackBerries were generally company property. It was understood that the company could wipe the BlackBerry. Then firms issued iOS and Android devices to certain employees. It was during this phase that MDM had its heyday. Securing devices became the objective. The response was a tactical one, install MDM. Companies were initially on firm ground in requiring that employees use a password on the device and in wiping the entire company-owned device should it be lost or stolen.

But the landscape changed rapidly with employees eager to work from their own personal iOS and Android smartphones or tablets. Requiring MDM to be installed on personal devices and requiring that a password be entered before an employee could use his or her own phone to make a personal call was overreaching. And wiping a personal device is a questionable practice. Not surprisingly, employees pushed back.

Leaders in the field saw that attempting to secure the device was the wrong approach and that what was needed was to secure the corporate data. A few innovative firms developed an approach which is broadly called containerization.

What is containerization? In its most advanced case, containerization is the creation of an encrypted sandbox on the mobile device for the secure access of corporate resources. In some cases, there is provision for storage of files within the secure container. The user must authenticate to access the secure container. There may also be offline access to files and email. The container itself can be remotely wiped by the company, but not the entire device. In fact, there are no restrictions on the personal usage of the device – no device password is required; there are no rules about what can be installed on the device.

Containers are not created equal. Features and architectures vary. We stake a claim on having unsurpassed security. For example, the encryption code for our Link Container is written in native code. It does not use the native OS security API. Our container remains secure even on a rooted or jail-broken device.

There is more to our secure container offering, including full endpoint administration, role-based access and analytics. We are just an email away – we would be happy to show you the full picture.

– Maureen