Guidance

EUD Security Guidance: Chrome OS 56

Created:  19 Apr 2017
Updated:  19 Apr 2017
Chromed engine
This guidance was developed following testing performed on a Chromebook device running Chrome OS 56.

It's important to remember this guidance is a series of recommendations to help you meet the 12 End User Device Security Principles. It should not be seen as a set of mandatory requirements requiring no further thought. 

Risk owners and administrators should agree a configuration which balances business requirements, usability and security. 

Risk owners' summary

The following architectural choices are recommended for Chrome OS:

  • All Chrome OS devices should be enrolled to a domain so they can be managed by your enterprise administrators.
  • All data should be routed over an appropriate VPN to ensure the confidentiality and integrity of traffic. This also allows the devices and data on them to be protected by your organisation’s protective monitoring solutions. 
  • Users should not be permitted to install arbitrary third-party applications on the device. The Google Admin console should be used to manage a catalogue of forced and available applications.

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

Neither the built-in VPN client nor third-party VPN extensions have been assured to Foundation Grade.

Users may disable the system VPN, which will compromise the in-transit protection provided by a VPN.

Assured data-at-rest protection

The built-in data encryption has not been independently assured to Foundation Grade.

Most user data is stored on Google servers. Files at rest on the device, including offline copies of user files, are encrypted and protected. Files synchronised or stored on Google servers are subject to Google's Enterprise Terms of Service and Data Processing Amendment.

Authentication

There is no method for automatically locking a device or user account after a number of failed logon attempts, although an online captcha is used to help prevent automated attacks.

Users are able to log in to Google services via any web browser, not just on managed devices. Third-party authentication providers may be able to limit access to certain IP ranges if required.

Event collection for enterprise analysis Some functionality for logging user events is available within Google admin and limited logs are available on the device, but in-depth security logs from the device and the functionality to push logs to a network collector are not available.

 

Administrators’ deployment guide

Overview

To meet the principles outlined in the End User Devices Security Framework, several recommendations are given in the table below. Recommendations on individual settings are provided in the ‘Recommended policies and settings’ section.

Security Principle Recommendation and Explanation
Assured data-in-transit protection Use the the built-in VPN (or other VPN available on the Chrome store). Users should be told not to disable the VPN.
Assured data-at-rest protection Chrome OS data protection is enabled by default. To also protect data in the cloud, administrators may additionally wish to configure the security settings for Google applications that are in use by their users.
Authentication

The user should be required to authenticate to the device in line with your organisation’s authentication policy.

Authenticating to the device unlocks a key which encrypts certificates and other credentials, allowing access the user’s local files and data stored using Google applications and services.

Two-factor authentication should be used to reduce the risk of an attacker getting access by utilising stolen passwords.

By default, users may access the Google application suite from any web browser, which may be located on a device that is less secure than the managed device (such as a home computer). Third-party authentication providers can mitigate this, or this risk can be managed procedurally.

Secure boot

Developer mode can be used to alter the operating system and subvert security settings; as such it should be disabled on enrolled devices.

If users are notified by the device that Secure Boot has failed, they should be instructed to switch the device off and return it for investigation.

Platform integrity and application sandboxing No configuration is required.
Application whitelisting

The Google Admin console can be used to manage which applications, themes and extensions are available to users, and which are installed by default. For some applications, settings can be forced to ensure that a specific configuration is applied.

Users cannot install third-party applications that are not available on the Chrome or Play Store. Additional applications, such as internal business applications, can be added in the Google Admin console.

Malicious code detection and prevention

A whitelist of applications should be used to ensure only trusted applications are installed on Chrome OS devices. In addition, any applications added from other sources, such as in-house business software, should undergo security testing before deployment.

Users are not able to execute arbitrary code, such as downloaded applications, on Chrome OS without enabling developer mode.

Security policy enforcement

Users cannot circumvent policies without wiping the device. Enabling the “Forced Re-enrolment” option ensures that even wiping the device does not prevent the application of policies.

Specific accounts can be given permission to enrol new devices if required.

External interface protection

