GCP – 5 ways Google Cloud can help you minimize credential theft risk

Threat actors who target cloud environments are increasingly focusing on exploiting compromised cloud identities. A compromise of human or non-human identities can lead to increased risks, including cloud resource abuse and sensitive data exfiltration. These risks are exacerbated by the sheer number of identities in most organizations; as they grow, the attack surface they represent also grows. 

As described in the latest Google Cloud Threat Horizons Report, organizations should prioritize measures that can strengthen identity protection. 

“We recommend that organizations incorporate automation and awareness strategies such as strong password policies, mandatory multi-factor authentication, regular reviews of user access and cloud storage bucket security, leaked credential monitoring on the dark web, and account lockout mechanisms,” said Iain Mulholland, senior director, Security Engineering, in last week’s Cloud CISO Perspectives newsletter.

Today, we are detailing key risk mitigations from Google Cloud security experts that you can quickly act on. Every organization should evaluate these mitigations as part of their efforts to protect their cloud deployments.

Google Cloud’s built-in protections 

Google Cloud provides always-on account protection measures that help mitigate credential theft. Many of these protections are based on heuristics that detect likely credential theft and terminate an attacker’s session. Others limit the use of suspected stolen cookies to minutes, instead of hours. 

Google Cloud requires users to reauthenticate to confirm the validity of their credentials before allowing many sensitive actions in the Cloud Console. This reauthentication can happen deterministically or based on a risk score. 

Google Cloud sets default Organization Policies on newly created organizations to guard against common risks of service credential theft and sharing of resources. 

However, as attacker tactics evolve, it’s important to have additional layers of defense in place spanning multi-factor authentication (MFA), protecting sessions, protecting service credentials, identity and access controls, and security monitoring.

Google Cloud customers are encouraged to adopt the following measures to help increase protection against credential theft:

1. Multi-factor authentication (MFA): As part of our shared fate approach to help customers, we recently described our plans to make MFA mandatory for all Google Cloud users this year. If you have not enabled MFA yet, you can take these steps in advance of mandatory enforcement:

1. Enable MFA on your primary Identity Provider (IdP). For Google Cloud customers who use Google Cloud Identity as their primary IdP, follow these instructions.

2. Add an MFA instrument to Google Cloud Identity accounts for re-authentication. If Google Cloud Identity is not your primary IdP, this provides an independent layer of verification prior to allowing sensitive actions. Follow these instructions.

3. Configure your IdP to always challenge (ideally with MFA) when accessing Google. When Google Cloud customers use Cloud Identity with their own IdP through SAML or OIDC, Cloud Identity queries the IdP for an attestation when the session expires or when Google Cloud requires re-authentication. In the default configuration, IdPs silently approve all these attestations to minimize user friction. However, most IdPs can be configured to always require re-entering credentials, and even to always require MFA whenever Google Cloud requests an attestation. This configuration can be set up to only apply to the app representing Google Cloud, and not for all apps that the IdP federates for a smoother user and administrative experience.

1. Limiting session length can reduce the usefulness of stolen cookies. The default session length is 16 hours, and is user-configurable. Here are instructions for setting session length, and you can read more on session length management.

2. Limiting IPs allowed to access Cloud Console and APIs with Context-Aware Access (CAA) can make stolen credentials useless (unless the attacker has access to allowlisted IPs, such as the corporate network or VPN IPs.)

3. Certificate-based access can be used to require mTLS certificates to access Cloud Console and Google Cloud APIs. mTLS provides strong protection against cookie theft, requiring users to present an mTLS certificate in addition to existing credentials such as cookies. mTLS certificates are typically stored in the Trusted Platform Module (TPM) of the user’s device, making them extremely difficult for an attacker to steal. Many enterprises already deploy mTLS certificates to their users, and Google Cloud allows customers to either reuse their existing mTLS certificates, or use new ones just for Google Cloud.

4. Contextual-access restrictions can be configured with Access Context Manager, which allows Google Cloud organization administrators to define fine-grained, attribute based access control for projects and resources. Access levels can be configured to require additional device and user attributes to be met in order for a resource request to be successful. For example, you can require that a corporate-managed be used to access and configure resources.

1. Disable creation of service account keys: This Organization Policy setting prevents users from creating persistent keys for service accounts. Instead of allowing unqualified use of service account keys, choose the right authentication method for your use case, and allow exceptions for service account keys only for scenarios that cannot use more secure alternatives.

2. Disable leaked service account keys automatically: Google Cloud regularly scans public repositories (including Github and Gitlab) for leaked service account keys. If Google Cloud detects an exposed key, it will automatically disable the key. It also creates a Cloud Audit Logs event and sends a notification about the exposed key to project owners and security contacts. We strongly recommend not modifying the DISABLE_KEY option (which is on by default).

3. Binding service account keys to trusted networks: Context Aware Access for service accounts enables customers to bind service accounts to an IP-range or specific VPC networks, and enforce that service accounts can access Google Cloud services and APIs only from these trusted networks. Customers can request early access to this control using this form. 

1. Google Cloud Identity and Access Management (IAM) lets you grant granular access to specific Google Cloud resources and can help prevent access to other resources. Permissions are grouped into roles, and roles are granted to authenticated principals. You should regularly review and right-size permissions using tools such as IAM Recommender. The Google Cloud Architecture Framework provides additional best practices for managing identity and access.

2. VPC Service Controls enable a powerful, context-aware approach to control access for your cloud resources. You can create granular access control policies based on attributes such as user identity and IP address. These policies ensure specific security controls are in place before granting access to cloud resources from untrusted networks. By allowing access only from authorized networks, VPC Service Controls helps protect against the risk of data exfiltration presented by clients using stolen OAuth or service account credentials.

3. Principal access boundaries can precisely define the resources that a principal is eligible to access. If a policy makes a principal ineligible to access a resource, then their access to that resource is limited regardless of the roles they’ve been granted.

4. Restrict identities by domain using domain-restricted sharing to limit role grants to users belonging to a specific domain or organization. When domain restricted sharing is active, only principals that belong to allowed domains or organizations can be granted IAM roles in your Google Cloud organization.

1. Security Command Center (SCC) is Google Cloud’s built-in security and risk management platform. It provides comprehensive security posture management, threat detection, and compliance monitoring.

   With SCC’s Cloud Infrastructure Entitlement Management (CIEM) capabilities, you can manage which identities have access to which resources in your deployments, mitigate potential vulnerabilities that result from misconfigurations, and enforce the principle of least privilege. The Sensitive Actions Service within SCC automatically detects and alerts on potentially damaging actions occurring across your cloud organization, folders, and projects. SCC’s Virtual Red Teaming capability continuously detects if high value resources are exposed and surfaces the identities and access paths that could lead to compromise.

Next steps

Maintaining a strong security posture requires ongoing evaluation of the risks your organization faces, and the controls you have in place to address them. These recommendations can help you strengthen your cloud estate against the growing risks associated with credential compromise.

You can learn more about protecting your Google Cloud deployments in our security Best Practices Center.