Mitigating Data Exfiltration Risks in GCP using VPC Service Controls ( Part-1 )

This is the first post in a multi-part series on securing your sensitive data assets in Google Cloud Platform(GCP) using a GCP service: VPC Service Controls. In this post, we cover the basics of VPC Service Controls and how we can use it to mitigate data exfiltration risks in the Google Cloud Platform. In the next part, we will deep dive into advanced concepts and go over data exfiltration use cases to illustrate how we can use this service to avoid the data breach risks.

Introduction

VPC Service Controls enables security administrators to establish security perimeter (referred to “the perimeter” henceforth) around sensitive data stored in Google Cloud Platform resources such as Google Cloud Storage (GCS), BigTable instances, and BigQuery datasets. When we enforce the perimeter, resources can freely exchange data within the perimeter boundary as long as IAM policies and VPC Firewall policies allow it. However, any access from outside is blocked by default.

On a high level, We can configure the perimeter using the following steps:

1. Identify the GCP projects you want to protect.
2. Identify the GCP services you wish to protect.
3. If you’re going to allow legitimate traffic from outside the perimeter to access a protected service, create access levels.
4. Configure the perimeter by including projects, GCP Services, and access levels you identified above.

Lastly, you can configure the perimeter using a method of your preference — console, gcloud or API.

That is it! Now we go over the threat model to highlight the risks that you can mitigate using this service.

Threat Model

VPC Service Controls help mitigate data exfiltration risks for the following attack vectors.

Threat Model and Risk mitigation using VPC Service Controls

1. Data exfiltration from GCS buckets inadvertently exposed to the public

Let us imagine for a moment that IAM policies are set incorrectly on a protected service (e.g., GCS or BigQuery) due to automation or human error; these assets become publicly accessible, potentially leading to data exposure. VPC Service Controls perimeter, if configured, will block any ingress access to such resources, even if IAM policies allow it.

2. Bulk Data exfiltration using service to service copy

As per the latest research findings, privileged users pose the most significant security risk to organizations. Most organizations are concerned about the stealing of data in bulk, in particular. Malicious users with privileged broad-based IAM access can copy the entire data from e.g., GCS bucket to a bucket in a personal project. Detection capabilities based on logging and monitoring may be able to detect such actions; however, they may not be sufficient to stop the data movement promptly. VPC Service Controls will block the flow of data across the perimeter boundary.

3. Data exfiltration using VM to service copy

VPC Service Controls will block any operations in which a malicious insider or compromised/untrusted code running on a VM attempts to copy data from, e.g., GCS bucket to a VM and subsequently to a GCS bucket in a project under adversary’s control.

4. Access to sensitive data in GCP services using stolen credentials

VPC Service Controls will block any operations in which an attacker tries to access sensitive data in a protected service from the Internet using stolen credentials ( e.g., OAuth or service account credentials).

5. Block access to Google Public APIs

VPC Service Controls will block any connections in which an application/service running inside a perimeter tries to send data to Google public APIs (e.g., Gmail, Google Drive, etc.).

Not every threat can be mitigated using VPC Service Controls

In general, VPC Service Controls will only apply when the destination of the communication path is a GCP service supported by VPC Service Controls. A few examples are listed below. In such cases, other security controls such as IAM, firewall rules, WAF, etc. must be implemented to mitigate these threats.

1. Attacks on your internet-facing web applications and services

Your internet-facing applications and services running on GCE instances and GKE clusters are exposed to threats, such as unauthorized access, application vulnerabilities such as XSS, SQLi, and CSRF. These threats can be mitigated by enforcing various security controls using GCP services such as Identity-Aware proxy, Apigee, cloud armor, etc.

2. Data Exfiltration via VM to an external malicious endpoint

VPC Service Control will not mitigate risks in which a malicious insider copies data from a GCS bucket to a VM within the perimeter and then sends it to a malicious external endpoint hosted outside the perimeter. To mitigate such threats, VPC Firewalls need to be used to ensure that egress traffic is allowed only to whitelisted hosts/IP ranges and ports.

3. Data Exfiltration via VM-VM calls and unsupported APIs

VPC Service Control will also not mitigate risks in which a malicious insider copies data from a GCS bucket to VM and then sends it to a VM or an unsupported API/service in an unauthorized project. Again VPC Firewall rules can be leveraged to block this type of traffic.

Now that we have a reasonably good understanding of how we can use VPC Service Controls to secure sensitive data assets, in the next section, we go into some of the best practices and considerations to keep in mind while using VPC service controls.

VPC Service Controls Best Practices

The following sections provide some of the best practices on enabling VPC Service Controls.

1. Do not enable unsupported GCP services in the perimeter.

VPC Service Controls do not support all GCP services. Refer to this list for more details. If you need to use a service not supported by VPC Service Controls, enable this service in a project outside the perimeter.

2. Use service accounts to allow traffic from external GCP projects into the perimeter

If services hosted in GCP projects outside the perimeter need to communicate with GCP service inside the perimeter, use the following steps:

• Create a service account and assign it the least permissions required to access the GCP service inside the perimeter
• Configure the service to use the service account.
• Whitelist the service account in the access level associated with the perimeter configuration.

3. Configure Private Google Access to allow traffic from On-premise hosts into the perimeter