A high level of granularity is available in restricting USB access. USB storage devices, including SD cards and MTP devices, can be disabled or made read-only to limit data import and export.

Network interfaces can be restricted as per the organisation’s security policy. Enforcing the use of a VPN is highly recommended as it would secure communications data even over an insecure network.

Device update policy Updates are provided by Google directly to ChromeOS devices; there is no way to enforce a minimum version.
Event collection for enterprise analysis Limited information regarding user and device state can be remotely retrieved from the device.
Incident response Devices can be disabled, wiped or de-provisioned remotely, however this requires the device to be connected to the internet. User accounts can also be suspended. These capabilities should be integrated into an incident response plan that is regularly tested.

 

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 following network diagram describes the recommended architecture for this platform.

Recommended network architecture for deployments of Chrome OS devices

Preparation for deployment

The steps below should be followed to prepare your organisation's infrastructure for hosting a deployment of these devices:

  • Procure, deploy and test a secure network architecture and VPN solution as recommended.
  • Configure the Google GSuite environment using the Google Admin console in accordance with the advice in this article.
  • Import or create user accounts.

Device provisioning steps

The steps below should be followed to provision each end user device onto your organisation’s network, preparing it for distribution to end users:

  • Enrol new devices using a dedicated enrolment account; there is no need to sign in to the device once the enrolment is complete.
  • Devices that have been signed in to previously need to be wiped before enrolment is possible (this is enforced by Chrome OS).
  • Provide the device and user credentials to the end user.

Recommended policies and settings

This section details important security policy settings which are recommended for the deployment of Chrome OS devices.

All guidance points given here are recommendations - they are not mandatory. Risk owners and administrators should agree a configuration which balances business requirements, expected security threats, usability and the security of the platform.

This section includes recommendations for all settings which have an impact on security, regardless of whether the default configuration within Google Admin is secure. If the recommended setting is the default, and the organisation has not overridden it, there is no need to explicitly set it.

The recommended settings should be applied to the root organisation (organisational unit), which will ensure that child organisations inherit all settings. Exceptions to the recommended settings can then be created by overriding the setting for a specific organisation.

User settings

Place business users in their own sub-organisation, not in the root organisation, and separate from administrators, as shown by the following list. Some example sub-organisations are included to indicate appropriate organisational structure.

  • Root organisation
    • Administrators
      • Global admins
      • IT support
    • Users
      • Finance
      • Human resources

This enables more granular controls and ensures that regular business users do not have the same rights as administrators. In addition, there are several security-related settings that cannot be changed within the root organisation, so must be changed in child-organisations. User groups who may require additional permissions, such as HR, may be in sub-groups which can override particular settings. Regular reviews of the rights afforded to users will assist in preventing “creep”, where normal users’ rights expand over time and ultimately incorporate now-defunct business cases.

Device management

The configuration of Android devices is not covered by this advice, although some of the recommended settings may impact them.

Network

Configure a VPN using either the built-in OpenVPN client or another VPN from the Chrome store. If using OpenVPN, their hardening guidance should be followed. VPNs can be disabled by the user, so appropriate training should be delivered to ensure that the VPN is left enabled. It is possible to force the use of a proxy that is only accessible via a VPN, which will prevent internet access from working (as the proxy will be unreachable) when the VPN is disabled. This approach is not flawless, as the user could disable the VPN and setup their own proxy, but it may be appropriate to reduce the ease with which users can access the internet with a disabled VPN.

Chrome management

User settings
Setting name Recommended value
Smart lock for Chrome Do not allow
Enrolment Permissions Create separate enrolment users and ensure they are the only ones able to enrol new devices. These accounts should not have access to any other data or applications.
Allow or Block All Apps and Extensions Block all apps and extensions except the ones I allow
Chrome Web Store Permissions Disable “Allow users to publish private apps that are restricted to your domain on Chrome Web Store.”
Android applications on Chrome Devices If this functionality is required and an Android application whitelist is in place, allow, otherwise do not allow
Account Management Disable users adding any accounts
Unknown Sources Do not allow install from unknown sources
Password Manager Always allow use of password manager
Lock Screen Force
Idle Settings

