The following security controls are part of the GCP CIS 1.0.0 specifications and they can audited by our managed GCP security services. Please note the standard has more security controls that unfortunately cannot be audited at this time, due to lack of APIs from the Google platform. Our GCP Security Services can audit and help you remediate most of the technical controls listed below:
| CONTROL | DESCRIPTION |
|---|---|
| 1.1 Ensure that corporate login credentials are used instead of Gmail accounts | Use corporate login credentials instead of Gmail accounts. |
| 1.3 Ensure that there are only GCP-managed service account keys for each service account | User managed service account should not have user managed keys. |
| 1.4 Ensure that ServiceAccount has no Admin privileges. | A service account is a special Google account that belongs to your application or a VM, instead of to an individual end user. Your application uses the service account to call the Google API of a service, so that the users aren’t directly involved. |
| 1.5 Ensure that IAM users are not assigned Service Account User role at project level | It is recommended to assign `Service Account User (iam.serviceAccountUser)` role to a user for a specific service account rather than assigning the role to a user at project level. |
| 1.6 Ensure user-managed/external keys for service accounts are rotated every 90 days or less | Service Account keys consist of a key ID (Private_key_Id) and Private key, which are used to sign programmatic requests that you make to Google cloud services accessible to that particular Service account. |
| 1.8 Ensure Encryption keys are rotated within a period of 365 days | Google Cloud Key Management Service stores cryptographic keys in a hierarchical structure designed for useful and elegant access control management. Access to resources.The format for the rotation schedule depends on the client library that is used. |
| 2.1 Ensure that Cloud Audit Logging is configured properly across all services and all users from a project | It is recommended that Cloud Audit Logging is configured to track all Admin activities and read, write access to user data. |
| 2.2 Ensure that sinks are configured for all Log entries | It is recommended to create sink which will export copies of all the log entries. |
| 2.3 Ensure that object versioning is enabled on log-buckets | It is recommended to enable object versioning on log-buckets. |
| 2.4 Ensure log metric filter and alerts exists for Project Ownership assignments/changes | In order to prevent unnecessarily project ownership assignments to users/service-accounts and further misuses of project and resources, all `roles/Owner` assignments should be monitored. |
| 2.5 Ensure log metric filter and alerts exists for Audit Configuration Changes | Google Cloud Platform services write audit log entries to Admin Activity and Data Access logs to helps answer the questions of “who did what, where, and when?” within Google Cloud Platform projects. |
| 2.6 Ensure log metric filter and alerts exists for Custom Role changes | It is recommended that a metric filter and alarm be established for changes IAM Role creation, deletion and updating activities. |
| 2.7 Ensure log metric filter and alerts exists for VPC Network Firewall rule changes | It is recommended that a metric filter and alarm be established for VPC Network Firewall rule changes. |
| 2.8 Ensure log metric filter and alerts exists for VPC network route changes | It is recommended that a metric filter and alarm be established for VPC network route changes. |
| 2.9 Ensure log metric filter and alerts exists for VPC network changes | It is recommended that a metric filter and alarm be established for VPC network changes. |
| 2.10 Ensure log metric filter and alerts exists for Cloud Storage IAM permission changes | It is recommended that a metric filter and alarm be established for Cloud Storage Bucket IAM changes. |
| 2.11 Ensure log metric filter and alerts exists for SQL instance configuration changes | It is recommended that a metric filter and alarm be established for SQL Instance configuration changes. |
| 3.1 Ensure the default network does not exist in a project | To prevent use of `default` network, a project should not have a `default` network. |
| 3.3 Ensure that DNSSEC is enabled for Cloud DNS | DNSSEC in Cloud DNS enables domain owners to take easy steps to protect their domains against DNS hijacking and man-in-the-middle and other attacks. |
| 3.4 Ensure that RSASHA1 is not used for key-signing key in Cloud DNS DNSSEC | DNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms. |
| 3.5 Ensure that RSASHA1 is not used for zone-signing key in Cloud DNS DNSSEC | DNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms. |
| 3.9 Ensure VPC Flow logs is enabled for every subnet in VPC Network | Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC Subnets. After you’ve created a flow log, you can view and retrieve its data in Stackdriver Logging. |
| 4.1 Ensure that instances are not configured to use the default service account with full access to all Cloud APIs | 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`. |
| 4.2 Ensure “Block Project-wide SSH keys” enabled for VM instances | It is recommended to user Instance specific SSH key(s) instead of using common/shared project-wide SSH key(s) to access Instances. |
| 4.3 Ensure oslogin is enabled for a Project | Enabling OS login binds SSH certificates to IAM users and facilitates effective SSH certificate management. |
| 4.4 Ensure ‘Enable connecting to serial ports’ is not enabled for VM Instance | If you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address. |
| 4.5 Ensure that IP forwarding is not enabled on Instances | Forwarding of data packets should be disabled to prevent data loss or information disclosure. |
| 5.1 Ensure that Cloud Storage bucket is not anonymously or publicly accessible | It is recommended that IAM policy on Cloud Storage bucket does not allows anonymous and/or public access. |
| 5.3 Ensure that logging is enabled for Cloud storage buckets | It is recommended that storage Access Logs and Storage logs are enabled for every Storage Bucket. |
| 6.1 Ensure that Cloud SQL database instance requires all incoming connections to use SSL | It is recommended to enforce all incoming connections to SQL database instance to use SSL. |
| 6.2 Ensure that Cloud SQL database Instances are not open to the world | Database Server should accept connections only from trusted Network(s)/IP(s) and restrict access from the world. |
| 6.4 Ensure that MySQL Database Instance does not allows root login from any Host | It is recommended that root access to a MySql Database Instance should be allowed only through specific white-listed trusted IPs. |
| 7.1 Ensure Stackdriver Logging is set to Enabled on Kubernetes Engine Clusters | Stackdriver Logging lets you have Kubernetes Engine automatically collect, process, and store your container and system logs in a dedicated, persistent datastore. |
| 7.2 Ensure Stackdriver Monitoring is set to Enabled on Kubernetes Engine Clusters | Stackdriver Monitoring to monitor signals and build operations in your Kubernetes Engine clusters. |
| 7.3 Ensure Legacy Authorization is set to Disabled on Kubernetes Engine Clusters | In Kubernetes, authorizers interact by granting a permission if any authorizer grants the permission. The legacy authorizer in Kubernetes Engine grants broad, statically defined permissions. |
| 7.4 Ensure Master authorized networks is set to Enabled on Kubernetes Engine Clusters | Authorized networks are a way of specifying a restricted range of IP addresses that are permitted to access your container cluster’s Kubernetes master endpoint. |
| 7.5 Ensure Kubernetes Clusters are configured with Labels | A cluster label is a key-value pair that helps you organize your Google Cloud Platform resources, such as clusters. You can attach a label to each resource, then filter the resources based on their labels. |
| 7.6 Ensure Kubernetes web UI / Dashboard is disabled | Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster itself along with its attendant resources. |
| 7.7 Ensure `Automatic node repair` is enabled for Kubernetes Clusters | Kubernetes Engine’s node auto-repair feature helps you keep the nodes in your cluster in a healthy, running state. When enabled, Kubernetes Engine makes periodic checks on the health state of each node in your cluster. |
| 7.8 Ensure Automatic node upgrades is enabled on Kubernetes Engine Clusters nodes | Node auto-upgrades help you keep the nodes in your cluster or node pool up to date with the latest stable version of Kubernetes. |
| 7.10 Ensure Basic Authentication is disabled on Kubernetes Engine Clusters | Basic authentication allows a user to authenticate to the cluster with a username and password and it is stored in plain text without any encryption. Disabling Basic authentication will prevent attacks like brute force. |
| 7.11 Ensure Network policy is enabled on Kubernetes Engine Clusters | A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. |
| 7.13 Ensure Kubernetes Cluster is created with Alias IP ranges enabled | Google Cloud Platform Alias IP Ranges lets you assign ranges of internal IP addresses as aliases to a virtual machine’s network interfaces. |
| 7.14 Ensure PodSecurityPolicy controller is enabled on the Kubernetes Engine Clusters | A Pod Security Policy is a cluster-level resource that controls security sensitive aspects of the pod specification. |
| 7.15 Ensure Kubernetes Cluster is created with Private cluster enabled | A private cluster is a cluster that makes your master inaccessible from the public internet. In a private cluster, nodes do not have public IP addresses, so your workloads run in an environment that is isolated from the internet. |
| 7.16 Ensure Private Google Access is set on Kubernetes Engine Cluster Subnets | Private Google Access enables your cluster hosts, which have only private IP addresses, to communicate with Google APIs and services using an internal IP address rather than an external IP address. |
| 7.18 Ensure Kubernetes Clusters created with limited service account Access scopes for Project access | Access scopes are the legacy method of specifying permissions for your instance. Before the existence of IAM roles, access scopes were the only mechanism for granting permissions to service accounts. |
| 1.7 Ensure that Separation of duties is enforced while assigning service account related roles to users | It is recommended that the principle of ‘Separation of Duties’ is enforced while assigning service account related roles to users. |
| 1.9 Ensure that Separation of duties is enforced while assigning KMS related roles to users | It is recommended that the principle of ‘Separation of Duties’ is enforced while assigning KMS related roles to users. |
| 3.6 Ensure that SSH access is restricted from the internet | GCP `Firewall Rules` are specific to a `VPC Network`. Each rule either `allows` or `denies` traffic when its conditions are met. Generic `(0.0.0.0/0)` incoming traffic from internet to VPC or VM instance using `SSH` on `Port 22` can be avoided. |
| 3.7 Ensure that RDP access is restricted from the internet | GCP `Firewall Rules` are specific to a `VPC Network`. Each rule either `allows` or `denies` traffic when its conditions are met. Generic `(0.0.0.0/0)` incoming traffic from internet to VPC or VM instance using `RDP` on `Port 3389` can be avoided. |
| 3.8 Ensure Private Google Access is enabled for all subnetwork in VPC Network | Private Google Access enables virtual machine instances on a subnet to reach Google APIs and services using an internal IP address rather than an external IP address. |
| 4.6 Ensure VM disks for critical VMs are encrypted with Customer-Supplied Encryption Keys (CSEK) | If you supply your own encryption keys, Google uses your key to protect the Google-generated keys used to encrypt and decrypt your data. By default, Google Compute Engine encrypts all data at rest. |
| 7.9 Ensure Container-Optimized OS (cos) is used for Kubernetes Engine Clusters Node image | Container-Optimized OS is an operating system image for your Compute Engine VMs that is optimized for running Docker containers. |
| 7.17 Ensure default Service account is not used for Project access in Kubernetes Clusters | A service account is an identity that an instance or an application can use to run API requests on your behalf. This identity is used to identify applications running on your virtual machine instances to other Google Cloud Platform services. |