Guidance

End User Devices Security Guidance: Google Chrome OS 32

Created:  10 Jun 2014
Updated:  08 Aug 2016
CESG Archive

Archive content originally produced by CESG that has not yet been absorbed into the new NCSC web pages.

Configuration guidance for the use of Chrome OS 32 for remote working at OFFICIAL.

Getting Started

Before reading this guidance, take the time to look at our overall Introduction to End User Device Security. This will give you some context on the thinking behind our advice and better enable you to apply the guidance to your particular circumstances.

Contents

 

1. Introduction

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

This document updates the previous guidance to cover Chrome OS 32. Some changes to the recommended configuration have been made to take account of new features and changed behaviours in the platform. The risk information given below has been updated to reflect that.

Deployments which followed the previous recommended configuration will need to be updated with the new configuration to take advantage of the enhanced platform features.

2. About this guidance

This Guidance is designed to help Risk Owners and Administrators understand the risks, security advantages and recommended configuration of Chrome OS 32 within a remote working environment at the OFFICIAL and OFFICIAL SENSITIVE classification. Risk owners are encouraged to read the Risk Owners' Summary and Enterprise Considerations sections. Administrators and system integrators are encouraged to read the whole document.

Risk owners are encouraged to read the Risk Owners' Summary and Enterprise Considerations sections. Administrators and system integrators are encouraged to read the whole document.

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 the business requirements, usability and security of the platform and use this guidance for advice where needed.

3. Risk owners' summary

When using Chrome OS 32 as part of a remote working scenario, the following architectural choices are recommended to minimise risk:

  • 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
  • Arbitrary third-party application installation by users is not permitted on the device. A list of allowed trusted apps and extensions can be configured within the Google Admin console

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 VPN has not been independently assured to Foundation Grade, and does not currently support some of the mandatory requirements expected from assured VPNs. The VPN can be disabled by the user and some Google traffic is sent prior to the VPN being established resulting in potential for data leakage onto untrusted networks. Without assurance in the VPN there is a risk that data transiting from the device could be compromised
Assured data-at-rest protection 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
Authentication Chrome OS relies on Google online services for user management and authentication.

 

 

There is no account lockout to prevent brute force password attacks when the device is offline. Logon attempts are hardware rate-limited when the user is fully logged off but not when a user session is still active and the screen has been locked. There is therefore potential to guess a user’s password on a stolen device

 

Management of Chrome OS devices via Google Admin console, and authentication of users to devices are intrinsically dependent on Google’s online services. Trust in Google’s online services is essential for enterprise deployments of Chrome OS devices. Users can authenticate against the account from unmanaged devices with risk of credential theft
External interface protection Only limited policy controls are available to restrict the external interfaces a user can enable, meaning that external interfaces such as Wi-Fi and Bluetooth may be accidentally or deliberately enabled by the end-user
Event collection for enterprise analysis There is no facility for collecting security logs remotely from a device, such as failed logins, for enterprise analysis is limited, meaning protective monitoring and forensic analysis following any compromise may be much harder than on other platforms

Overview

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

Security Principle Explanation
Assured data-in-transit protection Use the native IPsec VPN client.
Assured data-at-rest protection Use the native Chrome OS data encryption without additional configuration.
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 the first time they log in to their device, and after any subsequent password changes.
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.
Platform integrity and application sandboxing This requirement is met by the platform without additional configuration.
Application Whitelisting Authorised apps and extensions can be managed using a whitelist in Google Admin console.
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.
Security policy enforcement The security policy can be managed in Google Admin console to centrally enforce security settings, however some security related settings are configured only by the user, including those for Bluetooth.
External interface protection No technical controls exist to prevent users from enabling Wi-Fi and Bluetooth, or using certain USB devices. The use of USB storage devices can be disabled by policy.
Device Update Policy Operating system security updates can be configured via the Google Admin 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.
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.
Incident Response Cached user data can be wiped from the device after each sign-out (it is retained in the cloud). User accounts can be disabled or suspended from within the Google Admin 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.

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.

Recommended network architecture for deployments of Chrome OS devices

Preparation for deployment

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 recommended policies and settings section below.

Device 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

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 Kiosk Do not allow Public Session Kiosk
Device Settings → Single App Kiosk Do not all Single App Kiosk
Device Settings → Auto Update Allow auto-updates
Device Settings → Restrict Google Chrome version to at most No Restriction
Device Settings → Auto reboot after updates Allow auto-reboots
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
User Settings → Policy Refresh Rate 30
User Settings → Spell Check Service Disable the spell checking web service
User Settings → Google Translate Never offer translation
User Settings → Google Cloud Print Submission Disallow submission of documents to Google Cloud Print
User Settings → Google Cloud Print Proxy Disallow using Chrome as a proxy for Google Cloud Print

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)

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

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.

6. Enterprise considerations

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.

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.

Cloud integration

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. Features such as the ‘Spell Check Service’ and translation services rely on data being sent to a Google web service. Such features should not be used when handling OFFICIAL information as it could be processed by unaccredited systems.

It is possible for users to log in to enterprise Google accounts from unmanaged devices. Users should only log in to their enterprise Google account from enterprise managed devices to reduce the risk of credential theft.

Chrome web store

The configuration above prevents users from installing apps and extensions from the Chrome web store, but an organisation can host a private Chrome app collection to distribute in-house applications to their employees if required.

If the Chrome web store is enabled, authorised apps and extensions can be managed using an allow list in the Google Admin console.

Was this guidance helpful?

We need your feedback to improve this content.

Yes No