ControlMap follows CIS benchmarks to scan GCP environments and automatically report deviations. WE HIGHLY recommend that you familiarize yourself with the CIS benchmarks for GCP for AUDIT and REMEDIATION steps.

ControlMap currently scans for following benchmarks. The remediation steps are given along with each benchmark . You must refer to CIS Benchmarks for a more detailed understanding of the issues and remediation steps.

1.4  (GCP-CMAP-1-4) Ensure that there are only GCP-managed service account keys for  each service account

Description: 

User managed service accounts should not have user-managed keys. 

Rationale: 

Anyone who has access to the keys will be able to access resources through the service  account. GCP-managed keys are used by Cloud Platform services such as App Engine and  Compute Engine. These keys cannot be downloaded. Google will keep the keys and  automatically rotate them on an approximately weekly basis. User-managed keys are  created, downloadable, and managed by users. They expire 10 years from creation. 

For user-managed keys, the user has to take ownership of key management activities  which include: 

∙ Key storage 

∙ Key distribution 

∙ Key revocation 

∙ Key rotation 

∙ Protecting the keys from unauthorized users 

∙ Key recovery 

Even with key owner precautions, keys can be easily leaked by common development  malpractices like checking keys into the source code or leaving them in the Downloads  directory, or accidentally leaving them on support blogs/channels. 

It is recommended to prevent user-managed service account keys. 

1.5 (GCP-CMAP-1-5) Ensure that Service Account has no Admin privileges (Automated) Profile 

Description: 

A service account is a special Google account that belongs to an application or a VM, instead  of to an individual end-user. The application uses the service account to call the service's  Google API so that users aren't directly involved. It's recommended not to use admin access  for ServiceAccount. 

Rationale: 

Service accounts represent service-level security of the Resources (application or a VM)  which can be determined by the roles assigned to it. Enrolling ServiceAccount with Admin  rights gives full access to an assigned application or a VM. A ServiceAccount Access holder  can perform critical actions like delete, update change settings, etc. without user  intervention. For this reason, it's recommended that service accounts not have Admin  rights. 

1.6 (GCP-CMAP-1-5) Ensure that IAM users are not assigned the Service Account User or  Service Account Token Creator roles at project level 

Description: 

It is recommended to assign the Service Account User (iam.serviceAccountUser) and  Service Account Token Creator (iam.serviceAccountTokenCreator) roles to a user for  a specific service account rather than assigning the role to a user at project level. 

Rationale: 

A service account is a special Google account that belongs to an application or a virtual  machine (VM), instead of to an individual end-user. Application/VM-Instance uses the  service account to call the service's Google API so that users aren't directly involved. In  

addition to being an identity, a service account is a resource that has IAM policies attached  to it. These policies determine who can use the service account. 

Users with IAM roles to update the App Engine and Compute Engine instances (such as App  Engine Deployer or Compute Instance Admin) can effectively run code as the service  accounts used to run these instances, and indirectly gain access to all the resources for  which the service accounts have access. Similarly, SSH access to a Compute Engine instance  may also provide the ability to execute code as that instance/Service account. Based on business needs, there could be multiple user-managed service accounts  configured for a project. Granting the iam.serviceAccountUser or  iam.serviceAserviceAccountTokenCreatorccountUser roles to a user for a project gives  the user access to all service accounts in the project, including service accounts that may be  created in the future. This can result in elevation of privileges by using service accounts  and corresponding Compute Engine instances.  In order to implement least privileges best practices, IAM users should not be assigned  the Service Account User or Service Account Token Creator roles at the project level.  Instead, these roles should be assigned to a user for a specific service account, giving that  user access to the service account. The Service Account User allows a user to bind a  service account to a long-running job service, whereas the Service Account Token  Creator role allows a user to directly impersonate (or assert) the identity of a service  account.

1.7  (GCP-CMAP-1-7) Ensure user-managed/external keys for service accounts are rotated  every 90 days or less 

Description:

