How to mitigate ransomware risks for Google Workspace documents

About this document

Generic Security Principles

Google Drive fles protection Google native fles Chromebooks encryption What if it happens?

Other considerations

About this document

This document is intended to help customers mitigating ransomware and crypto-locking risks for Google Workspace documents.

Generic Security Principles

Strong factor of authentication: Enforce 2SV with Security Key Context aware access: Leverage Context-Aware Access to secure access Identify suspicious links so that end-users are prevented from clicking on them: Safe Browsing integrated within Google Workspace, Safe Browsing in Chrome Enforce security on mobile devices: Google Workspace Advanced MDM Enforce security on mobile Chromebooks : Chrome Enterprise policies and setings Enforce security on Windows devices: 3P solutions or manage Windows 10 devices through Google Workspace Audit logs: Review user and administrator activity Aler center: Leverage alers to identify suspicious activities Data Loss Prevention: Scan and protect Drive fles using DLP rules

1 The list above contains only some security principles. A more comprehensive Security Checklist is also available.

Google Drive fles protection

The same rigorous anti-virus protections that keep Gmail safe also apply to Google Drive. Most Drive fles undergo a real-time scan prior to any download or public sharing. Drive stores fles in a non-executable format, which prevents ransomware from propagating within Drive.

With Drive File Stream, the amount of company data stored on users’ hard drives is minimized, so the surace of atack on the fle system is restricted. Note that Drive File Stream does not scan fles, so end user machines may require anti-virus sofware if they are syncing fles created by other users.

A third-pary rogue app with High-Risk Drive API access could potentially compromise fles in Drive.

As a best practice, it is recommended to restrict Drive Google Service access by default and trust only specifc apps that are needed for business. For Google Drive, it is possible to specifcally restrict access to high-risk scopes (for example, deleting fles in Drive).

Another available option for admins is whether to trust internally owned apps or not. Internally owned apps include Google Apps Script projects created by users within the organization and apps associated with the organization in the Google Cloud Platorm Console.

The Google Workspace Marketplace Security Assessment Program was also recently released. Developers can submit their app to a third-pary security frm that perorms a security assessment of their Marketplace app. Apps that pass the security assessment display a security badge in their Marketplace listing. While the security assessment badge is not a guarantee against every possible threat or harm, it shows that an app has successfully passed a security review based on key security criteria.

Google native fles Google native fles are not actually stored in the fle system, even if a sync tool is in use, like Google Drive File Stream.

What it’s visible in the fle system is a link to the fle stored in the cloud. The actual content of the fle never reaches the local device unless the fle is pinned for ofine use.

2 In case a fle is available ofine, the actual data is stored in a cache in the local Chrome browser and only the authenticated Google user can access their ofine data in Chrome.

Chromebooks encryption

Chrome OS system paritions are read-only. Leveraging Verifed Boot, when the OS stars, it ensures that hashes of each of these paritions correspond to the ones that Google provides (with hardware-backed security). If there is any alteration of the system paritions, the device will not boot. The device will be stuck with a screen asking to use a recovery key. If the user plugs a recovery key then the device is wiped and "reimaged" and, afer that, it can boot again.

Regarding user data, all of the data belonging to a user is encrypted within its own profle with hardware-backed key storage and each user can only see his data (it is not possible for an application to access other user data even in read only). The amount of data synced from Google Workspace to the user context is done by the OS (and users cannot change it) and it ensures a limited data footprint on the device.

Finally, execution context within a Chrome OS environment is highly regulated making it extremely difcult for anything other than an extension to act on a Chrome OS device as a ransomware.

Regarding extensions, Google highly recommends proceeding only on an allowlist basis or at least to limit them based on permission setings, providing all the tools required for making Chrome OS a very ransomware inhospitable environment.

If Crostini (Linux VM hosted in Chromebook) is enabled and if some Drive folders are shared with Crostini, since the user is “root” of the Linux VM, an atacker able to execute code on the Linux VM will also be able to alter fle directly. In this case, any Google native fle would not sync “as is” back to the drive cloud: the native fle will remain and a second fle would be created (without extension) integrating the changes from the atacker. If the atacker changes a non Google native fle then this one will be synced to the cloud. It is strongly recommended not to allow Crostini on chromebook unless there is a valid business reason.

What if it happens?

In the event where an atacker forcibly encrypts fles that are synced via the Google Drive endpoint sync client or DFS, there is a simple approach to regain access to fles.

3 Prerequisite: ensure the machine syncing content to Drive has been cleaned by the Security team.

The frst approach is to check for original fles in the Drive trash, because ransomware ofen surreptitiously deletes original fles and replaces them with encrypted versions. If locating the original fles in the Drive trash is successful, simply delete the encrypted fles and restore these originals.

For bulk recovery, use the following procedure with Drive API

● List trashed fles with query ‘trashed = true’ (Files.list) ● Change ‘trashed’ propery to un-trash the fle (Files.update)

The second approach is suitable if ransomware happens to encrypt fles in place. To restore a previous clean version of a fle that has been encrypted in place by ransomware, follow instructions located in our suppor aricle: Save and restore recent fle versions.

For bulk recovery, use Drive API to list the fles and the versions, and then delete the afected revision. This procedure will promote the newest revision to the current version. The detailed procedure is as follows:

● List fles (Files.list) ● List a fle’s revisions (Revisions.list) ● Permanently delete a revision (Revisions.delete)

In addition, most Drive fles undergo a real-time scan prior to any download or public sharing. Drive stores fles in non-executable formats, which prevent ransomware from propagating within Drive.

If a Drive fle is permanently deleted it can also be recovered by the Administrator within 25 days.

Other considerations

With the Security Center, it is possible to understand the potential source of the eventual atack.

Google Vault gives the possibility to apply retention policies to data.

4 Finally, Google's new machine learning techniques presented at RSA 2020 and the Gmail’s Security Sandbox launched in 2019 with the goal of helping detect and prevent malware atacks.

If a copy of the malware or hash on VirusTotal is available, that would be very useful for checking the state of the ar for detection.

5