CISOs understandably ask us about jailbreak detection. If you have read our post, “The Myths of Mobile Jailbreaking“, then you know that our approach is to encrypt the data on the mobile device in such a way that it is protected from automated jailbreak and rooting attacks. Our encryption code is implemented independently of the underlying device platform, ensuring that attacks on the OS don’t compromise the application data. Data remains encrypted even on a jailbroken device.

Jailbreak detection is unreliable. As the post points out, it is a moving target. In addition, sophisticated hackers can fool the detection program.

Don’t be lulled by checking off the “Jailbreak Detection” box. Detection won’t protect against jailbreak. Our secure container system provides the highest level of security offered in enterprise mobility. We would be happy to illustrate Link’s security features to you and your security team. Just email me: maureen at mobilelhelix dot com.

– Maureen

Please click this Link to our security whitepapers.

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

A data centric rather than device centric security model turns IT security on its head but it leaves the enterprise more secure and it is also more realistic and simpler to deploy and support.

We have talked about devices being treated as “tools” for employees and not IT infrastructure. That is a radical shift in thinking. A related concept that we also firmly believe is that security must focus on enterprise data and not devices. This concept is another radical shift in IT thinking.

Device security currently focuses on securing the endpoint or device. These device centric models are flawed because:

• As soon as the device is compromised, the enterprise network is exposed as well as data on the device and back in the network (see jailbreak discussion below).
• Endpoint based security creates separate architectures that become increasingly complex and unwieldy (for both mobile and fixed access) with increasing layers of solutions needed to be added to plug the next gap in the model (VPN, Anti-Virus, Firewall, MDM, MAM, etc).
• Increasingly the device may not be owned by the enterprise, applying IT security policies to personal devices is fraught with issues and ultimately does not work.

A data centric approach focuses on the actual enterprise data and–or applications. The model focuses on sensitive corporate data and creates a robust encryption barrier surrounding that data, both at rest and in transit. Data is protected regardless of the device operating system or device state (e.g., rooted/jailbroken, protected with a device management policy or not, etc.).

The model also aligns well with personally owned devices/BOYD because IT only looks to secure and control its own “assets” – the enterprise data and-or the enterprise apps. This is a much more collaborative and reasonable position to pitch to employees whose support is critical for success.

A data centric security model adheres to a few essential principals:

• All data must be encrypted, in transit and at rest, and all encryption keys must be generated from strong credentials that are device independent.
• All encryption technology is implemented independent of the underlying device platform, ensuring that attacks on the OS don’t compromise the app/data.
• All sessions must be authenticated with strong credentials, and IT must be able to implement secure session management policies.
• All communications must be verified, end-to-end, precluding the possibility of unauthorized proxy access along the way.
• IT must have the tools available to implement the principle of least privilege. Data should be available to mobile employees who have a legitimate business case for using that data on a mobile device, and it should only be available under the circumstances (online/offline, location) justified by that business case.

To learn more:

• Please Join our Webinar with Maribel Lopez of Lopez Research on the 30th July.
• Our whitepaper on “Securing Corporate Data” goes into a lot more detail. Please click here to download the paper.

— Matt

Ever since the beginning of the mobile revolution, device manufacturers and telecom carriers have sought very tight control of the terminals.

On the one hand, phone manufacturers argue that built-in safety measures such as encryption and restricted access to sensitive APIs are the only way to ensure the integrity of the software (including the firmware, the OS, and the apps running on top of the OS) and the privacy of its users. Carriers are also worried that rogue devices may be able to connect to their networks with unknown consequences.

On the other hand, hackers and free software advocates have been able to circumvent the security measures in the OS of these mobile devices. Finding and exploiting vulnerabilities in the OS to gain control of the terminal is often referred to as jailbreaking or rooting. Jailbreaking/rooting a device can have legitimate reasons: some users argue that they should be able to install any software on a device they own or get rid of the apps bundled by the carrier or phone manufacturer. For instance, a popular firmware like CyanogenMod for Android requires the device to be rooted prior to installation. Obviously, jailbreaking can also be used to commit fraud or crime: for instance, install a Trojan or key logger on a device, breach the security of a corporate network or remove the tracking function from a stolen device.

This tug-of-war has been going on for a while now and shows no sign of slowing down: hackers find a new vulnerability to exploit; security experts detect and analyze the exploit then issue a patch … until the next exploit surfaces. This situation is very similar to what has been happening in the software industry for years between virus writers and security experts.

Three major reasons explain this never-ending game of whack-a-mole. First, the size of the code of a typical OS (millions of lines of code) and the constant need for new releases means that there are always bugs that can be exploited. Second, there is always a delay between the active exploitation of a software vulnerability and the discovery/patch of this vulnerability by security experts. Finally, there is no bulletproof method to detect that a device has been rooted.

Generally speaking, the detection methods for rooting rely on finding specific fingerprints left behind by known programs that are used to root a device. The issue here is that these fingerprints change potentially with every version of the exploiting program, and sophisticated hackers can fool the detection program and hide these specific signatures altogether. In this respect, jailbreak and root detection is no different from anti-virus, and as we have seen in the World of anti-virus the protection always lags the exploit, and it is often available only after the damage has been done.

So, what does it all mean? For mobile developers, it means that they cannot make the assumption that the underlying OS they rely on to communicate with the device is not jailbroken/rooted.

With the growing realization that what needs to be secured is the data, not the device, the mobile industry is turning to secure containers to isolate the mobile apps from the (possibly compromised) OS. This reality is especially important as the BYOD movement is gathering steam in many industries rendering device wide security policies hard to implement.

While in theory, a container may be rooted as well, it is a lot less likely since the size and complexity of the code (the attack area) is much smaller than that of a typical OS and the code is usually very stable in time. Of course, a secure container is only a piece of a wider end-to-end secure delivery system, but it is an essential piece that must be designed and implemented with care. Particular care must be taken to ensure that attacks directed at the runtime system of the OS (e.g., the Dalvik VM) do not compromise sensitive functionality like encryption. While this places a higher burden on the container developer, when devices are handling sensitive data IT and end users should expect nothing less.

Find out how the Link solution can help you secure data and applications even on potentially jailbroken/rooted devices here.

– Frederic