Mobile Security Moves On Up
The problem of mobile security is not solved, but we have at least reached the point where it is solvable.
You may have noticed that there hasn't been too much talk about mobile security vulnerabilities over the past few years. This is largely due to significant developments that have been made on all the major mobile platforms in recent years, effectively reaching parity among the top-level solutions.
That's not to say that the problem of mobile security is solved; because to benefit from these improvements you do have to implement them, and far too many organizations are following a classic "head-in-the-sand" strategy on securing their mobile assets. But for those who do want to take reasonable security measures, the tools are there to do so.
The big challenge with mobile security is that there are so many potential vulnerabilities, and the tools and capabilities to address them vary by operating system and sometimes by manufacturer. Android still faces the greatest challenges because enterprise users are faced with the task of distinguishing between, say, Samsung's KNOX technology and all the other manufacturers of Android devices.Hardware-Based Confirmations
The logical place to start any discussion of mobile security is with the platform itself. In particular, how susceptible the platform is to malware and other threats to the operating system and applications running on it. BlackBerry was first to implement a secure boot-up process that was linked to the hardware. Codes were built into the hardware itself that allowed the device to verify that any boot code that attempted to load was signed by a valid authority.
Apple took the same approach, as did Samsung with the secure boot function it included with its KNOX security capability; KNOX uses the TrustZone-based Integrity Measurement Architecture (TIMA) while Apple uses Secure Enclave in devices with an A7 or later processor. Samsung also includes a one-time programmable memory area it calls a "fuse" that is permanently written if the device identifies any suspected tampering. If any boot components fail its hardware verification, Apple stops the boot process, displays the "Connect to iTunes" screen and enters Device Firmware Upgrade mode to restore the factory settings.
Microsoft, for whom security had been an Achilles Heel, made a major leap with Windows 10. Starting with Windows 8.1, Microsoft required all devices to include a secure hardware component called the Trusted Platform Module (TPM) that provides that same type of hardware-based confirmations. Microsoft has also included a remote Attestation capability in Windows 10 Mobile where an MDM platform can order a device to assess its own security profile and report back to the MDM system.Containing Your Excitement about Secure Containers
Implementing these capabilities requires that the manufacturer have control of both the hardware and the software. That is the problem for Android and why the security profile is still a concern in multi-vendor Android environments. However, there are some steps that Google has taken that improve Android's security profile across the board, including Security Enhancements for Android (SE for Android) and Android for Work (AfW). SE for Android is a twist on Security-Enhanced Linux, a Linux kernel security module that provides a mechanism for supporting access control security policies.
Android for Work is a secure container technology that Google acquired with its purchase of Divide (formerly Enterproid). A secure container is a separate encrypted region on a mobile device to store and manage enterprise information, and this sort of technology has become a core component in mobile security. Virtually all of the mobile device management/enterprise mobility management (MDM/EMM) suppliers offer secure containers, including VMware AirWatch, MobileIron, and IBM (in MaaS360), and Samsung offers its own secure container in KNOX. One major advantage of secure container technology is that it enables the MDM platform to wipe the contents of the secure container if the device is lost or stolen or if the employee leaves the company; the personal data and apps on the device remain untouched.
The outlier in this is Windows 10, for which Microsoft developed a completely different strategy for securing corporate data and apps, called Enterprise Data Protection (EDP). Instead of going the way of the secure container, with EDP IT administrators simply identify apps as either business (called "trusted") or personal (called "untrusted"). Data created in or sent to trusted apps is automatically encrypted and IT can define data loss prevention (DLP) policies that prohibit printing, cutting and pasting, or forwarding data to personal email accounts or untrusted storage locations. You can also identify "enlightened" apps that can be for both, like Outlook, for example, for which you could have business and personal email accounts, and the business email and attachments are automatically encrypted and subject to DLP policies. For some container solutions, users need to maintain personal and business versions of apps used for both purposes, so the advantage of Microsoft's mobile security approach is that it eliminates the need to log into a separate container.Encryption and Authentication
Data encryption, both for data stored on the device and on an associated SD card, is critically important for mobile security. Most platforms now enable full device encryption by default on all devices, though there can be challenges with this. Google had initially promised default encryption on all devices with Android 5 ("Lollipop"), but later had to back off that commitment. With Android 6 ("Marshmallow"), default encryption is required for devices meeting certain standards.
That brings me to another problem with not controlling the hardware: You can't be sure every device comes with a built-in crypto chip; a lot of low-end Android devices don't have them. With the complexity of the encryption algorithms, if the device were to do the encryption in software, the performance would slow to a crawl.
The other big problem with mobile security is authentication to access the device. When the only authentication method available was a device PIN, almost nobody enabled device authentication; you picked up someone's phone, and it worked! Apple's implementation of the TouchID fingerprint sensor on the iPhone 5S was a major step forward in authentication. While some claim that the fingerprint sensor can be fooled, the process takes the skill level of MacGyver or CSI. Now that we've seen Apple open up the API for TouchID, it is increasingly being used as a mechanism to authenticate access to Web apps or to allow purchases.
Apple's second-generation TouchID sensor on the iPhone 6S delivered a big improvement in speed, but others have had problems getting their fingerprint sensors to work at all. With Windows 10, Microsoft is introducing Windows Hello, a multifactor biometric system that can use fingerprints, facial recognition or iris scans to authenticate access. Windows 10 will also allow you to unlock your PC with your authenticated Windows 10 Mobile device, and Apple just announced the ability to unlock a Mac with an Apple Watch in macOS 10 (the new name for "OS X"). macOS 10 will also allow you to authenticate a Web purchase on a Mac using the TouchID sensor on an associated iOS device.
Virtually all of these capabilities depend on having an MDM/EMM platform to define and enforce controls. Amazingly, a significant percentage of organizations are still using the rudimentary MDM capabilities in Exchange ActiveSync (EAS). Those capabilities include things like requiring passwords, disabling phone features, and allowing/disallowing attachment downloads, but none of the key security capabilities like secure containers are included. It can also remotely wipe a device, but this is the equivalent of a factory reset (i.e. "There go the baby pictures!").
In short, virtually all organizations have information that they need to secure, and if any of that information is on mobile devices the attack surface increases exponentially. To be sure, the tools available today for managing mobile defenses have reached the point where they are sufficient to address the security requirements of the vast majority of enterprises. The remaining challenge is getting organizations to acknowledge the fact that this is something they have to do and they need to find the money and personnel resources to do it adequately.
In regulated industries where security and compliance requirements have real teeth, these measures are virtually universal. However, I'm continuously amazed by the number of organizations I encounter where the mobile security plan appears to be "Ignorance is bliss."
And to that, I say, good luck with that one.