This guidance was developed following testing performed on a Chromebook device running Chrome OS 65, managed using the Google Admin Console.
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 or another third-party solution 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 applications have been assured to Foundation Grade.
Users may disable the system VPN, which will compromise the in-transit protection provided by a VPN. Some third party VPN applications support the PRIME profile for IPsec but do not support the always on functionality that is supported by the built-in VPN client. This increases the risk of data leaking outside the corporate network. |
| Assured data-at-rest protection | The built-in data at rest 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. |
| Platform integrity and application sandboxing | Chrome OS now supports running Android applications, and files written by Android applications that use WRITE_EXTERNAL_STORAGE permission are now accessible device-wide. Files stored in this way are world-readable so other applications (including native Chrome applications) are able to read these files. The application whitelisting policy applies here and can be used to only allow trusted applications to be installed and thus access the shared media files. |
Administrators’ deployment guide
Overview
To meet the principles outlined in the End User Devices Security Framework, several recommendations are given in the table below. Advice on individual settings is provided in the ‘Recommended policies and settings’ section.
| Security Principle | Recommendation and Explanation |
| Assured data-in-transit protection | Use the built-in VPN (or other VPN available on the Chrome or Google Play store). Users should be told not to disable the VPN.
If a third party VPN client that supports the PRIME IPSec profile and has an Always On setting becomes available, this should be used. Otherwise, use the built-in VPN client and enable Always On. |
| 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 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. Multi-factor authentication should be used to reduce the risk of an attacker gaining access through the use of stolen passwords. By default, users can access the Google application suite from any web browser. This may be located on a device that is less secure than the managed device (such as a home computer). Third-party authentication providers can be used to 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 (or other third-party solution) 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 which are not available on the Chrome or Play Stores. Additional applications, such as internal business applications, can be added in the administrative console or via the Google Managed Play Store. |
| 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 enforcement of policies.
Specific accounts can be given permission to enroll 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. |
| Device update policy | OS updates are provided by Google directly to Chrome OS devices. The MinimumRequiredChromeVersion policy can be used to enforce a minimum Chrome OS version, meaning users are not allowed to sign in before OS is updated.
Chrome OS device policies are unable to enforce the automatic update of applications. Managed Google Play can be configured to automatically update applications. However, users can turn this option off. A partial mitigation is to enable automatic updates in Managed Google Play and educate users to not disable it. |
| 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.
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 environment using the Google Admin console (or other third-party solution) in accordance with the advice in this guidance.
- 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:
- Enroll new devices using a dedicated enrollment account. There is no need to sign into the device once the enrolment is complete.
- Devices that have been signed into previously need to be wiped before enrolment is possible (this is enforced by Chrome OS).
- Devices should be updated to the latest stable ChromeOS version and any TPM updates applied.
- Provide the device and user credentials to the end user.
Recommended policies and settings
This section details important security policy settings which we recommend for deployments 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 your 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
- Administrators
This structure 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 other VPN available on the Chrome or Google Play 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 if you wish 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 |
| Access to Android applications | If this functionality is required and an Android application whitelist is in place, allow. Otherwise, do not allow |
| 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 but these 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. |
Android application settings
| Setting name | Recommended value |
| Enable Google Play Store for your domain | The Google Play Store itself does not present additional security risk, however it does make 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:
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. |
| Device Reporting | Enable all |
| Anonymous Metric Reporting | Never send metrics to Google |
| Bluetooth | Disable Bluetooth unless required |
| TPM Firmware Update | Allow users to perform TPM firmware updates. Users should follow the guidance on how to update their TPM and ensure that any local documents are backed up prior to updating their device. |
Security
Basic settings
These are our recommended settings for configuring G-Suite, if you are using G-Suite to manage your Chrome OS devices.
| 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 your organisation’s data. |
Other considerations
Reliance on Google infrastructure and services
Almost every feature of Chrome OS relies upon Google services and infrastructure. When using Google services, it is important to remember that user data is automatically saved by the services to Google servers, and features like translation and spell checking require sending text to Google servers.
You should be aware of which types of data are stored and processed on Google’s cloud services. 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 tampering 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 notify 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. If you decide to enable Guest Mode, there are settings in the administrative console which can be used to lock down guests’ abilities.
TPM firmware updates
ChromeOS utilises TPMs to store sensitive key material, including disk encryption keys. Over time, firmware updates may become available for the TPM.
Updating the TPM firmware requires a hardware reset of the TPM chip, which means that all data held by the TPM will be discarded and any encryption keys lost. This means that all user data on the device will also be lost. Because of this, any available TPM firmware updates should be installed at the device provisioning stage. Any future updates may be installed by the end-user by following the guidance on how to update their TPM, ensuring that any local documents are backed up prior to the update.
Source: NCSC
