EUD Security Guidance: Android 6

This guidance is applicable to Android 6 devices configured in Device Owner mode. This mode (i.e. corporate liable) provides an organisation with the highest level of control over an Android device. This guidance does not cover the use of Android 6 in a scenario in which personal use of the phone is done in a separate profile.

It is important to remember that any guidance points given here are just recommendations. None of the suggestions should be seen as being mandatory. They have been suggested as a way of satisfying the 12 End User Device Security Principles. 

Risk owners and administrators should agree a configuration which balances the business requirements, usability and security of the platform.

Risk owners’ summary

We recommend the following architectural choices for Android 6:

• All data should be routed over a secure VPN to ensure the confidentiality and integrity of the traffic. This will allow the devices and data on them to be protected by your organisation’s protective monitoring solutions.
• Publicly available apps that are required by your organisation should be whitelisted and either pushed to devices automatically or made available within Google Play for Work. In-house applications should be defined within the Mobile Device Manager (MDM) and distributed via a Google Play for Work private channel.

When configured in this way, risk owners should be aware of the following technical risks associated with this platform:

Associated security principle	Explanation of risks
Assured data-in-transit protection	The built-in VPN is not assured to Foundation grade, and no suitable assured third-party products exist. The built-in VPN does not support the PRIME IPsec profile. The weaker PRIME interim profile must be used instead, which increases the risk of data being compromised in transit. Third-party VPN clients cannot be configured into always-on mode as the built-in VPN can, so the built-in VPN should preferred over using a third-party VPN client.
Assured data-at-rest protection	Android data encryption is not assured to Foundation Grade, and no suitable assured third-party products exist. Encryption keys protecting sensitive data remain in device memory when the device is locked. Android 6.0 normally supports encryption of external storage only if the external storage is “adopted” as part of the internal storage. If external storage is configured as “portable” it will not be encrypted. This configuration can only be defined at the time of adding external storage and cannot be controlled by policy. Some OEMs may add SD card encryption to their devices for non-adopted storage, but this feature is not present on all Android devices.
Device Update Policy	MDM policy cannot enforce the automatic update of applications. Google Play can be configured to automatically update applications, but users can’t be blocked from subsequently turning off this option.
Event collection for enterprise analysis	There is no facility for collecting detailed logs remotely from a device.

Administrators’ deployment guide

Overview

To meet the principles outlined in the End User Devices Security Framework, several recommendations are given in the table below.

