EUD Security Guidance: Android 7

This guidance is applicable to Android 7 devices configured in Device Owner (i.e. corporate liable) mode. This mode provides an organisation with the highest level of control over an Android device.

This guidance does not cover Android 7 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 7:

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 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 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 only the Foundation 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 cannot support the always on feature. This increases the risk of data leaking outside the corporate network. However, Android 7 makes always on VPNs possible for third party applications, so this feature could be added. At the time of writing, there are no third party VPNs which can meet the PRIME profile and provide always-on functionality.
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. A lock screen bypass vulnerability or physical attack on the device may result in compromise of data. File-based encryption (FBE) was introduced in Android 7 and is enabled by default for new devices. Devices upgrading from Android 6 can switch to FBE if the device is wiped and restored. With the FBE mode of operation, each user has two storage locations. One location is credential encrypted (CE) and the other is device encrypted (DE). Application developers need to use these storage locations correctly to ensure the security of their applications’ data. The DE storage is available after boot but before the user has unlocked the device in what is referred to as Direct Boot mode. Data stored in this location could be acquired by an attacker without knowledge of the device password, but in general this should not be a significant risk as applications should not store sensitive data in these locations. The CE storage is only available after the user has unlocked the device with their password. Android 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	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.

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	If a third party VPN client that supports the PRIME IPsec profile becomes available that supports the Always On setting, use this. 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: Storage performance fast enough to enable Storage Encryption A Hardware-backed Key Store (managed by Trusted Execution Environment, or TEE) to ensure keys and passwords are securely stored on device (see Settings > Security > Credential Storage > Storage Type). If external storage is required, devices should be from OEMs who add external storage encryption to their devices. SD card encryption is not a standard feature of Android Enable the device’s native storage encryption via MDM policies. Disable backups to untrusted locations: Disable automatic cloud backup during provisioning. Apply MDM policies to disable Android Debug Bridge (ADB). 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.
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 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 for Work. An organisation’s applications can be distributed in a privately 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. 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 7’s new network security configuration to specify certificates accepted for pinning. Certificate pinning for third-party applications is 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. Verify Apps 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.
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 and allow the setting of automatic 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 its expected lifetime. 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 7 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. 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 – 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 supports wiping of both internal and external 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, 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 Android for Work – Device Owner 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 for Work. Your organisation’s internal apps should be made available via Google Play for Work 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 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 methods are available:
- User driven flow:

1. 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 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. These should be unchecked.

Device (NFC) driven flow:

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:

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 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.

Device (QR Code) driven flow:

This method is also dependent on the choice of MDM.

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.

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.

Recommended policies and settings

This section details important security policy settings for an Android 7.x 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 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
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 7 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 7.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 7.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

Issues specific to Android deployments.

Cloud integration and privacy

Android for Work devices require the 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, 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.

Source: NCSC

With over 20 years of experience, Serviceteam IT design and deliver sophisticated connectivity, communication, continuity, and cloud services, for organisations that need to stay connected 24/7. We take the time to fully understand your current challenges, and provide a solution that gives you a clear understanding of what you are purchasing and the benefits it will bring you.

To find out how we can help you, call us on 0121 468 0101, use the Contact Us form, or why not drop in and visit us at 49 Frederick Road, Edgbaston, Birmingham, B15 1HN.

We’d love to hear from you!