Service Account keys consist of a key ID (Private_key_Id) and Private key, which are used to  sign programmatic requests users make to Google cloud services accessible to that  particular service account. It is recommended that all Service Account keys are regularly  rotated. 

Rationale: 

Rotating Service Account keys will reduce the window of opportunity for an access key that  is associated with a compromised or terminated account to be used. Service Account keys  should be rotated to ensure that data cannot be accessed with an old key that might have  been lost, cracked, or stolen.  Each service account is associated with a key pair managed by Google Cloud Platform  (GCP). It is used for service-to-service authentication within GCP. Google rotates the keys  daily.  GCP provides the option to create one or more user-managed (also called external key  pairs) key pairs for use from outside GCP (for example, for use with Application Default  Credentials). When a new key pair is created, the user is required to download the private  key (which is not retained by Google). With external keys, users are responsible for keeping  the private key secure and other management operations such as key rotation. External  keys can be managed by the IAM API, gcloud command-line tool, or the Service Accounts  page in the Google Cloud Platform Console. GCP facilitates up to 10 external service account  keys per service account to facilitate key rotation. 

1.8  (GCP-CMAP-1-8) Ensure that Separation of duties is enforced while assigning service  account related roles to users  

Description: 

It is recommended that the principle of 'Separation of Duties' is enforced while assigning  service-account related roles to users. 

Rationale: 

The built-in/predefined IAM role Service Account admin allows the user/identity to  create, delete, and manage service account(s). The built-in/predefined IAM role Service  Account User allows the user/identity (with adequate privileges on Compute and App  Engine) to assign service account(s) to Apps/Compute Instances.  Separation of duties is the concept of ensuring that one individual does not have all  necessary permissions to be able to complete a malicious action. In Cloud IAM - service  accounts, this could be an action such as using a service account to access resources that  user should not normally have access to.  Separation of duties is a business control typically used in larger organizations, meant to  help avoid security or privacy incidents and errors. It is considered best practice. No user should have Service Account Admin and Service Account Userroles assigned at  the same time. 

1.9  (GCP-CMAP-1-9) Ensure that Cloud KMS cryptokeys are not anonymously or publicly  accessible 

Description: 

It is recommended that the IAM policy on Cloud KMS cryptokeys should restrict  anonymous and/or public access. 

Rationale: 

Granting permissions to allUsers or allAuthenticatedUsers allows anyone to access the  dataset. Such access might not be desirable if sensitive data is stored at the location. In this  case, ensure that anonymous and/or public access to a Cloud KMS cryptokey is not  allowed. 

1.10 (GCP-CMAP-1-10) Ensure KMS encryption keys are rotated within a period of 90 days  (Automated) 

Description: 

Google Cloud Key Management Service stores cryptographic keys in a hierarchical  structure designed for useful and elegant access control management. 

The format for the rotation schedule depends on the client library that is used. For the  gcloud command-line tool, the next rotation time must be in ISO or RFC3339 format, and the  rotation period must be in the form INTEGER[UNIT], where units can be one of seconds (s),  minutes (m), hours (h) or days (d). 

Rationale: 

Set a key rotation period and starting time. A key can be created with a specified rotation  period, which is the time between when new key versions are generated automatically. A  key can also be created with a specified next rotation time. A key is a named object  representing a cryptographic key used for a specific purpose. The key material, the actual  bits used for encryption, can change over time as new key versions are created. 

A key is used to protect some corpus of data. A collection of files could be encrypted with  the same key and people with decrypt permissions on that key would be able to decrypt  those files. Therefore, it's necessary to make sure the rotation period is set to a specific  time. 

3.1 (GCP-CMAP-3-1) Ensure that the default network does not exist in a project (Automated)

Description:

To prevent use of default network, a project should not have a default network.

Rationale:

The default network has a preconfigured network configuration and automatically generates the following insecure firewall rules:

• default-allow-internal: Allows ingress connections for all protocols and ports among instances in the network.
• default-allow-ssh: Allows ingress connections on TCP port 22(SSH) from any source to any instance in the network.
• default-allow-rdp: Allows ingress connections on TCP port 3389(RDP) from any source to any instance in the network.
• default-allow-icmp: Allows ingress ICMP traffic from any source to any instance in the network.