Security Principle	Recommendation and Explanation
Assured data-in-transit protection	Use the built-in Android IPSec VPN client until a Foundation Grade VPN client for this platform becomes available. Configure the VPN and the Always-On setting before disabling users’ access to the VPN settings via MDM policy.
Assured data-at-rest protection	Enable the device’s native storage encryption via MDM policies if the device has fast enough storage performance. Administrators should be aware that different Android devices have different security properties. Only devices with the following properties should be used: Device performance fast enough to enable Storage Encryption A Hardware-backed Key Store (managed by trusted execution environment (TEE)) to ensure keys and passwords are securely stored on device (see Settings > Security > Credential Storage > Storage Type). If external storage is required, devices must be from OEMs who add external storage encryption to their devices. SD card encryption is not a standard feature of Android 6.0. Disable backups to untrusted locations: Disable automatic cloud backup during provisioning. Apply MDM policies to disable ADB. Be aware of applications that perform backups independently of device settings.
Authentication	The user should be required to authenticate to the device in line with your organisation’s authentication policy (see Authentication Policy). Your organisation’s services should be configured to use X.509 client certificate authentication where possible. Devices should be provisioned with user specific client certificates. The native mail client and Chrome browser can use these for authentication.
Secure boot	Administrators should only provision Android devices with locked bootloaders. Users should be educated on the warnings they will see if the bootloader is tampered with. To prevent, users from unlocking the bootloader using the OEM Unlock feature, Developer Options should be disabled by policy in the MDM. On most devices unlocking the bootloader should wipe a device. However, if the bootloader is unlocked at provisioning time, or unlocked by exploiting a platform vulnerability, then the device will remain in an insecure state. It is possible to unlock a device, modify it, and then relock it. It cannot be assumed that any device received, other than directly from the OEM, is in its original state.
Application Whitelisting	Administrators can automatically push apps to devices or whitelist apps available for download within Google Play for Work. An organisation’s applications can be distributed in a non-public manner using Google Play for Work and private catalogues. Applications can be hosted on an organisation’s infrastructure but Google Play will be used to co-ordinate the distribution to users’ devices. Users can be prevented from installing applications from unauthorised sources.
Malicious code detection and prevention	Only approved applications should be permitted to be installed via Google Play for Work. Content-based attacks can be filtered by scanning capabilities within your organisation. Google Play checks for potentially harmful applications at the time of install, and at regular intervals in the background. Several third-party anti-malware products exist which attempt to detect malicious code for this platform. These can be used if desired. Android displays an alert if trusted credentials are installed that enable the interception of encrypted communications. Certificate pinning is used in certain Google applications to prevent interception and modification of SSL traffic. Certificate pinning for third-party applications is also possible but would need to be managed via an MDM solution supporting such functionality.
Platform integrity and application sandboxing	No configuration is required. SELinux in enforcing mode (mandatory) significantly enhances platform integrity and sandboxing. The scope of SELinux has been improved with Android 6.x. In addition, applications that target the Android 6 (level 23) API can request permissions at runtime instead of on install. Such runtime requests for permissions can be managed by the device owner and set in policy to be automatically accepted or denied instead of prompting the user.
Security policy enforcement	Security policy can be managed centrally via the MDM to enforce security settings. However, some security related settings are configured only by the user, including those for the built-in VPN. The user cannot disable Device Owner mode (unless the MDM enables this). They can only cause a factory reset.
External interface protection	USB debugging can be disabled completely by disabling developer options on the MDM. In Device Owner mode, MDM controls can be used to prevent the user from configuring Wi-Fi and Bluetooth.
Device Update Policy	MDM software can be used to audit which apps and OS versions are installed on a device. Android 6 has introduced an API to allow the device owner to set the update policy including automatic install of system updates. Some Android OEMs have committed to a monthly release schedule for system updates, designed to ensure that vulnerabilities are addressed promptly. The OEM documentation should be checked to determine whether the make and model of device will be supported with regular system updates for the expected lifetime of the device. Carriers may also be responsible for rolling out device updates in a timely manner, but the average time taken to patch vulnerabilities and bugs varies between OEMs and carriers. Consequently, care should be taken to ensure that the selected OEMs and carriers have a good track record of patching devices, when choosing which platforms to deploy. Your organisation has limited control of when application software is updated because this is dependent on a setting in Google Play that cannot be restricted by MDM policy. A partial mitigation is to enable automatic updates in Google play and educate users to not disable it. Applications that are required by MDM policy, including updated applications, can be pushed to devices.
Event collection for enterprise analysis	Android does not support remote or local historic detailed event collection. It is not possible to display or collect many security-related events, including detailed failed device login information. However, MDM solutions can be used to retrieve some information from the device, such as: – Installed applications – Android version information – Last time device seen by MDM  – Number of failed password attempts – Network state – Compliancy status (depending on the compliancy rules set up on the MDM server) – Enrolment status – Location information – Roaming Status
Incident Response	Android 6 supports wiping of both internal and external storage (previously it was just the internal storage). MDM/EMM solutions which support this can be used to remotely wipe devices if lost or stolen. Access to your organisation’s network can be prevented by revoking the VPN client certificate associated with a lost or stolen device. However, this should only be done after the remote wipe command has been confirmed or a certain amount of time has passed. Otherwise the device will be unable to connect to the MDM server to receive the wipe command. Additionally, the client certificates for any other organisation’s servers (such as email) that are stored on the device should be revoked.

Recommended network architecture

All remote or mobile working scenarios should use a typical remote access architecture with a VPN terminating into a DMZ. The use of a web proxy is recommended, though the Android system proxy setting is not necessarily honoured by all applications. The use of a transparent proxy is therefore recommended if Internet filtering is required for all applications on the device.

