I read that Android M will offer a number of security improvements over Lollipop. What are these Android M security...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
features and how will they affect enterprise security?
Google's Android M tackles one of the big frustrations users have when installing new applications: the all-or-nothing approach to runtime permissions. Least privilege is a core security principle, but currently during the Android app installation process, users have to grant all the permissions an app requests or abandon the install. Granting wide-ranging permissions is a security risk, particularly when users don't understand why an app needs a particular permission and the context in which it'll be used. The only permission a user can actually disable on previous versions of Android is access to location data, but this has to be applied to all apps at the same time.
Android M security features include a new permission model that allows users to install apps without agreeing to important privacy-related permissions first. Instead, when an app needs to use these permissions for the first time, it will present a permission request pop-up to the user. Making a permission request when it's actually needed means users will better understand the context in which the app will use the permission. For example, a photo app may ask for camera and camera roll access when first launched, but will only request access to the contacts' data if the user wants to share a photo. Users can choose whether or not to grant permissions to an app on a one-time or permanent basis and can revoke a permission that has already been granted. Low risk permissions like VIBRATE that only give access to isolated application-level features will not prompt for permission at run-time but will still be granted permission at install time.
Apps using the old apps permissions model will still need to be granted all requested permissions at install time, but users can change them afterwards in app settings, which will show the full list of an app's permissions. Another useful feature is users will be able to sort and view apps by the permissions they need access to. Probably the most abused permissions are access to contacts, browsing history, Wi-Fi connection information and location information, as this data is used heavily in targeted advertisements. The new apps permissions model will certainly help users easily see which apps have access to what. Making security easier always makes data more secure.
The changes introduced in M will hopefully bring down the number of apps that request excessive and intrusive permissions and help reduce the number of insecure or poorly coded apps. Enterprises will need to ensure any apps they develop account for permissions that don't get granted or are revoked by the user and can continue to work without malfunctioning; older apps that aren't designed for runtime permissions are fed empty data if they don't have the right permission. Developers should certainly make use of the new APIs in M that help find instances where an app attempts to send data over an unencrypted socket, either logging packets that are in cleartext or blocking further traffic on that socket to prevent accidental data leakage. Many developers may rail against this new apps permissions policy, but genuine developers will benefit from being able to engage with users who previously were uncomfortable giving blanket permissions to a new app. It will certainly hamper attempts by malicious apps from gaining excessive permissions and syphoning off sensitive user data held on an Android device.
Also included in Android M security features are the Fingerprint and Confirm Credential APIs that enable users to complement their PIN with their fingerprint to authenticate themselves and authorize payments. Although some Android phones have their own fingerprint scanners, these have been added to the OS by the OEM. This system-level support for biometric authentication methods should make unlocking access to data easier, yet more secure. The Backup Manager in M will automatically upload private application data from all installed apps to the user's Google Drive account, where it is encrypted and stored, unless the user chooses to opt out or the app developer has set the android:allowBackup attribute to false.
Enterprises are still advised to use mobile device management software to block access to sensitive data on mobile devices, as many Android users won't have the latest version or patches. Only 12% of devices running on Android have the latest version with the latest bug fixes, vulnerability patches and security updates, and it's up to the carriers to decide when users receive any upgrade. Users should all be made aware that apps should only be downloaded from trusted sources and permissions to sensitive data only granted when truly necessary.
Discover how to secure Android devices with a mobile device security policy
Find out how to avoid mobile application security risks
Dig Deeper on Alternative operating system security
Related Q&A from Michael Cobb
Can two-factor authentication be applied to a mobile device that's used as a 2FA factor? Michael Cobb explores the different knowledge factors and ...continue reading
Running a private certificate authority can pose significant risks and challenges to meet baseline requirements. Michael Cobb explores what ...continue reading
A recently discovered Android app permissions flaw can expose users to attacks. Michael Cobb explains what the risks are and how Android O security ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.