This guidance is applicable to Android 8 devices configured in work-managed (i.e. corporate liable) mode (previously known as Device Owner mode). This mode provides an organisation with the highest level of control over an Android device.
This guidance does not cover Android 8 where personal use of the phone is carried out in a separate profile.
It’s important to remember that this guidance has been conceived as a way to satisfy the 12 End User Device Security Principles. As such, it consists of recommendations and should not be seen as a set of mandatory instructions requiring no further thought.
Risk owners and administrators should agree a configuration which balances business requirements, usability and security.
Risk owners’ summary
We recommend the following architectural choices for Android 8:
- 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 benefit from your organisation’s protective monitoring solutions.
- Publicly available apps required by your organisation should be whitelisted and either pushed to devices automatically or made available within the managed Google Play store. In-house applications should be defined within the Mobile Device Manager (MDM) and distributed via a Google Play private channel.
When configured in this way, risk owners should be aware of the following technical risks associated with the platform:
| Associated security principle | Explanation of risks |
|---|---|
| Assured data-in-transit protection | There are two options with different risk profiles: the native VPN client, or a third-party VPN client. There is currently no Foundation Grade assured option.
If using the native client, the always-on VPN feature can be enabled, but neither the Foundation profile for IPsec or the PRIME profile for IPsec is supported. This increases the risk of data being compromised in transit. Some third-party applications support the PRIME profile for IPsec, but at the time of writing, none support the always-on feature. This increases the risk of data leaking outside the corporate network. However, Android makes always-on VPNs possible for third-party applications, so this feature could be added. |
| Assured data-at-rest protection | File-based encryption (FBE) had been available since Android 7. FBE has two types of storage:
FBE in Android 8 cannot be used together with adoptable storage. On devices using FBE, new storage media (such as an SD card) must be used as traditional storage. If external media is used in devices with FBE, then the device must also support external storage encryption, otherwise unencrypted data may be written to the external media. |
| 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 | The organisation can collect some bug reports and logs if the MDM supports the feature. User consent is required each time detailed logs are collected. Caution should be exercised to ensure that logs are stored securely to the device by the MDM, even when storage to device is only temporary. |
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 | A third-party VPN client that supports both PRIME profile for IPsec profile and always-on should be used if one is made available.
Or, if no such third-party application is available, use the built-in Android IPsec VPN client and enable always-on. In either case, configure the VPN before disabling user access to VPN settings via MDM policy. When a Foundation Grade VPN client for this platform becomes available, switch to it. |
| Assured data-at-rest protection | Administrators should be aware that different Android devices have different security properties. Only devices with the following properties should be used:
Enable the device’s native storage encryption via MDM policies. Disable backups to untrusted locations:
Be aware of third-party applications that perform backups independently of device settings. |
| Authentication | The user should be required to authenticate to the device in line with your organisational 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. If your organisation requires multi-factor authentication (MFA), FIDO certified devices could be one way to satisfy this. |
| Secure boot | Administrators should check and only provision Android devices with locked bootloaders. Verification of locked bootloaders can be done via Key Attestation. 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. If available on the MDM, administrators should also prevent the compromised devices connecting to the organisation’s infrastructure.
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 re-lock it. You cannot assume that any device is in its original state, unless received directly from a trusted supplier. |
| Application whitelisting | Administrators can automatically push apps to devices, or whitelist apps available for download within Google Play.
An organisation’s applications can be distributed privately using Google Play 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.
Content-based attacks can be filtered by scanning capabilities within your organisation. 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. In-house developed applications can use Android’s network security configuration to specify certificates accepted for pinning. Certificate pinning for some third-party applications may be also possible but would need to be managed via an MDM solution supporting such functionality. When configured as per this guidance, Android will only be able to execute whitelisted application from Google Play or Enterprise App Catalogue. Google Play Protect checks for potentially harmful applications at the time of install, and at regular intervals in the background. Each app is protected by its own sandbox which is enhanced by controls such as SELinux and SECCOMP. Therefore, there is little additional value to be gained from any third-party anti-malware products in the platform. |
| Platform integrity and application sandboxing | No configuration is required. SELinux in enforcing mode (mandatory) significantly enhances platform integrity and sandboxing.
Android 8 offers the ability to utilise Autofill APIs within compatible apps, this should be disabled. For more information on the risks around Autofill functionality see this security whitepaper. |
| 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 work-managed 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 work-managed 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 and allow the setting of automatic system updates.
Some 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 its expected lifetime. With the introduction of Project Treble in Android 8, vendors are able to push updates to a user’s device much quicker as result of the core Android framework being split from the vendor implementation. Only certain devices currently support this feature. 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 supports remote logging and bug report collection. In corporate-liable devices, security relevant events such as Android Debug Bridge (ADB) activity, unlock and lock attempts, and application launching are logged and can be remotely retrieved.
In Android 8, support for network activity logging is also available. Network activity logging captures DNS requests and TCP connections made by the device, allowing administrators to remotely retrieve these logs after user approval. Caution should be taken with the storage of this data to the device, even if only temporary, and to also ensure that the MDM stores the data in a secure manner. This functionality is available dependant on the MDM provider. Additionally, Android bug reports can be remotely requested, though this requires interactive approval from the user before it is shared. The details available for remote viewing depend on the MDM provider. MDM solutions can also still be used to retrieve some information from the device, such as: – Installed applications |
| Incident response | Android supports wiping of both internal and external storage. MDM 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, 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 an access layer (or 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 organisation’s working with sensitive data, administrators should:
- Deploy and configure the requisite network components as described above.
- Procure and set up an MDM server that supports work-managed mode and is able to enforce the settings given in the Policy Recommendations section below.
- Set up a dedicated Wi-Fi provisioning network.
- Create MDM security profiles for Android devices in line with the guidance given in the Policy Recommendations section, and associate these profiles with the devices.
- Define the apps that should be automatically installed onto devices (e.g. secure email client). Optional apps should be whitelisted and made available within Google Play. Your organisation’s internal apps should be made available via Google Play private channels. Internal applications can be hosted on your own infrastructure, but Google Play will be used to co-ordinate the distribution to users’ devices.
Device provisioning steps
These steps should be followed to provision devices onto your network in preparation for distribution to end users.
- Sign up for Google Play 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 work-managed mode can only occur on the first boot or after a factory reset. The following methods are available:
The method of provisioning will be unique to each MDM, so you must follow the instructions provided with the product. The next steps provide a general overview of what is required:
User driven flow:
- During the initial configuration after setting up Wi-Fi to connect to the provisioning network, the administrator enters the user’s Google account associated with Android.
- 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.
- The administrator is then presented with some options to use Google auto-backup services, location services and send anonymised usage data to Google. These should be unchecked.
Device (NFC) driven flow:
- Download and install the MDM NFC provisioning application onto a dedicated provisioning handset.
- 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.
- Perform an NFC bump between the provisioning handset and the target handset to configure the Wi-Fi and install the DPC application onto the end user’s device.
- Configure the provisioning application with a URL for the DPC application APK file and details for the provisioning Wi-Fi network.
Device (QR Code) driven flow:
- If this provisioning method is supported by the MDM, the enterprise mobility management console will be able to generate a provisioning QR code.
- When the device is first booted, at the welcome page, tap the screen 6 times to enter the QR code setup page.
- Enter network details in order to download the QR code reader.
- The QR code reader will launch and must be used to scan the provisioning QR code.
- The code contains network details and the location of the DPC application which will be downloaded and executed.
Once provisioning has been completed:
- 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 when using a client which supports this feature. It is not possible to configure the VPN via policy so this must be done procedurally. This requires an initial policy for the user which allows VPN configuration and a method to load certificates onto the device. Once the VPN is configured and set to always-on, the policy should be changed to prevent the device user from accessing VPN settings.
- Configure the email client to connect to your organisation’s server using client certificate authentication.
Zero-touch deployment had been implemented on Android 8, although to make use of this functionality devices must be brought from specific zero-touch carriers or resellers.
Recommended policies and settings
This section details important security policy settings for an Android 8 deployment. Other settings (e.g. server address) should be chosen according to the relevant network configuration.
Remember, any guidance points given here are recommendations – they are not mandatory. Risk owners and administrators should agree a configuration which balances business requirements, usability and the security of the platform.
As all Android MDMs vary, so the text you see accompanying a setting may be different to that shown below.
These restrictions and settings can generally be applied by Device Policy Controller applications. However, some settings may be specific to certain devices or vendors and should be applied if available.
| 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. |
| Security logging enabled | True |
| Allow non-provisioned devices | False |
| User restrictions | |
| Disallow add secondary user | True |
| Disallow remove user | 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 Google Play Protect | True |
| Disable controlling installed applications | True |
| Disallow location sharing | True |
| Disallow developer options | True |
| Disable Autofill | True |
| Other | |
| Require encryption on device | True |
| Disable VPN access configuration | True |
| Disable account management | True |
| Managed configurations | User where available (e.g. Chrome) |
| Use auto time | True |
| Disable Android Debug Bridge (ADB) | True |
| Disable screen capture | True |
| 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 our password guidance to help inform any password policy. Android 8 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 your 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 8 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 (TEE) or a seperate tamper-resistant hardware chip). 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 8 devices are required to perform biometric checking within a Trusted Execution Environment (TEE) or on a chip with a secure channel to the 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
Issues specific to Android deployments.
Cloud integration and privacy
Android devices require the user to have a Google account for management. Though this account is prevented from using other Google services such as Google Apps and Google Docs, its use could still result in unexpected data leakage to cloud services.
Android devices are usually configured by default to send anonymous usage data to Google servers (including location, device ID etc…). 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 tracking services which can 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.
The Android Enterprise Recommended programme is a Google scheme which highlights devices that meet enterprise-specific requirements for devices and services. Organisations can use this scheme to simplify their device selection process
With the introduction of Project Treble in Android 8, the intention is to allow vendors to separate their specific implementation from the Android operating system framework. This is to reduce the timeframe of security fixes being released by Google to then being pushed to vendor’s devices. When updating from older versions of Android to Android 8, manufacturers can choose to support Project Treble or not. If the initial version of Android on a device is Android 8.0, then the Project Treble will be supported.
Source: NCSC