Set an appropriate idle time. Around 5 minutes is recommended.

Lock screen on sleep

Incognito Mode Allow
Online Revocation Checks Perform online OCSP/CRL checks
Safe Browsing Always enable
Malicious Sites Prevent user from proceeding anyway to malicious sites.
Proxy Settings Force the use of a specific proxy if a proxy is used. Otherwise, select never use a proxy. This can be set per-network if required.
SSL Record Splitting Enable
Data Compression Proxy Always disable data compression proxy
Plugin Finder Disable automatic search and installation of missing plugins
Plugin Authorization Ask for permission before running plugins that require authorization
Outdated Plugins Disallow outdated plugins. This reduces the chance an attacker can exploit a plugin using a known and patched vulnerability.
Developer Tools Never allow the use of built-in developer tools. Note that there are some legitimate use-cases for developer tools; they should be permitted on an individual basis.
Multiple Sign-in Access Block multiple sign-in access for administrators, who should be aware when they are switching between their normal user account and their privileged administrator account.
External Storage Devices Configure this in line with corporate policy on the use of external storage devices.
Verified Mode Require verified mode boot for Verified Access
Google Play Store settings
Setting name Recommended value
Enable Google Play Store for your domain The Google Play Store itself does not present additional security risk, however there is a much wider selection of applications available. It is prudent to whitelist Play Store applications in the same way as Chrome Store applications.
Device settings
Setting name Recommended value
Forced Re-enrolment Force device to re-enrol into this domain after wiping
Verified Access

Enable for Enterprise Extensions

Enable for Content Protection

Verified Mode Require verified mode boot for Verified Access
Guest Mode Disallow guest mode. This is discussed further in the “Other Considerations” section.
Sign-in Restriction

Restrict Sign-in to list of users. Enter all domains used by Google Admin with the wildcard as the username, such as:

*@domain.com

*@sales.domain.com

Wildcards should not be used in the domain portion of the entries to ensure only users from managed domains and not unmanaged subdomains or third-party domains are allowed to sign in.

Auto Update Settings

Allow auto-updates

No restriction on Google Chrome version

Release Channel Stable Channel
Kiosk Settings Do not allow Public Session Kiosk
Inactive Device Notifications

Enable inactive device notifications

Set inactive range, notification cadence and email addresses as appropriate for the organisation. This recommendation aims to reduce the number of unused but available devices that have access to business data.

 

Security

Basic settings

Setting name Recommended value
Less secure apps Disable access to less secure apps for all users. This can be modified if a business case is available for allowing a less secure app.
API Access Enable API access
Single Sign On (SSO) When selecting a non-Google SSO provider, ensure that their security guidance is followed
Authentication (under advanced settings) Remove any unnecessary entries from this list, to reduce the number of applications able to directly access the organisation’s data.

 

Other considerations

Reliance on Google infrastructure and services

Almost every feature of Chrome OS relies upon Google services and infrastructure. User data is automatically saved on Google servers, and features like translation and spell checking require sending text to Google servers. Organisations should be aware of which types of data are stored and processed on Google's cloud services, and you can use the NCSC Cloud Security Guidance to help understand whether this is appropriate for the information in question.

Verified boot

Chrome OS includes a robust secure boot process that prevents unauthorised tamping with devices, such as compromising hardware configuration or security components. It will alert the user if it suspects an attack has taken place, and attempt to roll back to a previous known-good version, but does not have functionality to automatically report this. It is therefore vital that users are given training to recognise the alert, cease using the device, and alert administrators promptly.

Guest mode

Chrome OS has a “guest mode” (also called a “public session”), which allows a user to log into a Chromebook without having an account. This account is segregated from other accounts and cannot access business data, other user’s information, or make modifications to the OS settings that would impact other users. At the end of the session, all data and settings are wiped.

As it is likely that some users will want to allow others occasional access to their work-provisioned device, you may wish to consider enabling Guest Mode, where access to sensitive information is not available to those guests. If you decide to enable Guest Mode, there are settings in the administrative console which can be used to lock down guests' abilities.

Was this guidance helpful?

We need your feedback to improve this content.

Yes No