These automatically created firewall rules do not get audit logged and cannot be configured to enable firewall rule logging.

Furthermore, the default network is an auto mode network, which means that its subnets use the same predefined range of IP addresses, and as a result, it's not possible to use Cloud VPN or VPC Network Peering with the default network.

Based on organization security and networking requirements, the organization should create a new network and delete the default network.

3.6 (GCP-CMAP-3-6) Ensure that SSH access is restricted from the internet 

Description:

GCP Firewall Rules are specific to a VPC Network. Each rule either allows or denies traffic when its conditions are met. Its conditions allow the user to specify the type of traffic, such as ports and protocols, and the source or destination of the traffic, including IP addresses, subnets, and instances.

Firewall rules are defined at the VPC network level and are specific to the network in which they are defined. The rules themselves cannot be shared among networks. Firewall rules only support IPv4 traffic. When specifying a source for an ingress rule or a destination for an egress rule by address, only an IPv4 address or IPv4 block in CIDR notation can be used. Generic (0.0.0.0/0) incoming traffic from the internet to VPC or VM instance using SSH on Port 22 can be avoided.

Rationale:

GCP Firewall Rules within a VPC Network apply to outgoing (egress) traffic from instances and incoming (ingress) traffic to instances in the network. Egress and ingress traffic flows are controlled even if the traffic stays within the network (for example, instance-to-instance communication). For an instance to have outgoing Internet access, the network must have a valid Internet gateway route or custom route whose destination IP is specified. This route simply defines the path to the Internet, to avoid the most general (0.0.0.0/0) destination IP Range specified from the Internet through SSH with the default Port 22. Generic access from the Internet to a specific IP Range needs to be restricted.

3.7 (GCP-CMAP-3-7) Ensure that RDP access is restricted from the Internet 

Description:

GCP Firewall Rules are specific to a VPC Network. Each rule either allows or denies traffic when its conditions are met. Its conditions allow users to specify the type of traffic, such as ports and protocols, and the source or destination of the traffic, including IP addresses, subnets, and instances.

Firewall rules are defined at the VPC network level and are specific to the network in which they are defined. The rules themselves cannot be shared among networks. Firewall rules only support IPv4 traffic. When specifying a source for an ingress rule or a destination for an egress rule by address, an IPv4 address or IPv4 block in CIDR notation can be used. Generic (0.0.0.0/0) incoming traffic from the Internet to a VPC or VM instance using RDP on Port 3389 can be avoided.

Rationale:

GCP Firewall Rules within a VPC Network. These rules apply to outgoing (egress) traffic from instances and incoming (ingress) traffic to instances in the network. Egress and ingress traffic flows are controlled even if the traffic stays within the network (for example, instance-to-instance communication). For an instance to have outgoing Internet access, the network must have a valid Internet gateway route or custom route whose destination IP is specified. This route simply defines the path to the Internet, to avoid the most general (0.0.0.0/0) destination IP Range specified from the Internet through RDP with the default Port 3389. Generic access from the Internet to a specific IP Range should be restricted.

4.1 (GCP-CMAP-4-1) Ensure that instances are not configured to use the default service account

Description:

It is recommended to configure your instance to not use the default Compute Engine service account because it has the Editor role on the project.

Rationale:

The default Compute Engine service account has the Editor role on the project, which allows read and write access to most Google Cloud Services. To defend against privilege escalations if your VM is compromised and prevent an attacker from gaining access to all of your project, it is recommended to not use the default Compute Engine service account. Instead, you should create a new service account and assigning only the permissions needed by your instance.

The default Compute Engine service account is named [PROJECT_NUMBER]-compute@developer.gserviceaccount.com.

4.2 (GCP-CMAP-4-2) Ensure that instances are not configured to use the default service account with full access to all Cloud APIs

Description:

To support principle of least privileges and prevent potential privilege escalation it is recommended that instances are not assigned to default service account Compute Engine default service account with Scope Allow full access to all Cloud APIs.

