Comparing mobile OS security features

Your mobile device management (MDM) policy's technical requirements should include measures to meet business mobility needs and mitigate associated risks. But different mobile OSes offer different security features and methods.

Major business risks commonly associated with mobility include:

• Unauthorized access to business data, networks and applications by lost or stolen devices;
• Breaches of confidential data when mobile devices fall into the wrong hands, even temporarily;
• Compromised devices as a vector for intrusion into or attack against enterprise assets; and
• Inadequate visibility into activity and security posture to prove regulatory compliance.

Fortunately, these risks can be managed by requiring mobile security controls. However, the controls available vary by mobile device type, OS and make/model, so a mobility assessment should cover the risks posed by all devices identified in your workplace and permitted by your mobility policy.

Smartphones, tablets and many other mobile devices often run one of four mobile operating systems: Apple iOS, Google Android, RIM BlackBerry OS or Windows Phone.

As shown below, all four support PIN/passcode access controls, full-device encryption and MDM-initiated wipe. These "table stakes" go a long way toward addressing major business risks.

However, beneath these similarities in mobile OS security features, there are differences that should be assessed when developing your enterprise mobility policy. Risks to be considered, prioritized and mitigated include the following:

Security architecture: These mobile OSes use sandboxing to insulate applications from one another and the kernel, but consider disabling features that could be exploited by mobile malware or leak data, such as shared/removable storage.

Permissions model: These OSes require users to grant requested permissions to applications, but default permissions and prompting vary. Users may need your help -- and monitoring -- to detect over-reaching applications that pose more risk than benefit.

Vulnerability management: Over-the-air OS updates are now common, but update availability still varies by make/model and carrier, so it's important to enforce minimum versions.

Application provenance: Some vendors tightly control applications that can be installed, while others (most notably Google) take a more reactive stance that promotes malware. Consider disabling options that let users install unsigned applications from unofficial app stores, and monitor installed applications to detect and remove known malware.

Built-in security controls: These OSes include built-in basic security controls, but supported settings vary. Verify that each device supports your mobility policy's technical requirements, and define mandatory/optional settings for each supported kind of device.

Be sure to consider purpose and scope when deciding whether and how to mitigate these risks. For example, requirements would be more stringent in a policy safeguarding mobile access to healthcare data and applications than in a basic BYOD policy.

You might limit devices that you're willing to accept, such as Android for employee-owned tablets but not for patient care tablets. Or, you could specify tighter security settings like fingerprint access control on patient care tablets or four-digit PINs.