Preparation for deployment

For a deployment of Android devices suitable for organisation’s working with sensitive data, administrators should:

1. Deploy and configure the requisite network components as described above.
2. Procure and set up an MDM server that supports Android for Work Device Owner mode and is able to enforce the settings given in the Policy Recommendations section below.
3. Set up a dedicated Wi-Fi provisioning network.
4. Create MDM security profiles for the Android devices in line with the guidance given in the Policy Recommendations section, and associate these profiles with the devices.
5. Define the apps that should be automatically installed onto devices including a Secure Email Client. Optional apps should be whitelisted and made available within Google Play for Work. Internal apps should be made available via Google Play for Work private channels. Internal applications can be hosted on your organisation’s infrastructure, but Google Play will be used to co-ordinate the distribution to users’ devices.

Device provisioning steps

The following steps should be followed to provision each end user device onto your organisation’s network in preparation for distribution to end users.

• Sign up for Android for Work by creating a Google admin account for your organisation’s domain and verifying administration rights over the domain (through a DNS record, web page or <meta> tag on the website). Retrieve the token from Google and bind to the chosen MDM.
• Add and create a Google user account within the MDM (the primary email address will use the company domain). Depending on the MDM solution it may be possible to create users based on an existing Active Directory structure.
• Configure the client certificates for each user within the MDM solution. The following certificates are required:
  • Organisation’s CA certificate (used to validate the server certificates presented by the VPN endpoint and reverse proxy)
  • VPN client certificate (for authentication to your organisation’s VPN endpoint)
  • SSL client certificate (for authentication to the reverse proxy presentation layer for intranet services)
     
• Provision of the handsets into Device Owner mode can only occur on the first boot or after a factory reset. The following two methods are available:
  • User driven flow:
    • 1. During the initial configuration after setting up WiFi to connect to the provisioning network, the administrator enters the user’s google account associated with Android for Work.
    • 2. The administrator is then told that the account requires a Device Policy Controller (DPC) which you should then install. This is automatically registered with the user’s account and starts enforcing policy immediately.
    • 3. The administrator is then presented with some options to use Google auto-backup services, location services and send anonymised usage data to Google which must be unchecked.
  • Device (NFC) driven flow:

The method of provisioning will be unique to each MDM, therefore follow the instructions provided by the MDM provider. The next steps provide a general overview of what is required:

1. Download and install the MDM NFC provisioning application onto a dedicated provisioning handset.
2. If the provisioning application supports configuration via NFC, configure the user enrolment details and perform a second bump to enrol a specific user with the MDM. This may not be available for all solutions and it may simply be the case that the user logs into the corporate Google account on the DPC application to download the policy and start enforcing it.
3. Perform an NFC bump between the provisioning handset and the target handset to configure the Wi-Fi and install the Device Policy Controller (DPC) application onto the end user’s device.
4. Configure the provisioning application with a URL for the DPC application APK file and details for the provisioning Wi-Fi network.

A legacy activation code method is available for Android 5 devices, but is not applicable to Android 6.

Information on provisioning a device into Device Owner mode can be found here: https://developers.google.com/android/work/prov-devices#modes_of_operation

• Configure on-device security settings
• Configure the VPN client to connect to your organisation’s VPN endpoint, using the device-specific client certificate which has been loaded onto the device. Enable ‘Always-On’ VPN. It is not possible to configure the VPN via policy and must be done procedurally. This requires an initial policy for the user that allows VPN configuration and a method to load certificates onto the device. Once the VPN is configured and set to always on, the policy needs to be changed to block access to the VPN configuration by the device user
• Configure the email client to connect to your organisation’s server using client certificate authentication.

Recommended policies and settings

This section details important security policy settings which are recommended for an Android 6.x deployment. Other settings (e.g. server address) should be chosen according to the relevant network configuration. It is important to remember that any guidance points given here are just recommendations, none of the suggestions are mandatory. Risk owners and administrators should agree a configuration which balances business requirements, usability and security of the platform. Consult this guidance for advice where needed.

