Guidance

End User Devices Security Guidance: Google Chrome OS 26

Updated 14 October 2013

This guidance was withdrawn on

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

This guidance is applicable to devices running Chrome OS 26 and later. This guidance was developed following testing performed on Samsung Chromebooks running Chrome OS version 26.0. All device management services are provided by Google Infrastructure. This guidance was prepared with the provided versions as of June 2013.

1. Usage Scenario

Chrome OS devices will be used remotely over any network bearer, including Ethernet, Wi-Fi and 3G, to connect back to enterprise services over a VPN. This enables a variety of remote working approaches such as

  • accessing OFFICIAL email through an enterprise-provided web portal;

  • creating, editing, reviewing and commenting on OFFICIAL documents through an enterprise-provided web portal;

  • accessing the OFFICIAL intranet resources, 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 benefit from enterprise protective monitoring solutions.

  • Users of Chrome OS devices should not use unaccredited enterprise or Internet services to store or process OFFICIAL email, documents or web applications.

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. The VPN can be disabled by the user.
2. Assured data-at-rest protection The built-in data encryption has not been independently assured to Foundation Grade.
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 Only limited technical controls can be exercised over user access to physical and wireless interfaces on the device.
10. Device update policy
11. Event collection for enterprise analysis [!] It is not possible to display security related events such as failed logins
12. Incident response

2.1 Significant Risks

The following significant risks have been identified:

  • The VPN has not been independently assured to Foundation Grade. In addition, there is potential for the user to disable the VPN at any time and some Google traffic is sent prior to the VPN being established. These shortcomings in the VPN increase the risk that data transiting from the device could be compromised.

  • Chrome OS data encryption 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.

  • Chrome OS relies on Google services to authenticate users to the device, and to manage the device. Trust in Google’s online services is essential for enterprise deployments of Google Chrome

  • There is no account lockout to prevent brute force attacks when the device is offline, however authentication attempts are hardware rate limited through the on-board TPM.

  • Collection of events for enterprise analysis is limited, meaning protective monitoring and forensic analysis following any compromise may be much harder than on other platforms.

  • Only limited policy controls are available to restrict the external interfaces a user can enable, meaning that external interfaces may be accidentally or deliberately enabled by the end-user.

3. How the Platform Can Best Satisfy 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 native Chrome OS data encryption without additional configuration.

3.3 Authentication

Use a strong 9-character password to authenticate to the device. It is not possible to technically enforce some aspects of password complexity on Chrome OS, hence the increased password length versus some platforms.

Enterprises can choose to enable two-factor authentication on Chrome OS which will require the user to enter the second factor on first login and any subsequent password changes.

3.4 Secure boot

This requirement is met by the platform without additional configuration. Users should be educated to recognise when secure boot has failed and respond appropriately.

3.5 Platform integrity and application sandboxing

Implicitly provided by the platform.

3.6 Application whitelisting

Authorised apps and extensions can be managed using a whitelist in Google Management Console.

3.7 Malicious code detection and prevention

Chrome does not support side-loading of applications. Content-based attacks can be filtered by scanning on the email server.

3.8 Security policy enforcement

The security policy can be managed in Google Management Console to centrally enforce security settings, however some security related settings are configured only by the user, including those for VPN and Bluetooth.

3.9 External interface protection

No technical controls exist to prevent users from enabling Wi-Fi and Bluetooth, or using certain USB devices. The use of removable USB media can be disabled by policy.

3.10 Device update policy

Operating system security updates can be configured via the Google Management Console to be either automatically or manually applied. Using the recommended automatic setting, updates are installed automatically when the device is switched on and logged in. System updates are applied when the user restarts their Chrome OS device.

3.11 Event collection for enterprise analysis

The Google Management Console shows a limited amount of information about enrolled Chrome devices. It is not possible to display or collect many security related events, including failed logins.

3.12 Incident response

There is no remote wipe functionality available for Chrome OS. User accounts can be disabled or suspended from within the Google Management Console. 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. Architecture

All remote or mobile working scenarios should use a typical remote access architecture based on the Walled Garden Architectural Pattern. The following network diagram describes the recommended architecture for this platform.

Chrome OS Network Diagram

Recommended network architecture for deployments of Chrome OS devices

5. Deployment Process

The following steps should be followed to prepare the enterprise infrastructure for hosting a deployment of these devices:

  1. Procure and provision a Google Apps for Business account which also creates the Administrator account for use by the enterprise.

  2. Procure and provision a Google Enterprise Management Console Account using the previously created Administrator account.

  3. Purchase device licenses for the Google Management Console from the Google store

  4. Change the temporary password for the account.

  5. Recommended: Enable Google two-factor authentication for Admin account.

  6. Verify domain ownership.

  7. Setup Google Apps and Enterprise accounts according to requirements.

  8. Create profiles as defined in the Policy Recommendations section below.

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. Enrol Chrome OS device

  2. Add users to your domain

7. Policy Recommendations

The following settings can be applied from the Enterprise Management Console

Configuration Rule Configuration Setting
Device Settings → Enrol Devices Automatically Enrol Devices Automatically
Device Settings → Allow Guest Mode Do not allow guest mode
Device Settings → Sign-In Restriction *@{company domain}
Device Settings → Sign-in Screen Never show usernames and photos
Device Settings → Public Session Do not allow public session
Device Settings → Auto Update Allow auto-updates
Device Settings → Anonymous Metric Reporting Never send metrics to Google
Device Settings → Device State Reporting Enable device state reporting
User Settings → Allowed Apps and Extensions Block all apps and extensions except the ones I allow
User Settings → Safe Browsing Always enable Safe Browsing
User Settings → Screen Lock Always automatically lock screen on idle
User Settings → Malicious Sites Prevent user from proceeding anyway to malicious sites

In addition the following settings and steps must be performed manually on each device to be deployed. The settings are applied per-user, and therefore the person setting up the device must log into the Chrome device as the user to be set up. This may require resetting the user’s password before and after deployment.

Configuration Rule Value
Settings → Advanced Settings → Bluetooth Off (unless required)

7.1 VPN Profile

Setting Value
IKE DH Group 2 (1024-bit)
IKE Encryption Algorithm AES-128 CBC
IKE Hash Algorithm SHA-1
IKE Authentication Method RSA X.509
IPsec Encryption AES-128 CBC
IPsec Auth SHA-1
SA Lifetime 24 hours

7.2 Enterprise Firewall

To facilitate connections to Chrome OS devices and services, the following steps should be followed.

  • Firewall rules should be configured to allow users to access the VPN terminator.

  • If SSL intercepting proxies are used within the environment they should be configured to whitelist Google services as these services often use certificate pinning and fail to work when intercepted.

8. Enterprise Considerations

8.1 Secure Boot

The Chrome Secure Boot process alerts a user when an attempt to subvert the security controls has taken place. It is important to ensure users know how to identify and respond to this alert.

8.2 Enterprise Services

Users of Chrome devices should not use unaccredited enterprise services to store or process OFFICIAL email, documents or web applications, which may include the default public Google services. As with any online service, enterprises should ensure that the services used by the platform for storing or processing OFFICIAL information are appropriately accredited.