If there is a need to allow traffic from the on-premise network over the dedicated/partner Interconnect/VPN onto the perimeter, there are two cases to consider here:

• If on-premise hosts access only those Google APIs and services supported by VPC Service Controls, Configure Private google access for on-premise hosts using VIP — restricted.googleapis.com(199.36.153.4/30). The diagram at this link illustrates this connectivity.
• When on-premise hosts need access to GCP Service not supported by VPC Service Controls, use private.googleapis.com(199.36.153.8/30)

4. Use Authorized IP range, or device attributes to allow access from the Internet into the security perimeter

If end-users need to access protected GCP services from the Internet, whitelisting their userids in access levels is not recommended. Granting access into the perimeter based on identity is often useful in conjunction with service accounts. Additionally, as of writing this post, only a maximum of only 100 members can be added per access level. See quotas for the latest details. So even though the protected service (e.g., GCS) would indeed enforce IAM policies based on end-user identity, consider using one of the following approaches to authenticate end-users to into the perimeter while accessing a protected service:

1. If users always connect from a trusted network (corp network over VPN connection), whitelist the trusted IP range in the access levels
2. Use device attributes such as “corp owned device” in defining access levels. Enforcing access levels based on device attributes would require client devices to be configured with Endpoint Verification. Please refer to the device attributes section in Access levels for more details.

5. Configure the perimeter in dry-run mode to being with

Configuring the perimeter provides two options: dry run mode and enforced mode. At the start, the perimeter should not be set in the enforced-mode to avoid blocking any legitimate access:

1. Create a service perimeter in dry-run mode in a non-production environment, to begin with.
2. Test your applications and controls before configuring the perimeter in a higher environment.
3. Analyze dry-run logs for violations. Include any service accounts, IP range, device attributes, etc. to access level as needed. Please note that dry run violations occur in projects that are part of the perimeter.
4. Once dry run analysis shows no violations, configure the perimeter in the enforced mode.

6. Review known limitations before including GCP services in the perimeter

There are known limitations with certain Google Cloud services, products, and interfaces when using VPC Service Controls. Refer to this link for details.

7. Use IAM and VPC Firewall rules to restrict access within the perimeter

VPC Service Controls allow free communication between virtual machines (VMs)/ GKE nodes and GCP services within the perimeter as long as IAM policies and VPC firewall policies allow it. To restrict communication within the perimeter, use IAM policies, VPC Firewall rules, and other security controls for defense in depth.

8. Review the list of users who have permissions to configure the perimeter

Review the list of identities that have IAM permissions to modify the perimeter.

9. Set up Container Registry for GKE private clusters

This step applies if you are using GKE private cluster and Container Registry. It requires configuring your DNS server so that the requests to Container Registry addresses resolve to restricted.googleapis.com. If the restricted VIP is not used, data can be exfiltrated from a supported service to an unsupported one. See this link for more information.

10. Leverage conditional logic in creating access levels

Create access Levels using a combination (AND / OR) of the following attributes -

1. IP Range — this attribute can be used for allowing access from a specified range of IP addresses (for example, those within a corporate network).
2. Service Account — This attribute can be used for allowing access from specified service accounts or user accounts.
3. Device Attributes — The device attributes that can be used are -

a. Corp Owned device.
b. Screen lock is enabled.
c. Storage encryption is enabled.
d. Operating Systems of specific kinds and versions.

Any or combination of the above attributes can be used to create an access level. As an example, if you want to ensure that users are allowed either from a trusted IP range or from a corporate managed device, create an access level using authorized IP range and device attribute (“Corp Owned device.” ) using OR condition.

11. While using device attributes, use the “Corp Owned device” for more robust security.

Using “Corp Owned device” provides you an assurance that traffic is originating from a corporate-managed device. For successful authentication of client requests to GCP resources configured with this device attribute, endpoint verification needs to be enabled on the client devices. There are two options to allow endpoint verifications:

a. Endpoint Verification for Chromebook users

To collect the device attributes from Chromebook devices, enrolling must be completed. Automatic enrollment occurs when users log in for the first time to the device. Once enrolled, no other action is needed, and device information is sent on every request to GCP. This link provides details on enrolling Chromebooks.

b. Endpoint Verification for Non-Chromebook users

Device attributes for Non-Chromebook users can be collected using the Endpoint Verification Chrome Browser extension. The following steps are necessary to use this option.

• Turn on Endpoint Verification in the admin console.
• Installing the Endpoint Verification extension on authorized devices.

This article provides details on turning on the endpoint verification and the three options to install the extension.

Putting it together

The following diagram illustrates how VPC security controls can be used in conjunction with other security controls for defense-in-depth.

Using VPC Service Controls in conjunction with other security controls in GCP

Stay Tuned

In the next post, we will deep dive into advanced features of VPC Service Controls, and walk through some more data exfiltration use cases to demonstrate how VPC Service Controls can be used to mitigate the risks.

Further Readings

1. Overview of VPC Service Controls
2. Service perimeter configuration
3. VPC Service Controls — Supported products and limitations
4. Private Google Access with VPC Service Controls

Credits

Many thanks to Samrat Ray and Mike Altarace for providing their expertise on this topic.

Disclaimer

Mukesh Khattar is a Security Consultant at Google, Inc. (Google Cloud). The opinions stated here are my own, not those of Google, Inc.