Lollipop or lockdown? What a secure mobile OS means for BYOD
Connecting state and local government leaders
Android Lollipop and iOS8 present government mobility managers with more options for balancing end-user convenience with the requirements of high-threat, classified environments.
Mobile managers will soon be grappling with the advent of new and more secure mobile operating systems as both Apple and Google have recently rewritten iOS and Android to take account of both personal and enterprise security demands and requirements.
These new OSs will eventually have an effect on the use of mobile devices in government, where administrators are working to balance the culture of security against the irresistible force of bring your own device.
Out of the box, both iOS 8 and Android Lollipop (Android L) both have encryption turned on by default. The development has already caused a mild panic in intelligence circles, with the FBI saying it will make cyber investigations much more difficult.
On the other hand, encryption from the start will make it easier for enterprise managers to ensure secure data on users’ phones, particularly if they use their own phone for business purposes.
At the same time, it will put more of an onus on users to maintain their own settings. With Android L, for example, users will have to remember the device’s PIN, which unlocks encryption. Forget it and the device and its data will have to be wiped and reset, though apparently enterprises will be able to manage these PINs centrally.
Android L, whose launch is imminent, has a number of other security-based features that should appeal to agency enterprise managers.
Google’s Android Work, a subset of Android L features for mobile device management, will give IT and network administrators more control over how to provision apps for users or groups. Admins will also be able to define policies for how those apps are used and decide which users can access specific apps and data.
This should make it easier for government agencies to safely accommodate BYOD which, even though the phrase itself has lost some caché, is still a major concern. As an added incentive, new APIs will make it easier for enterprise mobility program developers to include Android Work in their own solutions.
One concern for some agency developers: Tougher security features in Android L are likely to make it harder to root the operating system in order to meet ad hoc requirements. Rooting – the ability to easily obtain “superuser” rights and permissions – had made it relatively easy for admins to change or modify any of the software code or load custom software on the devices.
However, there have already been workarounds reported, with some already coming out with device-specific solutions.
Much of the upgraded security in Android L benefits from the containerization technology that frames Samsung Knox, a four-year development that the company is using to try and consolidate a lion’s share of the Android mobile market.
The firm has already spent considerable time shopping its security vision to government, and the military in particular seems to be interested.
The latest signup is the National Security Agency, which recently put Samsung mobile devices and solutions that use Knox onto its Commercial Solutions for Classified program, making them the first consumer devices to be validated to handle classified information. Ironically, this is a what-goes-around-comes-around affair since Samsung Knox uses the Security Enhanced Android specification originally developed by the NSA.
Also, Samsung devices are notably absent from the list of device manufacturers who have said they would be soon be updating their products to Android L.
However, the Korean company has not given over all of Knox’s features for Android L, opting to keep hardware specific items to itself. That means new and updated Samsung devices will use an operating system that should be at least as secure as those that use the first vanilla versions of Android L.
In other developments on the cybersecurity front …
The National Institute of Standards and Technology recently published first draft recommendations for secure deployment of hypervisors (SP 800-125 A). The public comment period runs from October 20 through November 10.
NIST said though it might appear that activities related to secure hypervisors should be based on established practices for server-based software in general, the functionality that hypervisors deliver should be examined from two considerations:
- Hypervisor platform architectural choices – in other words, the way various modules link with each other and the server
- Hypervisor baseline functions – the core functions that provide the virtualization functionality
There are 22 recommendations in all in the draft, which also describes some of the security threats specific to hypervisors and how errors in deployment can lead to their being open to attack.