Guidance

End User Devices Security Guidance: Samsung Devices with Android 4.2

Updated 14 October 2013

This guidance was withdrawn on 9 June 2016

This content has been moved to the CESG website: https://www.cesg.gov.uk/eud-guidance

This guidance is applicable to Samsung devices running Android 4.2.2 and supporting the Samsung SAFE API. This guidance was developed following testing performed on Samsung Galaxy S4 devices running Android 4.2.

1. Usage Scenario

Samsung Android devices will be used remotely over 3G, 4G and non-captive Wi-Fi networks to enable a variety of remote working approaches such as accessing OFFICIAL email; reviewing and commenting on OFFICIAL documents, and accessing the internet and other web-resources.

To support these scenarios, the following architectural choices are recommended:

• All data should be routed over a secure enterprise VPN to ensure the confidentiality and integrity of the traffic, and to allow the devices and data on them to be protected by enterprise protective monitoring solutions.

• Arbitrary third-party application installation by users is not permitted on the device. An enterprise application catalogue should be used to whitelist and distribute approved applications to devices.

2. Summary of Platform Security

This platform has been assessed against each of the twelve security recommendations, and that assessment is shown in the table below. Explanatory text indicates that there is something related to that recommendation that the risk owners should be aware of. Rows marked [!] represent a more significant risk. See How the Platform Can Best Satisfy the Security Recommendations for more details about how each of the security recommendations is met.

Recommendation	Rationale
1. Assured data-in-transit protection	The built-in VPN has not been independently assured to Foundation grade, and no suitable third-party products exist.
2. Assured data-at-rest protection	Samsung's data encryption has not been independently assured to Foundation Grade. Encryption keys protecting sensitive data remain in device memory when the device is locked.
3. Authentication
4. Secure boot
5. Platform integrity and application sandboxing
6. Application whitelisting
7. Malicious code detection and prevention
8. Security policy enforcement
9. External interface protection
10. Device update policy	The enterprise cannot force the user to update their device software.
11. Event collection for enterprise analysis	[!] There is no facility for collecting detailed logs remotely from a device.
12. Incident response

2.1 Significant Risks:

The following significant risks have been identified:

• The VPN has not been independently assured to Foundation Grade, and currently does not support some of the mandatory requirements expected from assured VPNs. Without assurance in the VPN there is a risk that data transiting from the device could be compromised.

• Samsung’s data encryption product has not been independently assured to Foundation Grade, and does not support some of the mandatory requirements expected from assured full disk encryption products. Without assurance there is a risk that data stored on the device could be compromised.

• Samsung’s devices do not use any dedicated hardware to protect disk encryption from offline attacks. An attacker who gets physical access to a device can perform an offline brute-force attack to recover the device password.

• Encryption keys protecting sensitive data remain in device memory when the device is locked. This means that if the device is attacked while powered on and locked, keys and data on the device may be compromised without the attacker knowing the password.

• Procedural controls are used to achieve some of the requirements where no technical controls could be used, which means that users have to be trusted not to alter certain settings on the device, or perform actions which may impact the security of the device. These controls are discussed in later sections. Denying access to the Settings application may help mitigate this issue.

• User action is required to apply device updates, this may lead to security issues not being patched.

3. How the Platform Can Best Satisfy the Security Recommendations

This section details the platform security mechanisms which best address each of the security recommendations.

3.1 Assured data-in-transit protection

Use the native IPsec VPN client until a Foundation Grade VPN client for this platform becomes available.

3.2 Assured data-at-rest protection

Use the device’s native data encryption. The data is protected when powered off, but it is not protected when the device is locked.

3.3 Authentication

The user has a strong 9-character password to authenticate to the device. There is no dedicated hardware protection for passwords.

3.4 Secure boot

Administrators should only provision Samsung devices with locked bootloaders.

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.

3.5 Platform integrity and application sandboxing

This requirement is met by the platform without additional configuration.

3.6 Application whitelisting

SAFE APIs can be used to whitelist applications, or to blacklist applications which require certain permissions to run.

3.7 Malicious code detection and prevention

Several third-party anti-malware products exist which attempt to detect malicious code for this platform. Where possible an enterprise application catalogue can be used which should only contain vetted apps. Content-based attacks can be filtered by scanning capabilities in the enterprise.

3.8 Security policy enforcement

The security policy can be managed centrally via the MDM to enforce security settings, however some security related settings are controlled only by the user, including those for VPN. To mitigate this, the Settings application can be disabled but this may compromise the user experience.

3.9 External interface protection