Rationale:

Along with ability to optionally create, manage and use user managed custom service accounts, Google Compute Engine provides default service account Compute Engine default service account for an instances to access necessary cloud services. Project Editor role is assigned to Compute Engine default service account hence, This service account has almost all capabilities over all cloud services except billing. However, when Compute Engine default service account assigned to an instance it can operate in 3 scopes. 1. Allow default access: Allows only minimum access required to run an Instance (Least Privileges) 2. Allow full access to all Cloud APIs: Allow full access to all the cloud APIs/Services (Too much access) 3. Set access for each API: Allows Instance administrator to choose only those APIs that are needed to perform specific business functionality expected by instance When an instance is configured with Compute Engine default service account with Scope Allow full access to all Cloud APIs, based on IAM roles assigned to the user(s) accessing Instance, it may allow user to perform cloud operations/API calls that user is not supposed to perform leading to successful privilege escalation.

4.3 (GCP-CMAP-4-3) Ensure "Block Project-wide SSH keys" is enabled for VM instances

Description:

It is recommended to use Instance specific SSH key(s) instead of using common/shared project-wide SSH key(s) to access Instances.

Rationale:

Project-wide SSH keys are stored in Compute/Project-meta-data. Project wide SSH keys can be used to login into all the instances within project. Using project-wide SSH keys eases the SSH key management but if compromised, poses the security risk which can impact all the instances within project. It is recommended to use Instance specific SSH keys which can limit the attack surface if the SSH keys are compromised.

4.5 (GCP-CMAP-4-5) Ensure 'Enable connecting to serial ports' is not enabled for VM Instance 

Description:

Interacting with a serial port is often referred to as the serial console, which is similar to using a terminal window, in that input and output is entirely in text mode and there is no graphical interface or mouse support.

If you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address. Therefore interactive serial console support should be disabled.

Rationale:

A virtual machine instance has four virtual serial ports. Interacting with a serial port is similar to using a terminal window, in that input and output is entirely in text mode and there is no graphical interface or mouse support. The instance's operating system, BIOS, and other system-level entities often write output to the serial ports, and can accept input such as commands or answers to prompts. Typically, these system-level entities use the first serial port (port 1) and serial port 1 is often referred to as the serial console.

The interactive serial console does not support IP-based access restrictions such as IP whitelists. If you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address. This allows anybody to connect to that instance if they know the correct SSH key, username, project ID, zone, and instance name.

Therefore interactive serial console support should be disabled.

4.6 (GCP-CMAP-4-6) Ensure that IP forwarding is not enabled on Instances 

Description:

Compute Engine instance cannot forward a packet unless the source IP address of the packet matches the IP address of the instance. Similarly, GCP won't deliver a packet whose destination IP address is different than the IP address of the instance receiving the packet. However, both capabilities are required if you want to use instances to help route packets.

Forwarding of data packets should be disabled to prevent data loss or information disclosure.

Rationale:

Compute Engine instance cannot forward a packet unless the source IP address of the packet matches the IP address of the instance. Similarly, GCP won't deliver a packet whose destination IP address is different than the IP address of the instance receiving the packet. However, both capabilities are required if you want to use instances to help route packets. To enable this source and destination IP check, disable the canIpForward field, which allows an instance to send and receive packets with non-matching destination or source IPs.

4.9 (GCP-CMAP-4-9) Ensure that Compute instances do not have public IP addresses (Automated)

Description:

Compute instances should not be configured to have external IP addresses.

Rationale:

To reduce your attack surface, Compute instances should not have public IP addresses. Instead, instances should be configured behind load balancers, to minimize the instance's exposure to the internet.

4.11 (GCP-CMAP-4-11)Ensure that Compute instances have Confidential Computing enabled

Description:

Google Cloud encrypts data at-rest and in-transit, but customer data must be decrypted for processing. Confidential Computing is a breakthrough technology which encrypts data in-use—while it is being processed. Confidential Computing environments keep data encrypted in memory and elsewhere outside the central processing unit (CPU).