As all Android MDMs vary, the text accompanying the setting may be different to that shown below.

Policy Setting	Recommended Value
Compliance Rules (or ‘Safety Net’)	If an insecure device is identified (e.g. device found to be rooted) take appropriate mitigating action such as notifying an administrator, revoking VPN certificates or blocking further access to corporate resources.
Email Rules	Access should be prevented for non-enrolled devices.
Allow non-provisioned devices	False
User Restrictions
Disallow add secondary user	True
Disallow remove user	True
Disallow tethering configuration	True
Disallow hotspot configuration	True
Disallow debugging features	True
Disallow install from unknown sources	True
Disallow adding or removing accounts	True
Disallow mounting of physical media (e.g. SD cards). NB. Use this if SD card slot is available, but OEM does not enhance encryption mechanism to include external storage.	True
Disallow outgoing beam	True
Disallow USB file transfer	True
Ensure verify apps	True
Disallow credential changes	True
Disable controlling installed applications	True
Disallow Location sharing	True
Disallow developer options	True
Other
Require encryption on device	True
Disable VPN access configuration	True
Disable Account Management	True
Application Specific Restrictions	Use where available (e.g. Chrome)
Use Auto Time	True
Disable ADB	True
Disable Screen Capture	True
Bluetooth	Off
On device Settings
NFC	Off
ActiveSync Settings (if used)
Enable Security Restrictions	True
Allow Data Backup	False

Authentication policy

Your organisation should have a consistent authentication policy which applies to all users and devices capable of accessing its data. You can use the published password guidance to help inform any password policy. Android 6 implements a number of settings which should be configured in line with the authentication policy, by the administrator.

For further guidance on defining an authentication policy, see the EUD Security Guidance introduction.

To enforce this policy on Android devices, the following settings are available, and should be set according to the policy:

• Require password
• Require complex password
• Minimum number of upper case characters
• Minimum number of lower case characters
• Minimum number of numeric characters
• Minimum number of symbols
• Allow simple password
• Number of failed attempts allowed
• Minimum password length
• Time without user input before password must be re-entered
• Enforce password history
• Disable all keyguard features (includes disabling display of data and widgets on Lock Screen, and Smart Lock)

Hardware strengthening

Android 6.0 devices are required to implement a hardware-backed keystore. This means that successful authentication is required to use dedicated hardware (normally a Trusted Execution Environment, or TEE), and this prevents offline brute force attacks against data-at-rest keys. However, this mechanism does not prevent online attacks from privileged malware running on the device.

Biometrics

Android 6.0 devices are required to perform biometric checking within a Trusted Execution Environment (TEE). This means that a physical attack on a locked device should not result in compromise of data. Fingerprint readers are required to have less than 0.002% false acceptance rate, but the performance of individual sensors can vary within that range. You should consider these limitations when devising an authentication policy which permits the use of biometrics.

Other considerations

The following points contain specific issues for Android deployments.

Cloud integration and privacy

Android for Work devices require a user to have a Google work account for management, though this account is prevented from using other Google services such as Google Apps and Google Docs. Use of this Google account could result in unexpected data leakage to cloud services.

Android devices are usually configured by default to send anonymous usage data (including location, device ID etc.) to Google servers. This can be disabled through device settings, which will need to be enforced through procedural controls.

Location services can be disabled via MDM. Individual applications will often use application tracking services that may leak device information. These could be monitored and blocked when a VPN is active. Android may use location services and generate Wi-Fi beacons even when in airplane mode. This configuration can be disabled in advanced Wi-Fi settings.

Time to patch

Due to the number of separate entities involved in the creation, approval and distribution of updates for Android devices, the time between a vulnerability being exposed and an update being made available for a specific device can vary considerably. When selecting Android devices, it is important to select an OEM and carrier who have a good track record of supporting the latest platforms and releasing security fixes promptly.

Many OEMs are now committed to issuing monthly security updates, and these OEMs should be preferred where possible. MDM products can be used to track which security updates have been applied to each device in order to help update or upgrade those devices.

Source: NCSC