SAFE APIs can be used to disable external interfaces such as Wi-Fi, Bluetooth, USB and NFC if required.

3.10 Device update policy

MDM software can be used to audit which apps and OS versions are installed on a device. The enterprise cannot control when the applications or OS software are updated. These updates rely on user interaction.

System updates are applied when the user restarts their device.

3.11 Event collection for enterprise analysis

Samsung Android devices do not support remote or local historic detailed event collection.

It is not possible to display or collect many security related events, including failed device logins.

3.12 Incident response

Samsung Android devices support remote wipe when used in conjunction with a suitable MDM, which can be configured to selectively wipe internal or external memory, or both.

Access to the enterprise network can be prevented by revoking the VPN client certificate associated with a lost or stolen device. Additionally, the client certificates for any other enterprise servers (such as email) that are stored on the device should be revoked.

4. Network Architecture

It is recommended that all remote or mobile working scenarios use a typical remote access architecture based on the Walled Garden Architectural Pattern.

Recommended network architecture for deployments of Samsung devices with Android 4.2

5. Deployment Process

For an enterprise deployment of Samsung Android devices that is suitable for organisations working with OFFICIAL data, administrators should:

1. Deploy and configure the requisite network components as described above

2. Procure and set up an MDM server with a client that implements the SAFE APIs and is able to enforce all the settings given in the Policy Recommendations section below.

3. Create MDM security profiles for the devices in line with the guidance given in Policy Recommendations section, and associate these profiles with the devices.

6. Provisioning Steps

The following steps should be followed to provision each end user device onto the enterprise network to prepare it for distribution to end users.

1. Install the MDM agent app, and enrol the device into the MDM

2. Provision client certificates by either:

   1. Provision the client certificates using a locally-enrolled MDM server;

   2. Deploy the Android Development Tools (ADT) bundle and device-specific USB drivers onto a dedicated provisioning terminal. This will allow the client certificates to be manually deployed onto the device via the Android Debug Tool (adb). Note that USB debugging should be disabled once provisioning is complete.

   Certificates needed are:

   • Enterprise CA certificate (used to validate the server certificates presented by the VPN endpoint and reverse proxy)

   • VPN client certificate (for authentication to the enterprise VPN endpoint)

   • SSL client certificate (for authentication to the reverse proxy for intranet services).

3. Install apps required for enterprise productivity

4. Ensure that only trusted apps are installed and enabled on the device (disable unnecessary apps including Google Play)

5. Configure on-device security settings

6. Configure the VPN client to connect to the enterprise VPN endpoint, using the device-specific client certificate that has been loaded onto the device. Enable ‘Always-On’ VPN

7. Configure the email client to connect to the enterprise server using client certificate authentication.

7. Policy Recommendations

The following settings should be applied from the MDM interface. As all MDMs vary, the text accompanying the setting may be slightly different to that shown below.

Policy Setting	Recommended Value
Enrolment Rules	Enrolment of devices is only possible for an approved administrator as part of the device provisioning process
Compliance Rules	If a non-whitelisted application is detected on the device, take appropriate mitigating action such as notifying an administrator or blocking further access to corporate resources.
Email Rules	Access should be prevented for non-enrolled devices.
Allow non-provisioned devices	False
Password Complexity
Require password	True
Require complex password	True
Minimum number of upper case characters	1
Minimum number of lower case characters	1
Minimum number of symbols	1
Require encryption on device	True
Allow simple password	No
Number of failed attempts allowed	5
Minimum password length	9
Time without user input before password must be re-entered	10 (minutes)
Password expiration	90 (days)
Enforce password history	8
Show Data on Lock Screen Widgets	False

ActiveSync Settings (if used)
Enable Security Restrictions	True
Allow Data Backup	False

• Prevent user from deactivating and removing a Device Administrator application.

• Disable USB debugging.

• Blacklist applications based on required permissions

• Prevent users from associating their device with any other accounts (e.g Google, social networking)

8. Enterprise Considerations

The following points are in addition to the common enterprise considerations, and contain specific issues for deployments of Samsung devices.

8.1 VPN

On Samsung Android devices, users can alter the configuration of the VPN which can adversely affect the security of the device. Procedural controls must be present in the user security procedures to prohibit the altering of any settings related to the VPN. Alternatively, the SAFE MDM APIs can be used to remove access to the Settings application though this may compromise the user experience.

8.2 Cloud Integration

Samsung Android devices do not need to be associated with a Google account to operate as required within the enterprise. For example, it is still possible to receive push notifications through Google Cloud Messaging. SAFE MDM APIs can be used to prevent users from signing in to these services.

8.3 Privacy

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