Confidential VMs leverage the Secure Encrypted Virtualization (SEV) feature of AMD EPYC™ CPUs. Customer data will stay encrypted while it is used, indexed, queried, or trained on. Encryption keys are generated in hardware, per VM, and not exportable. Thanks to built-in hardware optimizations of both performance and security, there is no significant performance penalty to Confidential Computing workloads.

Rationale:

Confidential Computing enables customers' sensitive code and other data encrypted in memory during processing. Google does not have access to the encryption keys. Confidential VM can help alleviate concerns about risk related to either dependency on Google infrastructure or Google insiders' access to customer data in the clear.

5.1 (GCP-CMAP-5-1) Ensure that Cloud Storage bucket is not anonymously or publicly accessible 

Description:

It is recommended that IAM policy on Cloud Storage bucket does not allows anonymous or public access.

Rationale:

Allowing anonymous or public access grants permissions to anyone to access bucket content. Such access might not be desired if you are storing any sensitive data. Hence, ensure that anonymous or public access to a bucket is not allowed.

5.2 (GCP-CMAP-5-2) Ensure that Cloud Storage buckets have uniform bucket-level access enabled 

Description:

It is recommended that uniform bucket-level access is enabled on Cloud Storage buckets.

Rationale:

It is recommended to use uniform bucket-level access to unify and simplify how you grant access to your Cloud Storage resources. Cloud Storage offers two systems for granting users permission to access your buckets and objects: Cloud Identity and Access Management (Cloud IAM) and Access Control Lists (ACLs). These systems act in parallel - in order for a user to access a Cloud Storage resource, only one of the systems needs to grant the user permission. Cloud IAM is used throughout Google Cloud and allows you to grant a variety of permissions at the bucket and project levels. ACLs are used only by Cloud Storage and have limited permission options, but they allow you to grant permissions on a per-object basis.

In order to support a uniform permissioning system, Cloud Storage has uniform bucket-level access. Using this feature disables ACLs for all Cloud Storage resources: access to Cloud Storage resources then is granted exclusively through Cloud IAM. Enabling uniform bucket-level access guarantees that if a Storage bucket is not publicly accessible, no object in the bucket is publicly accessible either.

6.4 (GCP-CMAP-6-4) Ensure that the Cloud SQL database instance requires all incoming connections to use SSL 

Description:

It is recommended to enforce all incoming connections to SQL database instance to use SSL.

Rationale:

SQL database connections if successfully trapped (MITM); can reveal sensitive data like credentials, database queries, query outputs etc. For security, it is recommended to always use SSL encryption when connecting to your instance. This recommendation is applicable for Postgresql, MySql generation 1, MySql generation 2 and SQL Server 2017 instances.

6.5 (GCP-CMAP-6-5) Ensure that Cloud SQL database instances are not open to the world 

Description:

Database Server should accept connections only from trusted Network(s)/IP(s) and restrict access from the world.

Rationale:

To minimize attack surface on a Database server instance, only trusted/known and required IP(s) should be white-listed to connect to it. An authorized network should not have IPs/networks configured to 0.0.0.0/0 which will allow access to the instance from anywhere in the world. Note that authorized networks apply only to instances with public IPs.

6.6 (GCP-CMAP-6-6) Ensure that Cloud SQL database instances do not have public IPs 

Description:

It is recommended to configure Second Generation Sql instance to use private IPs instead of public IPs.

Rationale:

To lower the organization's attack surface, Cloud SQL databases should not have public IPs. Private IPs provide improved network security and lower latency for your application.

6.7 (GCP-CMAP-6-7) Ensure that Cloud SQL database instances are configured with automated backups 

Description:

It is recommended to have all SQL database instances set to enable automated backups.

Rationale:

Backups provide a way to restore a Cloud SQL instance to recover lost data or recover from a problem with that instance. Automated backups need to be set for any instance that contains data that should be protected from loss or damage. This recommendation is applicable for SQL Server, PostgreSql, MySql generation 1 and MySql generation 2 instances.