Android versus iOS security: Features, policies and controls

Under the covers: Android versus iOS security posture

The original iPhone lacked basic security features, as did early versions of Android. The platforms are now on their fourth and fifth generations respectively, however, and Android and iOS security features and policies are considerably stronger now.

Under the covers, both iOS 5 and Android 4.0 Ice Cream Sandwich use sandboxing to isolate applications from each other and from sensitive operating system features. One iOS security feature is that applications cannot search, view or modify each other’s code or data; in other words, they do not have root access to kernel or sensitive device resources. All applications operate with the same coarse permissions, except for a few user-controlled exceptions, such as location access and notifications.

Android security differs from iOS in that Android applications can’t view or modify each other’s data, but they can examine each other’s code and have shared access to removable storage, such as a secure digital (SD) card. Android also has a granular a la carte permissions model, whereby users must grant each application rights at the time of installation. Users’ only options are to either grant the permissions and download the app, or deny permissions and not download it. This makes it easy for app developers to build apps that abuse permissions.

From a risk management perspective, the iOS security approach is harder for poorly-written or malicious applications to abuse, but both platforms are vulnerable to browser exploits -- for example, iOS jailbreak apps use bugs in the Safari browser. From a risk-mitigation perspective, the Android security approach is more flexible; antimalware scanners can spot malicious apps on Android, but not on iOS.

Enforcing policy: Android versus iOS security controls

Both iOS 5 and Android 4.0 natively support the security controls typically required for enterprise use, including device-level access control, remote lock/wipe and encryption for data at rest and data in transit. On both OSes, IT can require a PIN or password with specified complexity, auto-lock a device’s screen after a period of inactivity or remotely lock a network-connected device. Android security  also supports pattern- and facial-recognition-based lock options, but they aren’t robust enough for business use.

There are cases where hackers can bypass access controls  -- remote access to a jailbroken device or physical removal of an Android SD card. If a device is jailbroken, an attacker can access the device remotely, logging in with the root password. The hacker will not need to enter the user's normal screen lock password, but will still have full access to the device. Similarly, if an SD card is physically removed from an Android device, an attacker can insert it into another device and freely access data -- email, media, file attachments, etc. -- from that original device.

Both platforms also support remote wipe, but differences exist in implementation and effectiveness. With iOS, IT can remotely invoke enterprise or full-device wipe using Apple’s mobile device management (MDM) application program interfaces (APIs). The former removes only those policies and applications installed via an MDM system, leaving the device otherwise intact. On Android, remote wipe requires a previously installed third-party application, such as an MDM agent, or configuration through Microsoft Exchange ActiveSync. In this case, IT may wipe the entire device or just selected data and apps, but a full-device wipe simply resets the device to factory default, leaving SD card contents behind.

Both platforms can use encryption to protect data at rest, but the hardware capabilities vary by make and model. Every iOS device since the iPhone 3G S has supported encryption using the 256-bit advanced encryption standard to secure data in flash, which is PIN/password unlocked. Applications can also apply secondary software encryption to their own data. For example, the native email client encrypts messages and attachments. Some (but not all) Android tablets running Android 3.0 Honeycomb and up, as well as Android 4.0 smartphones, support hardware encryption. It is increasingly common for enterprise-focused Android applications to use software encryption to protect their own data, independent of device capabilities.

Finally, both platforms support a variety of over-the-air encryption methods, including Secure Sockets Layer/Transport Layer Security-secured Web and email, Wi-Fi protected access (WPA) and WPA2-protected Wi-Fi and various native virtual private network (VPN) clients. Android 4.0 added an API to enable third-party Internet Protocol Security VPN client development, which not yet possible on iOS (except for Cisco Systems’ VPN, which iOS supports natively). IT can remotely configure accounts to require protection for mobile data on both platforms, although settings are currently more flexible for iOS than for Android.

Stopping malware: Android versus iOS application provenance

When it comes to enterprise risk mitigation, the biggest difference between iOS and Android security is governance of third-party software distribution and deployment. Apple asserts tight-fisted control over iOS apps, reviewing all third-party submissions to ensure approved use of APIs and requiring all developers to sign code with Apple-issued certificates. Users cannot install apps on iOS devices except when they are downloaded from the Apple App Store or an enterprise app store. Google takes a more open approach, allowing developers to sign code with self-signed certificates and publish apps in Google Play without review. (Google Bouncer scans for malicious apps but is not a pre-publication code review.) Users can change one setting to permit side loading, which allows them to install apps from other sources.

Because Apple’s app-vetting process is so rigorous, it helps prevent iOS devices from getting malware. Although iOS malware exists, it has only infected jailbroken devices to date. (That’s because jailbroken devices bypass Apple’s rules to permit app installation from outside the App Store.) On the other hand, several hundred Android malware outbreaks have already been documented, including some involving applications from Google Play. Google moved quickly to remove malware from its store and infected devices, but it’s still easier for malware to exploit the Android operating system.

IT can remotely inventory applications installed on both iOS and Android devices. When appropriate, IT can also remove any installed app from an Android device, but iOS does not let IT forcibly remove user-installed App Store apps. Application control is an area of continuous innovation for both platforms. Watch for new alternatives to help IT manage applications and their associated security risks on both iOS and Android.

Like SearchConsumerization.com on Facebook