Remediating Security Health Analytics findings

This page provides a list of reference guides and techniques for remediating Security Health Analytics findings using Security Command Center.

You need adequate Identity and Access Management (IAM) roles to view or edit findings, and to access or modify Google Cloud resources. If you encounter permissions errors when accessing Security Command Center in the Google Cloud console, ask your administrator for assistance and, to learn about roles, see Access control. To resolve resource errors, read documentation for affected products.

Note: If you are a Premium customer and plan to switch to the Standard tier, we recommend that you resolve all findings before changing your tier. Findings reported by Premium detectors can't be automatically resolved in the Standard tier. For more information, see Switching tiers.

Security Health Analytics remediation

This section includes remediation instructions for all Security Health Analytics findings.

Caution: If done improperly, modifying the configuration of your resources can negatively affect your production environment. Also, enabling some suggested Google Cloud services can increase your cloud costs. Understand the impact of all remediation steps before making changes.

Deactivation of findings after remediation

After you remediate a vulnerability or misconfiguration finding, Security Health Analytics automatically sets the state of the finding to INACTIVE the next time it scans for the finding. How long Security Health Analytics takes to set a remediated finding to INACTIVE depends on when the finding is fixed and the schedule of the scan that detects the finding.

Security Health Analytics also sets the state of a finding to INACTIVE when a scan detects that the resource that is affected by the finding is deleted.

For information about scan intervals, see Security Health Analytics scan types.

Access Transparency disabled

Category name in the API: ACCESS_TRANSPARENCY_DISABLED

Access Transparency logs when Google Cloud employees access the projects in your organization to provide support. Enable Access Transparency to log who from Google Cloud is accessing your information, when, and why. For more information, see Access Transparency.

To enable Access Transparency on a project, the project must be associated with a billing account.

Required roles

To get the permissions that you need to perform this task, ask your administrator to grant you the Access Transparency Admin (roles/axt.admin) IAM role at the organization level. For more information about granting roles, see Manage access.

This predefined role contains the permissions axt.labels.get and axt.labels.set, which are required to perform this task. You might also be able to get these permissions with a custom role or other predefined roles.

Remediation steps

To remediate this finding, complete the following steps:

1. Check your organization-level permissions:

   1. Go to the Identity and Access Management page on the Google Cloud console.

      Go to Identity and Access Management

   2. If you're prompted, select the Google Cloud organization in the selector menu.

2. Select any Google Cloud project within the organization using the selector menu.

   Access Transparency is configured on a Google Cloud project page but Access Transparency is enabled for the entire organization.

3. Go to the IAM & Admin > Settings page.

4. Click Enable Access Transparency.

Learn about this finding type's supported assets and scan settings.

Admin service account

Category name in the API: ADMIN_SERVICE_ACCOUNT

A service account in your organization or project has Admin, Owner, or Editor privileges assigned to it. These roles have broad permissions and shouldn't be assigned to service accounts. To learn about service accounts and the roles available to them, see Service accounts.

To remediate this finding, complete the following steps:

1. Go to the IAM policy page in the Google Cloud console.

   Go to IAM policy

2. For each principal identified in the finding:

   1. Click Edit next to the principal.
   2. To remove permissions, click Delete next to the offending role.
   3. Click Save.

Learn about this finding type's supported assets and scan settings.

Alpha cluster enabled

Category name in the API: ALPHA_CLUSTER_ENABLED

Alpha cluster features are enabled for a Google Kubernetes Engine (GKE) cluster.

Alpha clusters let early adopters experiment with workloads that use new features before they're released to the general public. Alpha clusters have all GKE API features enabled, but aren't covered by the GKE SLA, don't receive security updates, have node auto-upgrade and node auto-repair disabled, and can't be upgraded. They're also automatically deleted after 30 days.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

Alpha clusters can't be disabled. You must create a new cluster with alpha features disabled.

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Click Create.

3. Select Configure next to the type of cluster you want to create.

4. Under the Features tab, ensure Enable Kubernetes alpha features in this cluster is disabled.

   Note: If you selected GKE Autopilot, you won't see this option because Alpha clusters aren't supported.

5. Click Create.

6. To move workloads to the new cluster, see Migrating workloads to different machine types.

7. To delete the original cluster, see Deleting a cluster.

Learn about this finding type's supported assets and scan settings.

API key APIs unrestricted

Category name in the API: API_KEY_APIS_UNRESTRICTED

There are API keys being used too broadly.

Unrestricted API keys are insecure because they can be retrieved from devices on which the key is stored or can be seen publicly, for instance, from within a browser. In accordance with the principle of least privilege, configure API keys to only call APIs required by the application. For more information, see Apply API key restrictions.

To remediate this finding, complete the following steps:

1. Go to the API keys page in the Google Cloud console.

   Go to API keys

2. For each API key:

   1. In the API keys section, on the row for each API key for which you need to restrict APIs, display the Actions menu by clicking the icon.
   2. From the Actions menu, click Edit API key. The Edit API key page opens.
   3. In the API restrictions section, select Restrict APIs. The Select APIs drop-down menu appears.
   4. On the Select APIs drop-down list, select which APIs to allow.

      Warning: Do not set API restrictions to Google Cloud APIs, as it allows access to all services offered by Google Cloud.

   5. Click Save. It might take up to five minutes for settings to take effect.

Learn about this finding type's supported assets and scan settings.

API key apps unrestricted

Category name in the API: API_KEY_APPS_UNRESTRICTED

There are API keys being used in an unrestricted way, allowing use by any untrusted app.

Unrestricted API keys are insecure because they can be retrieved on devices on which the key is stored or can be seen publicly, for instance, from within a browser. In accordance with the principle of least privilege, restrict API key usage to trusted hosts, HTTP referrers, and apps. For more information, see Apply API key restrictions.

To remediate this finding, complete the following steps:

1. Go to the API keys page in the Google Cloud console.

   Go to API keys

2. For each API key:

   1. In the API keys section, on the row for each API key for which you need to restrict applications, display the Actions menu by clicking the icon.
   2. From the Actions menu, click Edit API key. The Edit API key page opens.
   3. On the Edit API key page, under Application restrictions, select a restriction category. You can set one application restriction per key.
   4. In the Add an item field that appears when you select a restriction, click Add an item to add restrictions based on the needs of your application.
   5. Once finished adding items, click Done.

      Warning: Do not set HTTP referrers to wild-cards that allow access to any/wide HTTP referrers, for example, *, *.[TLD], or .[TLD]/*). Do not set IP addresses and referrers to allow any host (0.0.0.0, ::0, or 0.0.0.0/0).

   6. Click Save.

Learn about this finding type's supported assets and scan settings.

API key exists

Category name in the API: API_KEY_EXISTS

A project is using API keys instead of standard authentication.

API keys are less secure than other authentication methods because they are simple encrypted strings and easy for others to discover and use. They can be retrieved on devices on which the key is stored or can be seen publicly, for instance, from within a browser. Also, API keys do not uniquely identify users or applications making requests. As an alternative, you can use a standard authentication flow, with either service accounts or user accounts.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

1. Ensure your applications are configured with an alternate form of authentication.

2. Go to the API credentials page in the Google Cloud console.

   Go to API credentials

3. In the API keys section on the row for each API key that you need to delete, display the Actions menu by clicking the icon.

4. From the Actions menu, click Delete API key.

Learn about this finding type's supported assets and scan settings.

API key not rotated

Category name in the API: API_KEY_NOT_ROTATED

An API key hasn't been rotated for more than 90 days.

API keys do not expire, so if one is stolen, it might be used indefinitely unless the project owner revokes or rotates the key. Regenerating API keys frequently reduces the amount of time that a stolen API key can be used to access data on a compromised or terminated account. Rotate API keys at least every 90 days. For more information, see Secure an API key.

To remediate this finding, complete the following steps:

1. Go to the API keys page in the Google Cloud console.

   Go to API keys

2. For each API key:

   1. In the API keys section, on the row for each API key that you need to rotate, display the Actions menu by clicking the icon.
   2. From the Actions menu, click Edit API key. The Edit API key page opens.
   3. On the Edit API key page, if the date in the Creation date field is older than 90 days, replace the key by clicking Regenerate key at the top of page. A new replacement key is generated.
   4. Click Save.
   5. To ensure your applications continue working uninterrupted, update them to use the new API key. The old API key works for 24 hours before it is permanently deactivated.

Learn about this finding type's supported assets and scan settings.

Audit config not monitored

Category name in the API: AUDIT_CONFIG_NOT_MONITORED

Log metrics and alerts aren't configured to monitor audit configuration changes.

Cloud Logging produces Admin Activity and Data Access logs that enable security analysis, resource change tracking, and compliance auditing. By monitoring audit configuration changes, you ensure that all activities in your project can be audited at any time. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, create metrics, if necessary, and alert policies:

Create metric

1. Go to the Logs-based Metrics page in the Google Cloud console.

   Go to Logs-based Metrics

2. Click Create Metric.

3. Under Metric Type, select Counter.

4. Under Details:

   1. Set a Log metric name.
   2. Add a description.
   3. Set Units to 1.

5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:

     protoPayload.methodName="SetIamPolicy"
     AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*
   

6. Click Create Metric. You see a confirmation.

Create Alert Policy

1. In the Google Cloud console, select Logging, and then select Log-based metrics, or click the following button:

   Go to Log-based metrics

2. Under the User-defined metrics section, select the metric you created in the previous section.

3. Click More , and then click Create alert from metric.

   The New condition dialog opens with the metric and data transformation options pre-populated.

4. Click Next.
   1. Review the pre-populated settings. You might want to modify the Threshold value.
   2. Click Condition name and enter a name for the condition.
5. Click Next.

6. To add notifications to your alerting policy, click Notification channels. In the dialog, select one or more notification channels from the menu, and then click OK.

   To be notified when incidents are opened and closed, check Notify on incident closure. By default, notifications are sent only when incidents are opened.

7. Optional: Update the Incident autoclose duration. This field determines when Monitoring closes incidents in the absence of metric data.
8. Optional: Click Documentation, and then add any information that you want included in a notification message.
9. Click Alert name and enter a name for the alerting policy.
10. Click Create Policy.

Learn about this finding type's supported assets and scan settings.

Audit logging disabled

Category name in the API: AUDIT_LOGGING_DISABLED

This finding isn't available for project-level activations.

Audit logging is disabled for one or more Google Cloud services, or one or more principals are exempt from data access audit logging.

Enable Cloud Logging for all services to track all admin activities, read access, and write access to user data. Depending on the quantity of information, Cloud Logging costs can be significant. To understand your usage of the service and its cost, see Cost optimization for Google Cloud's operations suite.

If any principals are exempted from data access audit logging on either the default data access audit logging configuration or the logging configurations for any individual services, remove the exemption.

To remediate this finding, complete the following steps:

1. Go to the Data Access audit logs default configuration page in the Google Cloud console.

   Go to default configuration

2. On the Log types tab, activate data access audit logging in the the default configuration:

   1. Select Admin Read, Data Read, and Data Write.
   2. Click Save.

3. On the Exempted principals tab, remove all exempted users from the default configuration:

   1. Remove each listed principal by clicking Delete next to each name.
   2. Click Save.

4. Go to the Audit Logs page.

   Go to audit logs

5. Remove any exempted principals from the data access audit log configurations of individual services.

   1. Under Data access audit logs configuration, for each service that shows an exempted principal, click on the service. An audit log configuration panel opens for the service.
   2. On the Exempted principals tab, remove all exempted principals by clicking Delete next to each name.
   3. Click Save.

Learn about this finding type's supported assets and scan settings.

Auto backup disabled

Category name in the API: AUTO_BACKUP_DISABLED

A Cloud SQL database doesn't have automatic backups enabled.

To prevent data loss, turn on automated backups for your SQL instances. For more information, see Creating and managing on-demand and automatic backups.

To remediate this finding, complete the following steps:

1. Go to the SQL instance backups page in the Google Cloud console.

   Go to SQL instance backups

2. Next to Settings, click Edit .

3. Select the box for Automate backups.

4. In the drop-down menu, choose a window of time for your data to be automatically backed up.

5. Click Save.

Learn about this finding type's supported assets and scan settings.

Auto repair disabled

Category name in the API: AUTO_REPAIR_DISABLED

A Google Kubernetes Engine (GKE) cluster's auto repair feature, which keeps nodes in a healthy, running state, is disabled.

When enabled, GKE makes periodic checks on the health state of each node in your cluster. If a node fails consecutive health checks over an extended time period, GKE initiates a repair process for that node. For more information, see Auto-repairing nodes.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Click the Nodes tab.

3. For each node pool:

   1. Click the name of the node pool to go to its detail page.
   2. Click Edit .
   3. Under Management, select Enable auto-repair.
   4. Click Save.

Learn about this finding type's supported assets and scan settings.

Auto upgrade disabled

Category name in the API: AUTO_UPGRADE_DISABLED

A GKE cluster's auto upgrade feature, which keeps clusters and node pools on the latest stable version of Kubernetes, is disabled.

For more information, see Auto-upgrading nodes.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. In the list of clusters, click the name of the cluster.

3. Click the Nodes tab.

4. For each node pool:

   1. Click the name of the node pool to go to its detail page.
   2. Click Edit .
   3. Under Management, select Enable auto-upgrade.
   4. Click Save.

Learn about this finding type's supported assets and scan settings.

BigQuery table CMEK disabled

Category name in the API: BIGQUERY_TABLE_CMEK_DISABLED

A BigQuery table is not configured to use a customer-managed encryption key (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google Cloud uses to encrypt your data, giving you more control over access to your data. For more information, see Protecting data with Cloud KMS keys.

Caution: These remediation steps can disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

1. Create a table protected by Cloud Key Management Service.
2. Copy your table to the new CMEK-enabled table.
3. Delete the original table.

To set a default CMEK key that encrypts all new tables in a dataset, see Set a dataset default key.

Learn about this finding type's supported assets and scan settings.

Binary authorization disabled

Category name in the API: BINARY_AUTHORIZATION_DISABLED

Binary Authorization is disabled on a GKE cluster.

Binary Authorization includes an optional feature that protects supply chain security by only allowing container images signed by trusted authorities during the development process to be deployed in the cluster. By enforcing signature-based deployment, you gain tighter control over your container environment, ensuring only verified images are allowed to be deployed.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. In the Security section, click on the edit icon () in the Binary Authorization row.

   If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

3. In the dialog, select Enable Binary Authorization.

4. Click Save changes.

5. Go to the Binary Authorization setup page.

   Go to Binary Authorization

6. Ensure a policy that requires attestors is configured and the project default rule is not configured to Allow all images. For more information, see Set up for GKE.

   To ensure that images that violate the policy are allowed to be deployed and violations are logged to Cloud Audit Logs, you can enable dry-run mode.

Learn about this finding type's supported assets and scan settings.

Bucket CMEK disabled

Category name in the API: BUCKET_CMEK_DISABLED

A bucket is not encrypted with customer-managed encryption keys (CMEK).

Setting a default CMEK on a bucket gives you more control over access to your data. For more information, see Customer-managed encryption keys.

To remediate this finding, use CMEK with a bucket by following Using customer-managed encryption keys. CMEK incurs additional costs related to Cloud KMS.

Note: Setting a default key will not retroactively re-encrypt objects currently in the bucket with a new key.

Learn about this finding type's supported assets and scan settings.

Bucket IAM not monitored

Category name in the API: BUCKET_IAM_NOT_MONITORED

Log metrics and alerts aren't configured to monitor Cloud Storage IAM permission changes.

Monitoring changes to Cloud Storage bucket permissions helps you identify over-privileged users or suspicious activity. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

Create metric

1. Go to the Logs-based Metrics page in the Google Cloud console.

   Go to Logs-based Metrics

2. Click Create Metric.

3. Under Metric Type, select Counter.

4. Under Details:

   1. Set a Log metric name.
   2. Add a description.
   3. Set Units to 1.

5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:

     resource.type=gcs_bucket
     AND protoPayload.methodName="storage.setIamPermissions"
   

6. Click Create Metric. You see a confirmation.

Create Alert Policy

1. In the Google Cloud console, select Logging, and then select Log-based metrics, or click the following button:

   Go to Log-based metrics

2. Under the User-defined metrics section, select the metric you created in the previous section.

3. Click More , and then click Create alert from metric.

   The New condition dialog opens with the metric and data transformation options pre-populated.

4. Click Next.
   1. Review the pre-populated settings. You might want to modify the Threshold value.
   2. Click Condition name and enter a name for the condition.
5. Click Next.

6. To add notifications to your alerting policy, click Notification channels. In the dialog, select one or more notification channels from the menu, and then click OK.

   To be notified when incidents are opened and closed, check Notify on incident closure. By default, notifications are sent only when incidents are opened.

7. Optional: Update the Incident autoclose duration. This field determines when Monitoring closes incidents in the absence of metric data.
8. Optional: Click Documentation, and then add any information that you want included in a notification message.
9. Click Alert name and enter a name for the alerting policy.
10. Click Create Policy.

Learn about this finding type's supported assets and scan settings.

Bucket logging disabled

Category name in the API: BUCKET_LOGGING_DISABLED

There is a storage bucket without logging enabled.

To help investigate security issues and monitor storage consumption, enable access logs and storage information for your Cloud Storage buckets. Access logs provide information for all requests made on a specified bucket, and the storage logs provide information about the storage consumption of that bucket.

To remediate this finding, set up logging for the bucket indicated by the Security Health Analytics finding by completing the usage logs & storage logs guide.

Learn about this finding type's supported assets and scan settings.

Bucket policy only disabled

Category name in the API: BUCKET_POLICY_ONLY_DISABLED

Uniform bucket-level access, previously called Bucket Policy Only, isn't configured.

Uniform bucket-level access simplifies bucket access control by disabling object-level permissions (ACLs). When enabled, only bucket-level IAM permissions grant access to the bucket and the objects it contains. For more information, see Uniform bucket-level access.

To remediate this finding, complete the following steps:

1. Go to the Cloud Storage browser page in the Google Cloud console.

   Go to Cloud Storage browser

2. In the list of buckets, click the name of the desired bucket.

3. Click the Configuration tab.

4. Under Permissions, in the row for Access control, click the edit icon ().

5. In the dialog, select Uniform.

6. Click Save.

Learn about this finding type's supported assets and scan settings.

Cloud Asset API disabled

Category name in the API: CLOUD_ASSET_API_DISABLED

Cloud Asset Inventory service is not enabled for the project.

To remediate this finding, complete the following steps:

1. Go to the API Library page in the Google Cloud console.

   Go to API Library

2. Search for Cloud Asset Inventory.

3. Select the result for Cloud Asset API service.

4. Ensure that API Enabled is displayed.

Cluster logging disabled

Category name in the API: CLUSTER_LOGGING_DISABLED

Logging isn't enabled for a GKE cluster.

To help investigate security issues and monitor usage, enable Cloud Logging on your clusters.

Depending on the quantity of information, Cloud Logging costs can be significant. To understand your usage of the service and its cost, see Cost optimization for Google Cloud's operations suite.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Select the cluster listed in the Security Health Analytics finding.

3. Click Edit.

   If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

4. On the Legacy Stackdriver Logging or Stackdriver Kubernetes Engine Monitoring drop-down list, select Enabled.

   These options aren't compatible. Make sure that you use either Stackdriver Kubernetes Engine Monitoring alone, or Legacy Stackdriver Logging with Legacy Stackdriver Monitoring.

5. Click Save.

Learn about this finding type's supported assets and scan settings.

Cluster monitoring disabled

Category name in the API: CLUSTER_MONITORING_DISABLED

Monitoring is disabled on GKE clusters.

To help investigate security issues and monitor usage, enable Cloud Monitoring on your clusters.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Select the cluster listed in the Security Health Analytics finding.

3. Click Edit.

   If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

4. On the Legacy Stackdriver Monitoring or Stackdriver Kubernetes Engine Monitoring drop-down list, select Enabled.

   These options aren't compatible. Make sure that you use either Stackdriver Kubernetes Engine Monitoring alone, or Legacy Stackdriver Monitoring with Legacy Stackdriver Logging.

5. Click Save.

Learn about this finding type's supported assets and scan settings.

Cluster private Google access disabled

Category name in the API: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Cluster hosts are not configured to use only private, internal IP addresses to access Google APIs.

Private Google Access enables virtual machine (VM) instances with only private, internal IP addresses to reach the public IP addresses of Google APIs and services. For more information, see Configuring Google Private Access.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the Virtual Private Cloud networks page in the Google Cloud console.

   Go to VPC networks

2. In the list of networks, click the name of the desired network.

3. On the VPC network details page, click the Subnets tab.

4. In the list of subnets, click the name of the subnet associated with the Kubernetes cluster in the finding.

5. On the Subnet details page, click Edit .

6. Under Private Google Access, select On.

7. Click Save.

8. To remove public (external) IPs from VM instances whose only external traffic is to Google APIs, see Unassigning a static external IP address.

Learn about this finding type's supported assets and scan settings.

Cluster secrets encryption disabled

Category name in the API: CLUSTER_SECRETS_ENCRYPTION_DISABLED

Application-layer secrets encryption is disabled on a GKE cluster.

Application-layer secrets encryption ensures GKE secrets are encrypted using Cloud KMS keys. The feature provides an additional layer of security for sensitive data, such as user-defined secrets and secrets required for the operation of the cluster, such as service account keys, which are all stored in etcd.

To remediate this finding, complete the following steps:

1. Go to the Cloud KMS keys page in the Google Cloud console.

   Go to Cloud KMS keys

2. Review your application keys or create a database encryption key (DEK). For more information, see Creating a Cloud KMS key.

3. Go to the Kubernetes clusters page.

   Go to Kubernetes clusters

4. Select the cluster in the finding.

5. Under Security, in the Application-layer secrets encryption field, click Edit Application-layer Secrets Encryption.

6. Select the Enable Application-layer Secrets Encryption checkbox, and then choose the DEK you created.

7. Click Save Changes.

Learn about this finding type's supported assets and scan settings.

Cluster shielded nodes disabled

Category name in the API: CLUSTER_SHIELDED_NODES_DISABLED

Shielded GKE nodes are not enabled for a cluster.

Without Shielded GKE nodes, attackers can exploit a vulnerability in a Pod to exfiltrate bootstrap credentials and impersonate nodes in your cluster. The vulnerability can give attackers access to cluster secrets.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Select the cluster in the finding.

3. Under Security, in the Shielded GKE nodes field, click Edit Shielded GKE nodes.

4. Select the Enable Shielded GKE nodes checkbox.

5. Click Save Changes.

Learn about this finding type's supported assets and scan settings.

Compute project wide SSH keys allowed

Category name in the API: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

Project-wide SSH keys are used, allowing login to all instances in the project.

Using project-wide SSH keys makes SSH key management easier but, if compromised, poses a security risk which can impact all instances within a project. You should use instance-specific SSH keys, which limit the attack surface if SSH keys are compromised. For more information, see Managing SSH keys in metadata.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. In the list of instances, click the name of the instance in the finding.

3. On the VM instance details page, click Edit.

   Note: You can't edit instances created using instance templates. To make changes to an instance template's configuration, see How to update instance templates.

4. Under SSH Keys, select Block project-wide SSH keys.

5. Click Save.

Learn about this finding type's supported assets and scan settings.

Compute Secure Boot disabled

Category name in the API: COMPUTE_SECURE_BOOT_DISABLED

A Shielded VM does not have Secure Boot enabled.

Using Secure Boot helps protect your virtual machines against rootkits and bootkits. Compute Engine does not enable Secure Boot by default because some unsigned drivers and low-level software are not compatible. If your VM does not use incompatible software and it boots with Secure Boot enabled, Google recommends using Secure Boot. If you are using third-party modules with Nvidia drivers, make sure they are compatible with Secure Boot before your enable it.

For more information, see Secure Boot.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. In the list of instances, click the name of the instance in the finding.

3. On the VM instance details page, click Stop.

4. After the instance stops, click Edit.

5. Under Shielded VM, select Turn on Secure Boot.

6. Click Save.

7. Click Start to start the instance.

Learn about this finding type's supported assets and scan settings.

Compute serial ports enabled

Category name in the API: COMPUTE_SERIAL_PORTS_ENABLED

Serial ports are enabled for an instance, allowing connections to the instance's serial console.

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. For more information, see Enabling access for a project.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. In the list of instances, click the name of the instance in the finding.

3. On the VM instance details page, click Edit.

4. Under Remote access, clear Enable connecting to serial ports.

5. Click Save.

Learn about this finding type's supported assets and scan settings.

Confidential Computing disabled

Category name in the API: CONFIDENTIAL_COMPUTING_DISABLED

A Compute Engine instance doesn't have Confidential Computing enabled.

Confidential Computing adds a third pillar to the end-to-end encryption story by encrypting data while in use. With the confidential execution environments provided by Confidential Computing and AMD Secure Encrypted Virtualization (SEV), Google Cloud keeps sensitive code and other data encrypted in memory during processing.

Confidential Computing can only be enabled when an instance is created. Thus, you must delete the current instance and create a new one.

For more information, see Confidential VM and Compute Engine.

Note: Confidential Computing is only supported on N2D machine types.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. In the list of instances, click the name of the instance in the finding.

3. On the VM instance details page, click Delete.

4. Create a Confidential VM using the Google Cloud console.

Learn about this finding type's supported assets and scan settings.

COS not used

Category name in the API: COS_NOT_USED

Compute Engine VMs aren't using the Container-Optimized OS, which is designed to run Docker containers on Google Cloud securely.

Container-Optimized OS is Google's recommended OS for hosting and running containers on Google Cloud. Its small OS footprint minimizes security exposure, while automatic updates patch security vulnerabilities in a timely manner. For more information, see Container-Optimized OS Overview.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. In the list of clusters, click the name of the cluster in the finding.

3. Click the Nodes tab.

4. For each node pool:

   1. Click the name of the node pool to go to its detail page.
   2. Click Edit .
   3. Under Nodes -> Image type, click Change.
   4. Select Container-Optimized OS, and then click Change.
   5. Click Save.

Learn about this finding type's supported assets and scan settings.

Custom role not monitored

Category name in the API: CUSTOM_ROLE_NOT_MONITORED

Log metrics and alerts aren't configured to monitor custom role changes.

IAM provides predefined and custom roles that grant access to specific Google Cloud resources. By monitoring role creation, deletion, and update activities, you can identify over-privileged roles at early stages. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

Create metric

1. Go to the Logs-based Metrics page in the Google Cloud console.

   Go to Logs-based Metrics

2. Click Create Metric.

3. Under Metric Type, select Counter.

4. Under Details:

   1. Set a Log metric name.
   2. Add a description.
   3. Set Units to 1.

5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:

     resource.type="iam_role"
     AND (protoPayload.methodName="google.iam.admin.v1.CreateRole"
     OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
     OR protoPayload.methodName="google.iam.admin.v1.UpdateRole")
   

6. Click Create Metric. You see a confirmation.

Create Alert Policy

1. In the Google Cloud console, select Logging, and then select Log-based metrics, or click the following button:

   Go to Log-based metrics

2. Under the User-defined metrics section, select the metric you created in the previous section.

3. Click More , and then click Create alert from metric.

   The New condition dialog opens with the metric and data transformation options pre-populated.

4. Click Next.
   1. Review the pre-populated settings. You might want to modify the Threshold value.
   2. Click Condition name and enter a name for the condition.
5. Click Next.

6. To add notifications to your alerting policy, click Notification channels. In the dialog, select one or more notification channels from the menu, and then click OK.

   To be notified when incidents are opened and closed, check Notify on incident closure. By default, notifications are sent only when incidents are opened.

7. Optional: Update the Incident autoclose duration. This field determines when Monitoring closes incidents in the absence of metric data.
8. Optional: Click Documentation, and then add any information that you want included in a notification message.
9. Click Alert name and enter a name for the alerting policy.
10. Click Create Policy.

Learn about this finding type's supported assets and scan settings.

Dataproc CMEK disabled

Category name in the API: DATAPROC_CMEK_DISABLED

A Dataproc cluster was created without an encryption configuration CMEK. With CMEK, keys that you create and manage in Cloud Key Management Service wrap the keys that Google Cloud uses to encrypt your data, giving you more control over access to your data.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

1. Go to the Dataproc cluster page in the Google Cloud console.

   Go to Dataproc clusters

2. Select your project and click Create Cluster.

3. In the Manage security section, click Encryption and the select Customer-managed key.

4. Select a customer-managed key from the list.

   If you don't have a customer-managed key, then you need create one to use. For more information, see Customer-managed encryption keys.

5. Ensure that the selected KMS key has the Cloud KMS CryptoKey Encrypter/Decrypter role assign to the Dataproc Cluster service account ("serviceAccount:[e-mail]").

6. After the cluster is created, migrate all of your workloads from the older cluster to the new cluster.

7. Go to Dataproc clusters and select your project.

8. Select the old cluster and click Delete cluster.

9. Repeat all steps above for other Dataproc clusters available in the selected project.

Learn about this finding type's supported assets and scan settings.

Dataproc image outdated

Category name in the API: DATAPROC_IMAGE_OUTDATED

A Dataproc cluster was created using a Dataproc image version that is affected by security vulnerabilities in the Apache Log4j 2 utility (CVE-2021-44228 and CVE-2021-45046).

This detector finds vulnerabilities by checking if the softwareConfig.imageVersion field in the config property of a Cluster has any of the following affected versions:

• Image versions earlier than 1.3.95.
• Subminor image versions earlier than 1.4.77, 1.5.53, and 2.0.27.

The version number of a custom Dataproc image can be overridden manually. Consider the following scenarios:

• One can modify the version of an affected custom image to make it appear to be unaffected. In this case, this detector doesn't emit a finding.
• One can override the version of an unaffected custom image with one that is known to have the vulnerability. In this case, this detector emits a false positive finding. To suppress these false positive findings, you can mute them.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, recreate and update the affected cluster.

Learn about this finding type's supported assets and scan settings.

Dataset CMEK disabled

Category name in the API: DATASET_CMEK_DISABLED

A BigQuery dataset is not configured to use a default customer-managed encryption key (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google Cloud uses to encrypt your data, giving you more control over access to your data. For more information, see Protecting data with Cloud KMS keys.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

You can't switch a table in place between default encryptions and CMEK encryption. To set a default CMEK key with which to encrypt all new tables in the dataset, follow the instructions to Set a dataset default key.

Setting a default key will not retroactively re-encrypt tables currently in the dataset with a new key. To use CMEK for existing data, do the following:

1. Create a new dataset.
2. Set a default CMEK key on the dataset you created.
3. To copy tables to your CMEK-enabled dataset, follow the instructions for Copying a table.
4. After copying data successfully, delete the original datasets.

Learn about this finding type's supported assets and scan settings.

Default network

Category name in the API: DEFAULT_NETWORK

The default network exists in a project.

Default networks have automatically created firewall rules and network configurations which might not be secure. For more information, see Default network.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the VPC networks page in the Google Cloud console.

   Go to VPC networks

2. In the list of networks, click the name of the default network.

3. In the VPC network details page, click Delete VPC Network.

4. To create a new network with custom firewall rules, see Creating networks.

Learn about this finding type's supported assets and scan settings.

Default service account used

Category name in the API: DEFAULT_SERVICE_ACCOUNT_USED

A Compute Engine instance is configured to use the default service account.

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 and unauthorized access, don't use the default Compute Engine service account. Instead, create a new service account and assign only the permissions needed by your instance. Read Access control for information on roles and permissions.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. Select the instance related to the Security Health Analytics finding.

3. On the Instance details page that loads, click Stop.

4. After the instance stops, click Edit.

5. Under the Service Account section, select a service account other than the default Compute Engine service account. You might first need to create a new service account. Read Access control for information on IAM roles and permissions.

6. Click Save. The new configuration appears on the Instance details page.

Learn about this finding type's supported assets and scan settings.

Disk CMEK disabled

Category name in the API: DISK_CMEK_DISABLED

Disks on this VM are not encrypted with customer-managed encryption keys (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google Cloud uses to encrypt your data, giving you more control over access to your data. For more information, see Protecting Resources with Cloud KMS Keys.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

1. Go to the Compute Engine disks page in the Google Cloud console.

   Go to Compute Engine disks

2. In the list of disks, click the name of the disk indicated in the finding.

3. On the Manage disk page, click Delete.

4. To create a new disk with CMEK enabled, see Encrypt a new persistent disk with your own keys. CMEK incurs additional costs related to Cloud KMS.

Learn about this finding type's supported assets and scan settings.

Disk CSEK disabled

Category name in the API: DISK_CSEK_DISABLED

Disks on this VM are not encrypted with Customer-Supplied Encryption Keys (CSEK). Disks for critical VMs should be encrypted with CSEK.

If you provide your own encryption keys, Compute Engine uses your key to protect the Google-generated keys used to encrypt and decrypt your data. For more information, see Customer-Supplied Encryption Keys. CSEK incurs additional costs related to Cloud KMS.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

Delete and create disk

You can only encrypt new persistent disks with your own key. You cannot encrypt existing persistent disks with your own key.

1. Go to the Compute Engine disks page in the Google Cloud console.

   Go to Compute Engine disks

2. In the list of disks, click the name of the disk indicated in the finding.

3. On the Manage disk page, click Delete.

4. To create a new disk with CSEK enabled, see Encrypt disks with customer- supplied encryption keys.

5. Complete the remaining steps to enable the detector.

Enable the detector

1. Go to Security Command Center's Assets page in the Google Cloud console.

   Go to Assets

2. In the Resource type section of the Quick filters panel, select compute.Disk.

   If you don't see compute.Disk, click View more, enter Disk in the search field, and then click Apply.

   The Results panel updates to show only instances of the compute.Disk resource type.

3. In the Display name column, select the box next to the name of the disk you want to use with CSEK, and then click Set Security Marks.

4. In the dialog, click Add Mark.

5. In the key field, enter enforce_customer_supplied_disk_encryption_keys, and in the value field, enter true.

6. Click Save.

Learn about this finding type's supported assets and scan settings.

DNS logging disabled

Category name in the API: DNS_LOGGING_DISABLED

Monitoring of Cloud DNS logs provides visibility to DNS names requested by the clients within the VPC network. These logs can be monitored for anomalous domain names and evaluated against threat intelligence. We recommend enabling DNS logging for VPC networks.

Depending on the quantity of information, Cloud DNS logging costs can be significant. To understand your usage of the service and its cost, see Pricing for Google Cloud's operations suite: Cloud Logging.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the VPC networks page in the Google Cloud console.

   Go to VPC networks

2. In the list of networks, click the name of the VPC network.

3. Create a new server policy (if one doesn't exist) or edit an existing policy:

   • If the network doesn't have a DNS server policy, complete the following steps:

     1. Click Edit.
     2. In the DNS server policy field, click Create a new server policy.
     3. Enter a name for the new server policy.
     4. Set Logs to On.
     5. Click Save.

   • If the network has a DNS server policy, complete the following steps:

     1. In the DNS server policy field, click the name of the DNS policy.
     2. Click Edit policy.
     3. Set Logs to On.
     4. Click Save.

Learn about this finding type's supported assets and scan settings.

DNSSEC disabled

Category name in the API: DNSSEC_DISABLED

Domain Name System Security Extensions (DNSSEC) is disabled for Cloud DNS zones.

DNSSEC validates DNS responses and mitigates risks, such as DNS hijacking and person-in-the-middle attacks, by cryptographically signing DNS records. You should enable DNSSEC. For more information, see DNS Security Extensions (DNSSEC) overview.

To remediate this finding, complete the following steps:

1. Go to the Cloud DNS page in the Google Cloud console.

   Go to Cloud DNS networks

2. Locate the row with the DNS zone indicated in the finding.

3. Click the DNSSEC setting in the row and then, under DNSSEC, select On.

4. Read the dialog that appears. If satisfied, click Enable.

Learn about this finding type's supported assets and scan settings.

Egress deny rule not set

Category name in the API: EGRESS_DENY_RULE_NOT_SET

An egress deny rule is not set on a firewall.

A firewall that denies all egress network traffic prevents any unwanted outbound network connections, except those connections other firewalls explicitly authorize. For more information, see Egress cases.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. Click Create Firewall Rule.

3. Give the firewall a name and, optionally, a description.

4. Under Direction of traffic, select Egress.

5. Under Action on match, select Deny.

6. In the Targets drop-down menu, select All instances in the network.

7. In the Destination filter drop-down menu, select IP ranges, and then type 0.0.0.0/0 into the Destination IP ranges box.

8. Under Protocols and ports, select Deny all.

9. Click Disable Rule then, under Enforcement, select Enabled.

10. Click Create.

Learn about this finding type's supported assets and scan settings.

Essential contacts not configured

Category name in the API: ESSENTIAL_CONTACTS_NOT_CONFIGURED

Your organization has not designated a person or group to receive notifications from Google Cloud about important events such as attacks, vulnerabilities, and data incidents within your Google Cloud organization. We recommend that you designate as an essential contact one or more persons or groups in your business organization.

To remediate this finding, complete the following steps:

1. Go to the Essential Contacts page in the Google Cloud console.

   Go to Essential Contacts

2. Make sure the organization appears in the resource selector at the top of the page. The resource selector tells you what project, folder, or organization you are currently managing contacts for.

3. Click +Add contact. The Add a contact panel opens.

4. In the Email and Confirm Email fields, enter the email address of the contact.

5. From the Notification categories section, select the notification categories that you want the contact to receive communications for. Ensure that appropriate email addresses are configured for each of the following notification categories:

   1. Legal
   2. Security
   3. Suspension
   4. Technical

6. Click Save. Learn about this finding type's supported assets and scan settings.

Firewall not monitored

Category name in the API: FIREWALL_NOT_MONITORED

Note: The logs-based metric filter for this detector was changed on Oct 27, 2021.

Log metrics and alerts aren't configured to monitor VPC Network Firewall rule changes.

Monitoring firewall rules creation and update events gives you insight into network access changes, and can help you quickly detect suspicious activity. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

Create metric

1. Go to the Logs-based Metrics page in the Google Cloud console.

   Go to Logs-based Metrics

2. Click Create Metric.

3. Under Metric Type, select Counter.

4. Under Details:

   1. Set a Log metric name.
   2. Add a description.
   3. Set Units to 1.

5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:

     resource.type="gce_firewall_rule"
     AND (protoPayload.methodName:"compute.firewalls.insert"
     OR protoPayload.methodName:"compute.firewalls.patch"
     OR protoPayload.methodName:"compute.firewalls.delete")
   

6. Click Create Metric. You see a confirmation.

Create Alert Policy

1. In the Google Cloud console, select Logging, and then select Log-based metrics, or click the following button:

   Go to Log-based metrics

2. Under the User-defined metrics section, select the metric you created in the previous section.

3. Click More , and then click Create alert from metric.

   The New condition dialog opens with the metric and data transformation options pre-populated.

4. Click Next.
   1. Review the pre-populated settings. You might want to modify the Threshold value.
   2. Click Condition name and enter a name for the condition.
5. Click Next.

6. To add notifications to your alerting policy, click Notification channels. In the dialog, select one or more notification channels from the menu, and then click OK.

   To be notified when incidents are opened and closed, check Notify on incident closure. By default, notifications are sent only when incidents are opened.

7. Optional: Update the Incident autoclose duration. This field determines when Monitoring closes incidents in the absence of metric data.
8. Optional: Click Documentation, and then add any information that you want included in a notification message.
9. Click Alert name and enter a name for the alerting policy.
10. Click Create Policy.

Learn about this finding type's supported assets and scan settings.

Firewall rule logging disabled

Category name in the API: FIREWALL_RULE_LOGGING_DISABLED

Firewall rules logging is disabled.

Firewall rules logging lets you audit, verify, and analyze the effects of your firewall rules. It can be useful for auditing network access or providing early warning that the network is being used in an unapproved manner. The cost of logs can be significant. For more information on Firewall Rules Logging and its cost, see Using Firewall Rules Logging.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the desired firewall rule.

3. Click Edit.

4. Under Logs, select On.

5. Click Save.

Learn about this finding type's supported assets and scan settings.

Flow logs disabled

Category name in the API: FLOW_LOGS_DISABLED

There is a VPC subnetwork that has flow logs disabled.

VPC Flow Logs record a sample of network flows sent from and received by VM instances. These logs can be used for network monitoring, forensics, real-time security analysis, and expense optimization. For more information about flow logs and their cost, see Using VPC Flow Logs.

To remediate this finding, complete the following steps:

1. Go to the VPC networks page in the Google Cloud console.

   Go to VPC networks

2. In the list of networks, click the name of the desired network.

3. On the VPC network details page, click the Subnets tab.

4. In the list of subnets, click the name of the subnet indicated in the finding.

5. On the Subnet details page, click Edit.

6. Under Flow logs, select On.

Learn about this finding type's supported assets and scan settings.

Flow logs settings not recommended

Category name in the API: VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

In the configuration of a subnet in a VPC network, the VPC Flow Logs service is either off or is not configured according to CIS Benchmark 1.3 recommendations. VPC Flow Logs records a sample of network flows sent from and received by VM instances which can be used to detect threats.

Note: VPC Flow Logs can incur costs and the CIS Benchmark recommendations are not optimized for cost savings. To reduce costs, use an aggregation interval of 15 minutes and a sample rate between 5% and 10%, which provides a good balance between cost and threat detection. However, if you use these balanced settings, you will continue to receive this finding, because the balanced settings do not match the current CIS Benchmark recommendations.

For more information about VPC Flow Logs and their cost, see Using VPC Flow Logs.

To remediate this finding, complete the following steps:

1. Go to the VPC networks page in the Google Cloud console.

   Go to VPC networks

2. In the list of networks, click the name of the network.

3. On the VPC network details page, click the Subnets tab.

4. In the list of subnets, click the name of the subnet indicated in the finding.

5. On the Subnet details page, click Edit.

6. Under Flow logs, select On.

   1. Optionally, modify the configuration of the logs by clicking on the Configure logs button to expand the tab. The CIS Benchmarks recommend the following settings:
      1. Set the Aggregation Interval to 5 SEC.
      2. In the Additional fields checkbox, select the Include metadata option.
      3. Set the Sample rate to 100%.
      4. Click on the SAVE button.

Learn about this finding type's supported assets and scan settings.

Full API access

Category name in the API: FULL_API_ACCESS

A Compute Engine instance is configured to use the default service account with full access to all Google Cloud APIs.

An instance configured with the default service account scope, Allow full access to all Cloud APIs, might allow users to perform operations or API calls for which they don't have IAM permissions. For more information, see Compute Engine default service account.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. In the list of instances, click the name of the instance in the finding.

3. Click Stop if the instance is currently started.

4. After the instance stops, click Edit.

5. Under Service account, in the drop-down menu, select Compute Engine default service account.

6. Under Access scopes section, ensure that Allow full access to all Cloud APIs is not selected.

7. Click Save.

8. Click Start to start the instance.

Learn about this finding type's supported assets and scan settings.

HTTP load balancer

Category name in the API: HTTP_LOAD_BALANCER

A Compute Engine instance uses a load balancer that is configured to use a target HTTP proxy instead of a target HTTPS proxy.

To protect the integrity of your data and prevent intruders from tampering with your communications, configure your HTTP(S) load balancers to allow only HTTPS traffic. For more information, see External HTTP(S) Load Balancing overview.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the Target proxies page in the Google Cloud console.

   Go to Target proxies

2. In the list of target proxies, click the name of the target proxy in the finding.

3. Click the link under the URL map.

4. Click Edit.

5. Click Frontend configuration.

6. Delete all Frontend IP and port configurations that allow HTTP traffic and create new ones that allow HTTPS traffic.

Learn about this finding type's supported assets and scan settings.

Integrity monitoring disabled

Category name in the API: INTEGRITY_MONITORING_DISABLED

Integrity monitoring is disabled on a GKE cluster.

Integrity monitoring lets you monitor and verify the runtime boot integrity of your shielded nodes using Monitoring. This lets you respond to integrity failures and prevent compromised nodes from being deployed into the cluster.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

Once a node is provisioned, it can't be updated to enable integrity monitoring. You must create a new node pool with integrity monitoring enabled.

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Click on the name of the cluster in the finding.

3. Click on Add Node Pool.

4. Under the Security tab, ensure the Enable integrity monitoring is enabled.

5. Click Create.

6. To migrate your workloads from the existing non-conforming node pools to the new node pools, see Migrating workloads to different machine types.

7. After your workloads have been moved, delete the original non-conforming node pool.

   1. On the Kubernetes cluster page, in the Node pools menu, click the name of the node pool you want to delete.
   2. Click Remove node pool.

Learn about this finding type's supported assets and scan settings.

Intranode visibility disabled

Category name in the API: INTRANODE_VISIBILITY_DISABLED

Intranode visibility is disabled for a GKE cluster.

Enabling intranode visibility makes your intranode Pod-to-Pod traffic visible to the networking fabric. With this feature, you can use VPC flow logging or other VPC features to monitor or control intranode traffic. To get logs, you need to enable VPC flow logs in the selected subnetwork. For more information, see Using VPC flow logs.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

Once a node is provisioned, it can't be updated to enable integrity monitoring. You must create a new node pool with integrity monitoring enabled.

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. In the Networking section, click on the edit icon () in the Intranode visibility row.

   If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

3. In the dialog, select Enable Intranode visibility.

4. Click Save Changes.

Learn about this finding type's supported assets and scan settings.

IP alias disabled

Category name in the API: IP_ALIAS_DISABLED

A GKE cluster was created with alias IP ranges disabled.

When you enable alias IP ranges, GKE clusters allocate IP addresses from a known CIDR block, so your cluster is scalable and interacts better with Google Cloud products and entities. For more information, see Alias IP ranges overview.

To remediate this finding, complete the following steps:

You cannot migrate an existing cluster to use alias IPs. To create a new cluster with alias IPs enabled, do the following:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Click Create.

3. From the navigation pane, under Cluster, click Networking.

4. Under Advanced networking options, select Enable VPC-native traffic routing (uses alias IP).

5. Click Create.

   Note: A cluster cannot be modified while it is reconfiguring itself.

Learn about this finding type's supported assets and scan settings.

IP forwarding enabled

Category name in the API: IP_FORWARDING_ENABLED

IP forwarding is enabled on Compute Engine instances.

Prevent data loss or information disclosure by disabling IP forwarding of data packets for your VMs.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. In the list of instances, check the box next to the name of the instance in the finding.

3. Click Delete.

4. Select Create Instance to create a new instance to replace the one you deleted.

5. To ensure IP forwarding is disabled, click Management, disks, networking, SSH keys, and then click Networking.

6. Under Network interfaces, click Edit.

7. Under IP forwarding, in the drop-down menu, ensure that Off is selected.

8. Specify any other instance parameters, and then click Create. For more information, see Creating and starting a VM instance.

Learn about this finding type's supported assets and scan settings.

KMS key not rotated

Category name in the API: KMS_KEY_NOT_ROTATED

Rotation isn't configured on a Cloud KMS encryption key.

Rotating your encryption keys regularly provides protection in case a key gets compromised and limits the number of encrypted messages available to cryptanalysis for a specific key version. For more information, see Key rotation.

To remediate this finding, complete the following steps:

1. Go to the Cloud KMS keys page in the Google Cloud console.

   Go to Cloud KMS keys

2. Click the name of the key ring indicated in the finding.

3. Click the name of the key indicated in the finding.

4. Click Edit Rotation Period.

5. Set the rotation period to a maximum of 90 days.

6. Click Save.

Learn about this finding type's supported assets and scan settings.

KMS project has owner

Category name in the API: KMS_PROJECT_HAS_OWNER

A user has roles/Owner permissions on a project that has cryptographic keys. For more information, see Permissions and roles.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the IAM page in the Google Cloud console.

   Go IAM page

2. If necessary, select the project in the finding.

3. For each principal assigned the Owner role:

   1. Click Edit.
   2. In the Edit permissions panel, next to the Owner role, click Delete.
   3. Click Save.

Learn about this finding type's supported assets and scan settings.

KMS public key

Category name in the API: KMS_PUBLIC_KEY

A Cloud KMS Cryptokey or Cloud KMS Key Ring is public and accessible to anyone on the internet. For more information, see Using IAM with Cloud KMS.

To remediate this finding, if it is related to a Cryptokey:

1. Go to the Cryptographic Keys page in the Google Cloud console.

   Cryptographic Keys

2. Under Name, select the key ring that contains the cryptographic key related to the Security Health Analytics finding.

3. On the Key ring details page that loads, select the checkbox next to the cryptographic key.

4. If the INFO PANEL is not displayed, click the SHOW INFO PANEL button.

5. Use the filter box preceding Role / Principal to search principals for allUsers and allAuthenticatedUsers, and click Delete to remove access for these principals.

To remediate this finding, if it is related to a Key Ring:

1. Go to the Cryptographic Keys page in the Google Cloud console.

   Cryptographic Keys

2. Find the row with the key ring in the finding and select the checkbox.

3. If the INFO PANEL is not displayed, click the SHOW INFO PANEL button.

4. Use the filter box preceding Role / Principal to search principals for allUsers and allAuthenticatedUsers, and click Delete to remove access for these principals.

Learn about this finding type's supported assets and scan settings.

KMS role separation

Category name in the API: KMS_ROLE_SEPARATION

This finding isn't available for project-level activations.

One or more principals have multiple Cloud KMS permissions assigned. We recommend that no account simultaneously has Cloud KMS Admin along with other Cloud KMS permissions. For more information, see Permissions and roles.

To remediate this finding, complete the following steps:

1. Go to the IAM page in the Google Cloud console.

   Go to IAM

2. For each principal listed in the finding, do the following:

   1. Check whether the role was inherited from a folder or organization resource by looking at the Inheritance column. If the column contains a link to a parent resource, click on the link to go to the parent resource's IAM page.
   2. Click Edit next to a principal.
   3. To remove permissions, click Delete next to Cloud KMS Admin. If you want to remove all permissions for the principal, click Delete next to all other permissions.

3. Click Save.

Learn about this finding type's supported assets and scan settings.

Legacy authorization enabled

Category name in the API: LEGACY_AUTHORIZATION_ENABLED

Legacy Authorization is enabled on GKE clusters.

In Kubernetes, role-based access control (RBAC) lets you define roles with rules containing a set of permissions, and grant permissions at the cluster and namespace level. This feature provides better security by ensuring that users only have access to specific resources. Consider disabling legacy attribute-based access control (ABAC).

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Select the cluster listed in the Security Health Analytics finding.

3. Click Edit.

   If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

4. On the Legacy Authorization drop-down list, select Disabled.

5. Click Save.

Learn about this finding type's supported assets and scan settings.

Legacy metadata enabled

Category name in the API: LEGACY_METADATA_ENABLED

Legacy metadata is enabled on GKE clusters.

Compute Engine's instance metadata server exposes legacy /0.1/ and /v1beta1/ endpoints, which do not enforce metadata query headers. This is a feature in the /v1/ APIs that makes it more difficult for a potential attacker to retrieve instance metadata. Unless required, we recommend you disable these legacy /0.1/ and /v1beta1/ APIs.

For more information, see Disabling and transitioning from legacy metadata APIs.

To remediate this finding, complete the following steps:

You can only disable legacy metadata APIs when creating a new cluster or when adding a new node pool to an existing cluster. To update an existing cluster and disable legacy metadata APIs, see Migrating workloads to different machine types.

Learn about this finding type's supported assets and scan settings.

Legacy network

Category name in the API: LEGACY_NETWORK

A legacy network exists in a project.

Legacy networks are not recommended because many new Google Cloud security features are not supported in legacy networks. Instead, use VPC networks. For more information, see Legacy networks.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the VPC networks page in the Google Cloud console.

   Go to VPC networks

2. To create a new non-legacy network, click Create Network.

3. Return to the VPC networks page.

4. In the list of networks, click legacy_network.

5. In the VPC network details page, click Delete VPC Network.

Learn about this finding type's supported assets and scan settings.

Load balancer logging disabled

Category name in the API: LOAD_BALANCER_LOGGING_DISABLED

Logging is disabled for the backend service in a load balancer.

Enabling logging for a load balancer allows you to view HTTP(S) network traffic for your web applications. For more information, see Load balancer.

Caution: A high sample rate can result in higher storage costs for the log file. You need to strike a balance between the sample rate and the potential storage costs that is right for your business.

To remediate this finding, complete the following steps:

1. Go to the Cloud Load Balancing page in the Google Cloud console.

   Go to Cloud Load Balancing

2. Click the name of your load balancer.

3. Click Edit .

4. Click Backend configuration.

5. In the Backend configuration page, click .

6. In the Logging section, select Enable logging and choose the best sample rate for your project.

7. To finish editing the backend service, click Update.

8. To finish editing the load balancer, click Update.

Learn about this finding type's supported assets and scan settings.

Locked retention policy not set

Category name in the API: LOCKED_RETENTION_POLICY_NOT_SET

A locked retention policy is not set for logs.

A locked retention policy prevents logs from being overwritten and the log bucket from being deleted. For more information, see Retention policies and retention policy locks.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the Storage Browser page in the Google Cloud console.

   Go to Storage Browser

2. Select the bucket listed in the Security Health Analytics finding.

3. On the Bucket details page, click the Retention tab.

4. If a retention policy has not been set, click Set Retention Policy.

5. Enter a retention period.

6. Click Save. The retention policy is shown in the Retention tab.

7. Click Lock to ensure the retention period is not shortened or removed.

   Caution: Locking a retention policy is an irreversible act and can only be undone by deleting the entire bucket. For more information, see Retention policies and retention policy locks.

Learn about this finding type's supported assets and scan settings.

Log not exported

Category name in the API: LOG_NOT_EXPORTED

A resource doesn't have an appropriate log sink configured.

Cloud Logging helps you quickly find the root cause of issues in your system and applications. However, most logs are only retained for 30 days by default. Export copies of all log entries to extend the storage period. For more information, see Overview of log exports.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the Log Router page in the Google Cloud console.

   Go to Log Router

2. Click Create Sink.

3. To ensure that all logs are exported, leave the inclusion and exclusion filters empty.

4. Click Create Sink.

   Note: These instructions create a sink at the project level. Sinks can also be created at the folder or organization level. For more information, see Exporting logs with the Google Cloud console.

Learn about this finding type's supported assets and scan settings.

Master authorized networks disabled

Category name in the API: MASTER_AUTHORIZED_NETWORKS_DISABLED

Control Plane Authorized Networks is not enabled on GKE clusters.

Control Plane Authorized Networks improves security for your container cluster by blocking specified IP addresses from accessing your cluster's control plane. For more information, see Adding authorized networks for control plane access.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Select the cluster listed in the Security Health Analytics finding.

3. Click Edit.

   If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

4. On the Control Plane Authorized Networks drop-down list, select Enabled.

5. Click Add authorized network.

6. Specify the authorized networks you want to use.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

MFA not enforced

Category name in the API: MFA_NOT_ENFORCED

This finding isn't available for project-level activations.

Multi-factor authentication, specifically 2-Step Verification (2SV), is disabled for some users in your organization.

Multi-factor authentication is used to protect accounts from unauthorized access and is the most important tool for protecting your organization against compromised login credentials. For more information, see Protect your business with 2-Step Verification.

To remediate this finding, complete the following steps:

1. Go to the Admin console page in the Google Cloud console.

   Go to Admin console

2. Enforce 2-Step Verification for all organizational units.

Suppress findings of this type

To suppress finding of this type, define a mute rule that automatically mutes future findings of this type. For more information, see Mute findings in Security Command Center.

Although it is not a recommended way to suppress findings, you can also add dedicated security marks to assets so that Security Health Analytics detectors don't create security findings for those assets.

• To prevent this finding from being activated again, add the security mark allow_mfa_not_enforced with a value of true to the asset.
• To ignore potential violations for specific organizational units, add the excluded_orgunits security mark to the asset with a comma-separated list of organizational unit paths in the value field. For example, excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA.

Learn about this finding type's supported assets and scan settings.

Network not monitored

Category name in the API: NETWORK_NOT_MONITORED

Note: The logs-based metric filter for this detector was changed on Oct 27, 2021.

Log metrics and alerts aren't configured to monitor VPC network changes.

To detect incorrect or unauthorized changes to your network setup, monitor VPC network changes. For more information, see Overview of logs- based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

Create metric

1. Go to the Logs-based Metrics page in the Google Cloud console.

   Go to Logs-based Metrics

2. Click Create Metric.

3. Under Metric Type, select Counter.

4. Under Details:

   1. Set a Log metric name.
   2. Add a description.
   3. Set Units to 1.

5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:

     resource.type="gce_network"
     AND (protoPayload.methodName:"compute.networks.insert"
     OR protoPayload.methodName:"compute.networks.patch"
     OR protoPayload.methodName:"compute.networks.delete"
     OR protoPayload.methodName:"compute.networks.removePeering"
     OR protoPayload.methodName:"compute.networks.addPeering")
   

6. Click Create Metric. You see a confirmation.

Create Alert Policy

1. In the Google Cloud console, select Logging, and then select Log-based metrics, or click the following button:

   Go to Log-based metrics

2. Under the User-defined metrics section, select the metric you created in the previous section.

3. Click More , and then click Create alert from metric.

   The New condition dialog opens with the metric and data transformation options pre-populated.

4. Click Next.
   1. Review the pre-populated settings. You might want to modify the Threshold value.
   2. Click Condition name and enter a name for the condition.
5. Click Next.

6. To add notifications to your alerting policy, click Notification channels. In the dialog, select one or more notification channels from the menu, and then click OK.

   To be notified when incidents are opened and closed, check Notify on incident closure. By default, notifications are sent only when incidents are opened.

7. Optional: Update the Incident autoclose duration. This field determines when Monitoring closes incidents in the absence of metric data.
8. Optional: Click Documentation, and then add any information that you want included in a notification message.
9. Click Alert name and enter a name for the alerting policy.
10. Click Create Policy.

Learn about this finding type's supported assets and scan settings.

Network policy disabled

Category name in the API: NETWORK_POLICY_DISABLED

Network policy is disabled on GKE clusters.

By default, pod to pod communication is open. Open communication allows pods to connect directly across nodes, with or without network address translation. A NetworkPolicy resource is like a pod-level firewall that restricts connections between pods, unless the NetworkPolicy resource explicitly allows the connection. Learn how to define a network policy.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Click the name of the cluster listed in the Security Health Analytics finding.

3. Under Networking, in the row for Calico Kubernetes Network policy, click Edit.

   If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

4. In the dialog, select Enable Calico Kubernetes network policy for control plane and Enable Calico Kubernetes network policy for nodes.

5. Click Save Changes.

Learn about this finding type's supported assets and scan settings.

Nodepool boot CMEK disabled

Category name in the API: NODEPOOL_BOOT_CMEK_DISABLED

Boot disks in this node pool are not encrypted with customer-managed encryption keys (CMEK). CMEK allows the user to configure the default encryption keys for boot disks in a node pool.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. In the list of clusters, click the name of the cluster in the finding.

3. Click the Nodes tab.

4. For each default-pool node pool, click Delete .

5. When prompted to confirm, click Delete.

6. To create new node pools using CMEK, see Using customer-managed encryption keys (CMEK). CMEK incurs additional costs related to Cloud KMS.

Learn about this finding type's supported assets and scan settings.

Nodepool secure boot disabled

Category name in the API: NODEPOOL_SECURE_BOOT_DISABLED

Secure boot is disabled for a GKE cluster.

Enable Secure Boot for Shielded GKE Nodes to verify the digital signatures of node boot components. For more information, see Secure Boot.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

Once a Node pool is provisioned, it can't be updated to enable Secure Boot. You must create a new Node pool with Secure Boot enabled.

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Click on the name of the cluster in the finding.

3. Click on Add Node Pool.

4. In the Node pools menu, do the following:

   1. Click the name of the new Node pool to expand the tab.
   2. Select Security, and then, under Shielded options, select Enable secure boot.
   3. Click Create.
   4. To migrate your workloads from the existing non-conforming node pools to the new node pools, see Migrating workloads to different machine types.
   5. After your workloads have been moved, delete the original non-conforming node pool.

Learn about this finding type's supported assets and scan settings.

Non org IAM member

Category name in the API: NON_ORG_IAM_MEMBER

A user outside of your organization or project has IAM permissions on a project or organization. Learn more about IAM permissions.

To remediate this finding, complete the following steps:

1. Go to the IAM page in the Google Cloud console.

   Go to IAM

2. Select the checkbox next to users outside your organization or project.

3. Click Remove.

Learn about this finding type's supported assets and scan settings.

Object versioning disabled

Category name in the API: OBJECT_VERSIONING_DISABLED

Object versioning isn't enabled on a storage bucket where sinks are configured.

To support the retrieval of objects that are deleted or overwritten, Cloud Storage offers the Object Versioning feature. Enable Object Versioning to protect your Cloud Storage data from being overwritten or accidentally deleted. Learn how to Enable Object Versioning.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, use the gsutil versioning set on command with the appropriate value:

    gsutil versioning set on gs://finding.assetDisplayName

Replace finding.assetDisplayName with the name of the relevant bucket.

Learn about this finding type's supported assets and scan settings.

Open Cassandra port

Category name in the API: OPEN_CASSANDRA_PORT

Firewall rules that allow any IP address to connect to Cassandra ports might expose your Cassandra services to attackers. For more information, see VPC firewall rules overview.

The Cassandra service ports are:

• TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open ciscosecure websm port

Category name in the API: OPEN_CISCOSECURE_WEBSM_PORT

Firewall rules that allow any IP address to connect to CiscoSecure/WebSM ports might expose your CiscoSecure/WebSM services to attackers. For more information, see VPC firewall rules overview.

The CiscoSecure/WebSM service ports are:

• TCP - 9090

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open directory services port

Category name in the API: OPEN_DIRECTORY_SERVICES_PORT

Firewall rules that allow any IP address to connect to Directory ports might expose your Directory services to attackers. For more information, see VPC firewall rules overview.

The Directory service ports are:

• TCP - 445
• UDP - 445

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open DNS port

Category name in the API: OPEN_DNS_PORT

Firewall rules that allow any IP address to connect to DNS ports might expose your DNS services to attackers. For more information, see VPC firewall rules overview.

The DNS service ports are:

• TCP - 53
• UDP - 53

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open Elasticsearch port

Category name in the API: OPEN_ELASTICSEARCH_PORT

Firewall rules that allow any IP address to connect to Elasticsearch ports might expose your Elasticsearch services to attackers. For more information, see VPC firewall rules overview.

The Elasticsearch service ports are:

• TCP - 9200, 9300

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open firewall

Category name in the API: OPEN_FIREWALL

Firewall rules that allow connections from all IP addresses, like 0.0.0.0/0, or from all ports can unnecessarily expose resources to attacks from unintended sources. These rules should be removed or scoped explicitly to the intended source IP ranges or ports. For example, in applications intended to be public, consider restricting allowed ports to those needed for the application, like 80 and 443. If your application needs to allow connections from all IP addresses or ports, consider adding the asset to an allowlist. Learn more about Updating firewall rules.

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall rules page in the Google Cloud console.

   Go to Firewall rules

2. Click the firewall rule listed in the Security Health Analytics finding, and then click Edit.

3. Under Source IP ranges, edit the IP values to restrict the range of IPs that is allowed.

4. Under Protocols and ports, select Specified protocols and ports, select the allowed protocols, and enter ports that are allowed.

5. Click Save.

Learn about this finding type's supported assets and scan settings.

Open FTP port

Category name in the API: OPEN_FTP_PORT

Firewall rules that allow any IP address to connect to FTP ports might expose your FTP services to attackers. For more information, see VPC firewall rules overview.

The FTP service ports are:

• TCP - 21

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open group IAM member

Category name in the API: OPEN_GROUP_IAM_MEMBER

One or more principals that have access to an organization, project, or folder are Google Groups accounts that can be joined without approval.

Google Cloud customers can use Google Groups to manage roles and permissions for members in their organizations, or apply access policies to collections of users. Instead of granting roles directly to members, administrators can grant roles and permissions to Google Groups, and then add members to specific groups. Group members inherit all of a group's roles and permissions, which lets members access specific resources and services.

If an open Google Groups account is used as a principal in an IAM binding, anyone can inherit the associated role just by joining the group directly or indirectly (through a subgroup). We recommend revoking the roles of the open groups or restricting access to those groups.

To remediate this finding, perform one of the following procedures.

Remove the group from the IAM policy

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

1. Go to the IAM page in the Google Cloud console.

   Go IAM

2. If necessary, select the project, folder, or organization in the finding.

3. Revoke the role of each open group identified in the finding.

Restrict access to the open groups

1. Sign in to Google Groups.
2. Update the settings of each open group, and its subgroups, to specify who can join the group and who must approve them.

Learn about this finding type's supported assets and scan settings.

Open HTTP port

Category name in the API: OPEN_HTTP_PORT

Firewall rules that allow any IP address to connect to HTTP ports might expose your HTTP services to attackers. For more information, see VPC firewall rules overview.

The HTTP service ports are:

• TCP - 80

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open LDAP port

Category name in the API: OPEN_LDAP_PORT

Firewall rules that allow any IP address to connect to LDAP ports might expose your LDAP services to attackers. For more information, see VPC firewall rules overview.

The LDAP service ports are:

• TCP - 389, 636
• UDP - 389

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open Memcached port

Category name in the API: OPEN_MEMCACHED_PORT

Firewall rules that allow any IP address to connect to Memcached ports might expose your Memcached services to attackers. For more information, see VPC firewall rules overview.

The Memcached service ports are:

• TCP - 11211, 11214, 11215
• UDP - 11211, 11214, 11215

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open MongoDB port

Category name in the API: OPEN_MONGODB_PORT

Firewall rules that allow any IP address to connect to MongoDB ports might expose your MongoDB services to attackers. For more information, see VPC firewall rules overview.

The MongoDB service ports are:

• TCP - 27017, 27018, 27019

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open MySQL port

Category name in the API: OPEN_MYSQL_PORT

Firewall rules that allow any IP address to connect to MySQL ports might expose your MySQL services to attackers. For more information, see VPC firewall rules overview.

The MySQL service ports are:

• TCP - 3306

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open NetBIOS port

Category name in the API: `OPEN_NETBIOS_PORT

Firewall rules that allow any IP address to connect to NetBIOS ports might expose your NetBIOS services to attackers. For more information, see VPC firewall rules overview.

The NetBIOS service ports are:

• TCP - 137, 138, 139
• UDP - 137, 138, 139

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open OracleDB port

Category name in the API: OPEN_ORACLEDB_PORT

Firewall rules that allow any IP address to connect to OracleDB ports might expose your OracleDB services to attackers. SeFor more information, seee VPC firewall rules overview.

The OracleDB service ports are:

• TCP - 1521, 2483, 2484
• UDP - 2483, 2484

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open POP3 port

Category name in the API: OPEN_POP3_PORT

Firewall rules that allow any IP address to connect to POP3 ports might expose your POP3 services to attackers. For more information, see VPC firewall rules overview.

The POP3 service ports are:

• TCP - 110

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open PostgreSQL port

Category name in the API: OPEN_POSTGRESQL_PORT

Firewall rules that allow any IP address to connect to PostgreSQL ports might expose your PostgreSQL services to attackers. For more information, see VPC firewall rules overview.

The PostgreSQL service ports are:

• TCP - 5432
• UDP - 5432

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open RDP port

Category name in the API: OPEN_RDP_PORT

Firewall rules that allow any IP address to connect to RDP ports might expose your RDP services to attackers. For more information, see VPC firewall rules overview.

The RDP service ports are:

• TCP - 3389
• UDP - 3389

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open Redis port

Category name in the API: OPEN_REDIS_PORT

Firewall rules that allow any IP address to connect to Redis ports might expose your Redis services to attackers. For more information, see VPC firewall rules overview.

The Redis service ports are:

• TCP - 6379

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open SMTP port

Category name in the API: OPEN_SMTP_PORT

Firewall rules that allow any IP address to connect to SMTP ports might expose your SMTP services to attackers. For more information, see VPC firewall rules overview.

The SMTP service ports are:

• TCP - 25

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open SSH port

Category name in the API: OPEN_SSH_PORT

Firewall rules that allow any IP address to connect to SSH ports might expose your SSH services to attackers. For more information, see VPC firewall rules overview.

The SSH service ports are:

• SCTP - 22
• TCP - 22

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Open Telnet port

Category name in the API: OPEN_TELNET_PORT

Firewall rules that allow any IP address to connect to Telnet ports might expose your Telnet services to attackers. For more information, see VPC firewall rules overview.

The Telnet service ports are:

• TCP - 23

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

To remediate this finding, complete the following steps:

1. Go to the Firewall page in the Google Cloud console.

   Go to Firewall

2. In the list of firewall rules, click the name of the firewall rule in the finding.

3. Click Edit.

4. Under Source IP ranges, delete 0.0.0.0/0.

5. Add specific IP addresses or IP ranges that you want to let connect to the instance.

6. Add specific protocols and ports you want to open on your instance.

7. Click Save.

Learn about this finding type's supported assets and scan settings.

Org policy Confidential VM policy

Category name in the API: ORG_POLICY_CONFIDENTIAL_VM_POLICY

A Compute Engine resource is out of compliance with the constraints/compute.restrictNonConfidentialComputing organization policy. For more information about this org policy constraint, see Enforcing organization policy constraints.

Your organization requires this VM to have the Confidential VM service enabled. VMs that don't have this service enabled will not use runtime memory encryption, exposing them to runtime memory attacks.

Note: Confidential VM incurs additional costs on top of Compute Engine pricing. For more information, see Pricing.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. In the list of instances, click the name of the instance in the finding.

3. If the VM doesn't require the Confidential VM service, move it to a new folder or project.

4. If the VM requires Confidential VM, click Delete.

5. To create a new instance with Confidential VM enabled, see Quickstart: Creating a Confidential VM instance.

Learn about this finding type's supported assets and scan settings.

Org policy location restriction

Category name in the API: ORG_POLICY_LOCATION_RESTRICTION

The Organization Policy gcp.resourceLocations constraint lets you restrict the creation of new resources to Cloud Regions you select. For more information, see Restricting resource locations.

Note: Resource location constraints are not retroactively enforced, so if constraint values change, existing resources are not altered. ORG_POLICY_LOCATION_RESTRICTION findings might be generated if existing resource locations violate new constraints.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

The ORG_POLICY_LOCATION_RESTRICTION detector covers many resource types and remediation instructions are different for each resource. The general approach to remediate location violations includes the following:

1. Copy, move, or back up the out-of-region resource or its data into a resource that is in-region. Read the documentation for individual services to get instructions on moving resources.
2. Delete the original out-of-region resource or its data.

This approach is not possible for all resource types. For guidance, consult the customized recommendations that are provided in the finding.

Additional considerations

When remediating this finding, consider the following.

Managed resources

The lifecycles of resources are sometimes managed and controlled by other resources. For example, a managed Compute Engine instance group creates and destroys Compute Engine instances in accordance with the instance group's autoscaling policy. If managed and managing resources are in-scope for location enforcement, both might be flagged as violating the Organization Policy. Remediation of findings for managed resources should be done on the managing resource to ensure operational stability.

Resources in-use

Certain resources are used by other resources. For example, a Compute Engine disk that is attached to a running Compute Engine instance is considered to be in-use by the instance. If the resource in-use violates the location Organization Policy, you need to ensure that the resource is not in-use before addressing the location violation.

Learn about this finding type's supported assets and scan settings.

OS login disabled

Category name in the API: OS_LOGIN_DISABLED

OS Login is disabled on this Compute Engine instance.

OS Login enables centralized SSH key management with IAM, and it disables metadata-based SSH key configuration on all instances in a project. Learn how to set up and configure OS Login.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

1. Go to the Metadata page in the Google Cloud console.

   Go to Metadata

2. Click Edit, and then click Add item.

3. Add an item with key enable-oslogin and value TRUE.

Learn about this finding type's supported assets and scan settings.

Over privileged account

Category name in the API: OVER_PRIVILEGED_ACCOUNT

A GKE node is using the Compute Engine default service node, which has broad access by default and might be over-privileged for running your GKE cluster.

To remediate this finding, complete the following steps:

Follow the instructions to Use least privilege Google service accounts.

Learn about this finding type's supported assets and scan settings.

Over privileged scopes

Category name in the API: OVER_PRIVILEGED_SCOPES

A node service account has broad access scopes.

Access scopes are the legacy method of specifying permissions for your instance. To reduce the possibility of a privilege escalation in an attack, create and use a minimally privileged service account to run your GKE cluster.

To remediate this finding, follow the instructions to Use least privilege Google service accounts.

Learn about this finding type's supported assets and scan settings.

Over privileged service account user

Category name in the API: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

A user has the iam.serviceAccountUser or iam.serviceAccountTokenCreator roles at the project, folder, or organization level, instead of for a specific service account.

Granting those roles to a user for a project, folder, or organization gives the user access to all existing and future service accounts at that scope. This situation can result in unintended escalation of privileges. For more information, see Service account permissions.

To remediate this finding, complete the following steps:

1. Go to the IAM page in the Google Cloud console.

   Go IAM page

2. If necessary, select the project, folder, or organization in the finding.

3. For each principal assigned roles/iam.serviceAccountUser or roles/iam.serviceAccountTokenCreator, do the following:

   1. Click Edit.
   2. In the Edit permissions panel, next to the roles, click Delete.
   3. Click Save.

4. Follow this guide to grant individual users permission to impersonate a single service account. You need to follow the guide for each service account you want to allow chosen users to impersonate.

Learn about this finding type's supported assets and scan settings.

Owner not monitored

Category name in the API: OWNER_NOT_MONITORED

Log metrics and alerts aren't configured to monitor Project Ownership assignments or changes.

The IAM Owner role has the highest level of privilege on a project. To secure your resources, set up alerts to get notified when new owners are added or removed. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

Create metric

1. Go to the Logs-based Metrics page in the Google Cloud console.

   Go to Logs-based Metrics

2. Click Create Metric.

3. Under Metric Type, select Counter.

4. Under Details:

   1. Set a Log metric name.
   2. Add a description.
   3. Set Units to 1.

5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:

     (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
     AND (ProjectOwnership OR projectOwnerInvitee)
     OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
     AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
     OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
     AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
   

6. Click Create Metric. You see a confirmation.

Create Alert Policy

1. In the Google Cloud console, select Logging, and then select Log-based metrics, or click the following button:

   Go to Log-based metrics

2. Under the User-defined metrics section, select the metric you created in the previous section.

3. Click More , and then click Create alert from metric.

   The New condition dialog opens with the metric and data transformation options pre-populated.

4. Click Next.
   1. Review the pre-populated settings. You might want to modify the Threshold value.
   2. Click Condition name and enter a name for the condition.
5. Click Next.

6. To add notifications to your alerting policy, click Notification channels. In the dialog, select one or more notification channels from the menu, and then click OK.

   To be notified when incidents are opened and closed, check Notify on incident closure. By default, notifications are sent only when incidents are opened.

7. Optional: Update the Incident autoclose duration. This field determines when Monitoring closes incidents in the absence of metric data.
8. Optional: Click Documentation, and then add any information that you want included in a notification message.
9. Click Alert name and enter a name for the alerting policy.
10. Click Create Policy.

Learn about this finding type's supported assets and scan settings.

Pod security policy disabled

Category name in the API: POD_SECURITY_POLICY_DISABLED

The PodSecurityPolicy is disabled on a GKE cluster.

A PodSecurityPolicy is an admission controller resource that validates requests to create and update pods on a cluster. Clusters won't accept pods that don't meet the conditions defined in the PodSecurityPolicy.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, define and authorize PodSecurityPolicies, and enable the PodSecurityPolicy controller. For instructions, see Using PodSecurityPolicies.

Learn about this finding type's supported assets and scan settings.

Primitive roles used

Category name in the API: PRIMITIVE_ROLES_USED

A user has one of the following IAM basic roles: roles/owner, roles/editor, or roles/viewer. These roles are too permissive and shouldn't be used. Instead, they should be assigned per project only.

For more information, see Understanding roles.

To remediate this finding, complete the following steps:

1. Go to the IAM policy page in the Google Cloud console.

   Go to IAM policy

2. For each user assigned a primitive role, consider using more granular roles instead.

Learn about this finding type's supported assets and scan settings.

Private cluster disabled

Category name in the API: PRIVATE_CLUSTER_DISABLED

A GKE cluster has a private cluster disabled.

Private clusters allow nodes to only have private IP addresses. This feature limits outbound internet access for nodes. If a cluster node doesn't have a public IP address, it isn't discoverable or exposed to the public internet. You can still route traffic to a node by using an internal load balancer. For more information, see Private clusters.

You can't make an existing cluster private. To remediate this finding, create a new private cluster:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. Click Create Cluster.

3. In the navigation menu, under Cluster, select Networking.

4. Select the radio button for Private cluster.

5. Under Advanced networking options, select the checkbox for Enable VPC-native traffic routing (uses alias IP).

6. Click Create.

Learn about this finding type's supported assets and scan settings.

Private Google access disabled

Category name in the API: PRIVATE_GOOGLE_ACCESS_DISABLED

There are private subnets without access to Google public APIs.

Private Google Access enables VM instances with only internal (private) IP addresses to reach the public IP addresses of Google APIs and services.

For more information, see Configuring Google Private Access.

To remediate this finding, complete the following steps:

1. Go to the VPC networks page in the Google Cloud console.

   Go to VPC networks

2. In the list of networks, click the name of the desired network.

3. On the VPC network details page, click the Subnets tab.

4. In the list of subnets, click the name of the subnet associated with the Kubernetes cluster in the finding.

5. On the Subnet details page, click Edit .

6. Under Private Google Access, select On.

7. Click Save.

8. To remove public (external) IPs from VM instances whose only external traffic is to Google APIs, see Unassigning a static external IP address.

Learn about this finding type's supported assets and scan settings.

Public bucket ACL

Category name in the API: PUBLIC_BUCKET_ACL

A bucket is public and anyone on the internet can access it.

For more information, see Overview of access control.

To remediate this finding, complete the following steps:

1. Go to the Storage Browser page in the Google Cloud console.

   Go to Storage Browser

2. Select the bucket listed in the Security Health Analytics finding.

3. On the Bucket details page, click the Permissions tab.

4. Next to View by, click Roles.

5. In the Filter box, search for allUsers and allAuthenticatedUsers.

6. Click Delete to remove all IAM permissions granted to allUsers and allAuthenticatedUsers.

Learn about this finding type's supported assets and scan settings.

Public Compute image

Category name in the API: PUBLIC_COMPUTE_IMAGE

A Compute Engine image is public and anyone on the internet can access it. allUsers represents anyone on the internet and allAuthenticatedUsers represents anyone who is authenticated with a Google account; neither is constrained to users within your organization.

Compute Engine images might contain sensitive information like encryption keys or licensed software. Such sensitive information should not be publicly accessible. If you intended to make this Compute Engine image public, ensure that it does not contain any sensitive information.

For more information, see Access control overview.

To remediate this finding, complete the following steps:

1. Go to the Compute Engine images page in the Google Cloud console.

   Go to Compute Engine images

2. Select the box next to the public-image image, and then click Show Info Panel.

3. In the Filter box, search principals for allUsers and allAuthenticatedUsers.

4. Expand the role for which you want to remove users.

5. Click Delete to remove a user from that role.

Learn about this finding type's supported assets and scan settings.

Public dataset

Category name in the API: PUBLIC_DATASET

A BigQuery dataset is public and accessible to anyone on the internet. The IAM principal allUsers represents anyone on the internet and allAuthenticatedUsers represents anyone who is logged into a Google service; neither is constrained to users within your organization.

For more information, see Controlling access to datasets.

To remediate this finding, complete the following steps:

1. Go to the BigQuery Explorer page in the Google Cloud console.

   Go to BigQuery Dataset

2. In the list of datasets, click on the name of the dataset that is identified in the finding. The Dataset info panel opens.

3. Near the top of the Dataset info panel, click SHARING.

4. In the drop-down menu, click on Permissions.

5. In the Dataset Permissions panel, enter allUsers and allAuthenticatedUsers, and remove access for these principals.

Learn about this finding type's supported assets and scan settings.

Public IP address

Category name in the API: PUBLIC_IP_ADDRESS

A Compute Engine instance has a public IP address.

To reduce your organizations' attack surface, avoid assigning public IP addresses to your VMs. Stopped instances might still be flagged with a Public IP finding, for example, if the network interfaces are configured to assign an ephemeral public IP on start. Ensure the network configurations for stopped instances do not include external access.

For more information, see Securely connecting to VM instances.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. In the list of instances, check the box next to the name of the instance in the finding.

3. Click Edit.

4. For each interface under Network interfaces, click Edit and set External IP to None.

5. Click Done, and then click Save.

Learn about this finding type's supported assets and scan settings.

Public log bucket

Category name in the API: PUBLIC_LOG_BUCKET

This finding isn't available for project-level activations.

A storage bucket is public and used as a log sink, meaning that anyone on the internet can access logs stored in this bucket. allUsers represents anyone on the internet and allAuthenticatedUsers represents anyone who is logged into a Google service; neither is constrained to users within your organization.

For more information, see Overview of access control.

To remediate this finding, complete the following steps:

1. Go to the Cloud Storage browser page in the Google Cloud console.

   Go to Cloud Storage browser

2. In the list of buckets, click the name of the bucket indicated in the finding.

3. Click the Permissions tab.

4. Remove allUsers and allAuthenticatedUsers from the list of principals.

Learn about this finding type's supported assets and scan settings.

Public SQL instance

Category name in the API: PUBLIC_SQL_INSTANCE

Your SQL instance has 0.0.0.0/0 as an allowed network. This occurrence means that any IPv4 client can pass the network firewall and make login attempts to your instance, including clients you might not have intended to allow. Clients still need valid credentials to successfully log in to your instance.

For more information, see Authorizing with authorized networks.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. In the navigation panel, click Connections.

5. Under Authorized networks, delete 0.0.0.0/0 and add specific IP addresses or IP ranges that you want to let connect to your instance.

6. Click Done, and then click Save.

Learn about this finding type's supported assets and scan settings.

Pubsub CMEK disabled

Category name in the API: PUBSUB_CMEK_DISABLED

A Pub/Sub topic is not encrypted with customer-managed encryption keys (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google uses to encrypt your data, giving you more control over access to your data.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, delete the existing topic and create a new one:

1. Go to Pub/Sub's Topics page in the Google Cloud console.

   Go to Topics

2. If necessary, select the project containing the Pub/Sub topic.

3. Select the checkbox next to the topic listed in the finding, and then click Delete.

4. To create a new Pub/Sub topic with CMEK enabled, see Using customer-managed encryption keys. CMEK incurs additional costs related to Cloud KMS.

5. Publish findings or other data to the CMEK-enabled Pub/Sub topic.

Learn about this finding type's supported assets and scan settings.

Route not monitored

Category name in the API: ROUTE_NOT_MONITORED

Note: The logs-based metric filter for this detector was changed on Oct 27, 2021.

Log metrics and alerts aren't configured to monitor VPC network route changes.

Google Cloud routes are destinations and hops that define the path that network traffic takes from a VM instance to a destination IP. By monitoring changes to route tables, you can help ensure that all VPC traffic flows through an expected path.

For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

Create metric

1. Go to the Logs-based Metrics page in the Google Cloud console.

   Go to Logs-based Metrics

2. Click Create Metric.

3. Under Metric Type, select Counter.

4. Under Details:

   1. Set a Log metric name.
   2. Add a description.
   3. Set Units to 1.

5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:

     resource.type="gce_route"
     AND (protoPayload.methodName:"compute.routes.delete"
     OR protoPayload.methodName:"compute.routes.insert")
   

6. Click Create Metric. You see a confirmation.

Create Alert Policy

1. In the Google Cloud console, select Logging, and then select Log-based metrics, or click the following button:

   Go to Log-based metrics

2. Under the User-defined metrics section, select the metric you created in the previous section.

3. Click More , and then click Create alert from metric.

   The New condition dialog opens with the metric and data transformation options pre-populated.

4. Click Next.
   1. Review the pre-populated settings. You might want to modify the Threshold value.
   2. Click Condition name and enter a name for the condition.
5. Click Next.

6. To add notifications to your alerting policy, click Notification channels. In the dialog, select one or more notification channels from the menu, and then click OK.

   To be notified when incidents are opened and closed, check Notify on incident closure. By default, notifications are sent only when incidents are opened.

7. Optional: Update the Incident autoclose duration. This field determines when Monitoring closes incidents in the absence of metric data.
8. Optional: Click Documentation, and then add any information that you want included in a notification message.
9. Click Alert name and enter a name for the alerting policy.
10. Click Create Policy.

Learn about this finding type's supported assets and scan settings.

Redis role used on org

Category name in the API: REDIS_ROLE_USED_ON_ORG

This finding isn't available for project-level activations.

A Redis IAM role is assigned at the organization or folder level.

The following Redis IAM roles should be assigned per project only, not at the organization or folder level:

• roles/redis.admin
• roles/redis.viewer
• roles/redis.editor

For more information, see Access control and permissions.

To remediate this finding, complete the following steps:

1. Go to the IAM policy page in the Google Cloud console.

   Go to IAM policy

2. Remove the Redis IAM roles indicated in the finding and add them on the individual projects instead.

Learn about this finding type's supported assets and scan settings.

Release channel disabled

Category name in the API: RELEASE_CHANNEL_DISABLED

A GKE cluster is not subscribed to a release channel.

Subscribe to a release channel to automate version upgrades to the GKE cluster. The features also reduces version management complexity to the number of features and level of stability required. For more information, see Release channels.

To remediate this finding, complete the following steps:

1. Go to the Kubernetes clusters page in the Google Cloud console.

   Go to Kubernetes clusters

2. In the Cluster basics section, click on the edit icon () in the Release channel row.

   If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

3. In the dialog, select Release channel, and then choose the release channel you want to subscribe to.

   If the control plane version of your cluster is not upgradeable to a release channel, that channel might be disabled as an option.

4. Click Save Changes.

Learn about this finding type's supported assets and scan settings.

RSASHA1 for signing

Category name in the API: RSASHA1_FOR_SIGNING

RSASHA1 is used for key signing in Cloud DNS zones. The algorithm used for key signing should not be weak.

To remediate this finding, replace the algorithm with a recommended one by following the Using advanced signing options guide.

Learn about this finding type's supported assets and scan settings.

Service account key not rotated

Category name in the API: SERVICE_ACCOUNT_KEY_NOT_ROTATED

This finding isn't available for project-level activations.

A user-managed service account key hasn't been rotated for more than 90 days.

In general, user-managed service account keys should be rotated at least every 90 days, to ensure that data cannot be accessed with an old key that might have been lost, compromised, or stolen. For more information, see Rotate service account keys to reduce security risk caused by leaked keys.

If you generated the public/private key pair yourself, stored the private key in a hardware security module (HSM), and uploaded the public key to Google, then you might not need to rotate the key every 90 days. Instead, you can rotate the key if you believe that it might have been compromised.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

1. Go to the Service Accounts page in the Google Cloud console.

   Go to Service Accounts

2. If necessary, select the project indicated in the finding.

3. In the list of service accounts, find the service account listed in the finding and click Delete. Before proceeding, consider the impact deleting a service account could have on your production resources.

4. Create a new service account key to replace the old one. For more information, see Creating service account keys.

Learn about this finding type's supported assets and scan settings.

Service account role separation

Category name in the API: SERVICE_ACCOUNT_ROLE_SEPARATION

This finding isn't available for project-level activations.

One or more principals in your organization have multiple service account permissions assigned. No account should simultaneously have Service Account Admin along with other service account permissions. To learn about service accounts and the roles available to them, see Service accounts.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

1. Go to the IAM page in the Google Cloud console.

   Go to IAM

2. For each principal listed in the finding, do the following:

   1. Check whether the role was inherited from a folder or organization resource by looking at the Inheritance column. If the column contains a link to a parent resource, click on the link to go to the parent resource's IAM page.
   2. Click Edit next to a principal.
   3. To remove permissions, click Delete next to Service Account Admin. If you want to remove all service account permissions, click Delete next to all other permissions.

3. Click Save.

Learn about this finding type's supported assets and scan settings.

Shielded VM disabled

Category name in the API: SHIELDED_VM_DISABLED

Shielded VM is disabled on this Compute Engine instance.

Shielded VM's are virtual machines (VMs) on Google Cloud hardened by a set of security controls that help defend against rootkits and bootkits. Shielded VM's help ensure that the boot loader and firmware are signed and verified. Learn more about Shielded VM.

To remediate this finding, complete the following steps:

1. Go to the VM instances page in the Google Cloud console.

   Go to VM instances

2. Select the instance related to the Security Health Analytics finding.

3. On the Instance details page that loads, click Stop.

4. After the instance stops, click Edit.

5. In the Shielded VM section, toggle Turn on vTPM and Turn on Integrity Monitoring to enable Shielded VM.

6. Optionally, if you do not use any custom or unsigned drivers, then also enable Secure Boot.

7. Click Save. The new configuration appears on the Instance details page.

8. Click Start to start the instance.

Learn about this finding type's supported assets and scan settings.

SQL CMEK disabled

Category name in the API: SQL_CMEK_DISABLED

A SQL database instance is not using customer-managed encryption keys (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google uses to encrypt your data, giving you more control over access to your data. For more information, see CMEK overviews for your product: Cloud SQL for MySQL, Cloud SQL for PostgreSQL, or Cloud SQL for SQL Server. CMEK incurs additional costs related to Cloud KMS.

Caution: These remediation steps could disrupt your production environment. If necessary, shift workloads, data, or permissions to new resources before deleting existing assets.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Delete.

4. To create a new instance with CMEK enabled, follow the instructions to configure CMEK for your product:

   1. Cloud SQL for MySQL
   2. Cloud SQL for PostgreSQL
   3. Cloud SQL for SQL Server

Learn about this finding type's supported assets and scan settings.

SQL contained database authentication

Category name in the API: SQL_CONTAINED_DATABASE_AUTHENTICATION

A Cloud SQL for SQL Server database instance does not have the contained database authentication database flag set to Off.

The contained database authentication flag controls whether you can create or attach contained databases to the Database Engine. A contained database includes all database settings and metadata required to define the database and has no configuration dependencies on the instance of the Database Engine where the database is installed.

Enabling this flag is not recommended because of the following:

• Users can connect to the database without authentication at the Database Engine level.
• Isolating the database from the Database Engine makes it possible to move the database to another instance of SQL Server.

Contained databases face unique threats that should be understood and mitigated by SQL Server Database Engine administrators. Most threats result from the USER WITH PASSWORD authentication process, which moves the authentication boundary from the Database Engine level to the database level.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the contained database authentication database flag with the value Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL cross DB ownership chaining

Category name in the API: SQL_CROSS_DB_OWNERSHIP_CHAINING

A Cloud SQL for SQL Server database instance does not have the cross db ownership chaining database flag set to Off.

The cross db ownership chaining flag lets you control cross-database ownership chaining at the database level or allow cross-database ownership chaining for all database statements.

Enabling this flag is not recommended unless all databases hosted by the SQL Server instance participate in cross-database ownership chaining and you are aware of the security implications of this setting.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the cross db ownership chaining database flag with the value Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL external scripts enabled

Category name in the API: SQL_EXTERNAL_SCRIPTS_ENABLED

A Cloud SQL for SQL Server database instance does not have the external scripts enabled database flag set to Off.

When activated, this setting enables the execution of scripts with certain remote language extensions. Since this feature can adversely affect the security of the system, we recommend disabling it.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. In the Database flags section, set the external scripts enabled database flag with the value Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL instance not monitored

Category name in the API: SQL_INSTANCE_NOT_MONITORED

This finding isn't available for project-level activations.

Log metrics and alerts aren't configured to monitor Cloud SQL instance configuration changes.

Misconfiguration of SQL instance options can cause security risks. Disabling auto backup and high availability options could impact business continuity and not restricting authorized networks could increase exposure to untrusted networks. Monitoring changes to SQL instance configuration helps you reduce the time it takes to detect and correct misconfigurations.

For more information, see Overview of logs- based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization.

To remediate this finding, complete the following steps:

Create metric

1. Go to the Logs-based Metrics page in the Google Cloud console.

   Go to Logs-based Metrics

2. Click Create Metric.

3. Under Metric Type, select Counter.

4. Under Details:

   1. Set a Log metric name.
   2. Add a description.
   3. Set Units to 1.

5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:

     protoPayload.methodName="cloudsql.instances.update"
     OR protoPayload.methodName="cloudsql.instances.create"
     OR protoPayload.methodName="cloudsql.instances.delete"
   

6. Click Create Metric. You see a confirmation.

Create Alert Policy

1. In the Google Cloud console, select Logging, and then select Log-based metrics, or click the following button:

   Go to Log-based metrics

2. Under the User-defined metrics section, select the metric you created in the previous section.

3. Click More , and then click Create alert from metric.

   The New condition dialog opens with the metric and data transformation options pre-populated.

4. Click Next.
   1. Review the pre-populated settings. You might want to modify the Threshold value.
   2. Click Condition name and enter a name for the condition.
5. Click Next.

6. To add notifications to your alerting policy, click Notification channels. In the dialog, select one or more notification channels from the menu, and then click OK.

   To be notified when incidents are opened and closed, check Notify on incident closure. By default, notifications are sent only when incidents are opened.

7. Optional: Update the Incident autoclose duration. This field determines when Monitoring closes incidents in the absence of metric data.
8. Optional: Click Documentation, and then add any information that you want included in a notification message.
9. Click Alert name and enter a name for the alerting policy.
10. Click Create Policy.

Learn about this finding type's supported assets and scan settings.

SQL local infile

Category name in the API: SQL_LOCAL_INFILE

A Cloud SQL for MySQL database instance does not have the local_infile database flag set to Off. Due to security issues associated with the local_infile flag, it should be disabled. For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the local_infile database flag with the value Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log checkpoints disabled

Category name in the API: SQL_LOG_CHECKPOINTS_DISABLED

A Cloud SQL for PostgreSQL database instance does not have the log_checkpoints database flag set to On.

Enabling log_checkpoints causes checkpoints and restart points to be logged in the server log. Some statistics are included in the log messages, including the number of buffers written and the time spent writing them.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_checkpoints database flag with the value On.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log connections disabled

Category name in the API: SQL_LOG_CONNECTIONS_DISABLED

A Cloud SQL for PostgreSQL database instance does not have the log_connections database flag set to On.

Enabling the log_connections setting causes attempted connections to the server to be logged, along with successful completion of client authentication. The logs can be useful in troubleshooting issues and confirming unusual connection attempts to the server.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_connections database flag with the value On.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log disconnections disabled

Category name in the API: SQL_LOG_DISCONNECTIONS_DISABLED

A Cloud SQL for PostgreSQL database instance does not have the log_disconnections database flag set to On.

Enabling the log_disconnections setting creates log entries at the end of each session. The logs are useful in troubleshooting issues and confirming unusual activity across a time period. For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_disconnections database flag with the value On.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log duration disabled

Category name in the API: SQL_LOG_DURATION_DISABLED

A Cloud SQL for PostgreSQL database instance does not have the log_duration database flag set to On.

When log_duration is enabled, this setting causes the execution time and duration of each completed statement to be logged. Monitoring the amount of time it takes to execute queries can be crucial in identifying slow queries and troubleshooting database issues.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_duration database flag to On.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log error verbosity

Category name in the API: SQL_LOG_ERROR_VERBOSITY

A Cloud SQL for PostgreSQL database instance does not have the log_error_verbosity database flag set to default or stricter.

The log_error_verbosity flag controls the amount of detail in messages logged. The greater the verbosity, the more details are recorded in messages. We recommend setting this flag to default or stricter.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. In the Database flags section, set the log_error_verbosity database flag to default or stricter.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log lock waits disabled

Category name in the API: SQL_LOG_LOCK_WAITS_DISABLED

A Cloud SQL for PostgreSQL database instance does not have the log_lock_waits database flag set to On.

Enabling the log_lock_waits setting creates log entries when session waits take longer than the deadlock_timeout time to acquire a lock. The logs are useful in determining whether lock waits are causing poor performance.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_lock_waits database flag with the value On.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log min duration statement enabled

Category name in the API: SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

A Cloud SQL for PostgreSQL database instance does not have the log_min_duration_statement database flag set to -1.

The log_min_duration_statement flag causes SQL statements that run longer than a specified time to be logged. Consider disabling this setting because SQL statements might contain sensitive information that should not be logged. For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_min_duration_statement database flag with the value -1.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log min error statement

Category name in the API: SQL_LOG_MIN_ERROR_STATEMENT

A Cloud SQL for PostgreSQL database instance does not have the log_min_error_statement database flag set appropriately.

The log_min_error_statement flag controls whether SQL statements that cause error conditions are recorded in server logs. SQL statements of the specified severity or higher are logged with messages for the error statements. The greater the severity, the fewer messages are recorded.

If log_min_error_statement is not set to the correct value, messages might not be classified as error messages. A severity set too low might increase the number of messages and make it difficult to find actual errors. A severity set too high might cause error messages for actual errors to not be logged.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_min_error_statement database flag with one of the following recommended values, according to your organization's logging policy.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log min error statement severity

Category name in the API: SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY

A Cloud SQL for PostgreSQL database instance does not have the log_min_error_statement database flag set appropriately.

The log_min_error_statement flag controls whether SQL statements that cause error conditions are recorded in server logs. SQL statements of the specified severity or stricter are logged with messages for the error statements. The stricter the severity, the fewer messages are recorded.

If log_min_error_statement is not set to the correct value, messages might not be classified as error messages. A severity set too low would increase the number of messages and make it difficult to find actual errors. A severity level that is too high (too strict) might cause error messages for actual errors to not be logged.

We recommend setting this flag to error or stricter.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. In the Database flags section, set the log_min_error_statement database flag with one of the following recommended values, according to your organization's logging policy.

   • error
   • log
   • fatal
   • panic

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log min messages

Category name in the API: SQL_LOG_MIN_MESSAGES

A Cloud SQL for PostgreSQL database instance does not have the log_min_messages database flag set to at minimum warning.

The log_min_messages flag controls which message levels are recorded in server logs. The higher the severity, the fewer messages are recorded. Setting the threshold too low can result in increased log storage size and length, making it difficult to find actual errors.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_min_messages database flag with one of the following recommended values, according to your organization's logging policy.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log executor stats enabled

Category name in the API: SQL_LOG_EXECUTOR_STATS_ENABLED

A Cloud SQL for PostgreSQL database instance does not have the log_executor_status database flag set to Off.

When the log_executor_status flag is activated, executor performance statistics are included in the PostgreSQL logs for each query. This setting can be useful for troubleshooting, but it can significantly increase the number of logs and performance overhead.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_executor_status database flag to Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log hostname enabled

Category name in the API: `SQL_LOG_HOSTNAME_ENABLED

A Cloud SQL for PostgreSQL database instance does not have the log_hostname database flag set to Off.

When the log_hostname flag is activated, the hostname of the connecting host is logged. By default, connection log messages only show the IP address. This setting can be useful for troubleshooting. However, it can incur overhead on server performance, because for each statement logged, DNS resolution is required to convert an IP address to a hostname.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_hostname database flag to Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log parser stats enabled

Category name in the API: SQL_LOG_PARSER_STATS_ENABLED

A Cloud SQL for PostgreSQL database instance does not have the log_parser_stats database flag set to Off.

When the log_parser_stats flag is activated, parser performance statistics are included in the PostgreSQL logs for each query. This can be useful for troubleshooting, but it can significantly increase the number of logs and performance overhead.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_parser_stats database flag to Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log planner stats enabled

Category name in the API: SQL_LOG_PLANNER_STATS_ENABLED

A Cloud SQL for PostgreSQL database instance does not have the log_planner_stats database flag set to Off.

When the log_planner_stats flag is activated, a crude profiling method for logging PostgreSQL planner performance statistics is used. This can be useful for troubleshooting, but it can significantly increase the number of logs and performance overhead.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_planner_stats database flag to Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log statement

Category name in the API: SQL_LOG_STATEMENT

A Cloud SQL for PostgreSQL database instance does not have the log_statement database flag set to Ddl.

The value of this flag controls which SQL statements are logged. Logging helps troubleshoot operational problems and permits forensic analysis. If this flag isn't set to the correct value, relevant information might be skipped or might be hidden in too many messages. A value of Ddl (all data definition statements) is recommended unless otherwise directed by your organization's logging policy.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_statement database flag to Ddl.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log statement stats enabled

Category name in the API: SQL_LOG_STATEMENT_STATS_ENABLED

A Cloud SQL for PostgreSQL database instance does not have the log_statement_stats database flag set to Off.

When the log_statement_stats flag is activated, end-to-end performance statistics are included in the PostgreSQL logs for each query. This setting can be useful for troubleshooting, but it can significantly increase the number of logs and performance overhead.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_statement_stats database flag to Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL log temp files

Category name in the API: SQL_LOG_TEMP_FILES

A Cloud SQL for PostgreSQL database instance does not have the log_temp_files database flag set to 0.

Temporary files can be created for sorts, hashes, and temporary query results. Setting the log_temp_files flag to 0 causes all temporary files information to be logged. Logging all temporary files is useful for identifying potential performance issues. For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. Under the Database flags section, set the log_temp_files database flag with the value 0.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL no root password

Category name in the API: SQL_NO_ROOT_PASSWORD

A MySQL database instance does not have a password set for the root account. You should add a password to the MySQL database instance. For more information, see MySQL users.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. On the Instance details page that loads, select the Users tab.

4. Next to the root user, click More , and then select Change Password.

5. Enter a new, strong password, and then click OK.

Learn about this finding type's supported assets and scan settings.

SQL public IP

Category name in the API: SQL_PUBLIC_IP

A Cloud SQL database has a public IP address.

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

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. On the left-side menu, click on Connections.

4. Click on the Networking tab and clear the Public IP check box.

5. If the instance is not already configured to use a private IP, see Configuring private IP for an existing instance.

6. Click Save.

Learn about this finding type's supported assets and scan settings.

SQL remote access enabled

Category name in the API: SQL_REMOTE_ACCESS_ENABLED

A Cloud SQL for SQL Server database instance doesn't have the remote access database flag set to Off.

When activated, this setting grants permission to run local stored procedures from remote servers or remote stored procedures from the local server. This functionality can be abused to launch a Denial-of-Service (DoS) attack on remote servers by offloading query processing to a target. To prevent abuse, we recommend disabling this setting.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the Cloud SQL Instances page in the Google Cloud console.

   Go to Cloud SQL Instances

2. Select the instance listed in the Security Health Analytics finding.

3. Click Edit.

4. In the Flags section, set remote access to Off.

5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL skip show database disabled

Category name in the API: SQL_SKIP_SHOW_DATABASE_DISABLED

A Cloud SQL for MySQL database instance does not have the skip_show_database database flag set to On.

When activated, this flag prevents users from using the SHOW DATABASES statement if they don't have the SHOW DATABASES privilege. With this setting, users without explicit permission aren't able to see databases that belong to other users. We recommend enabli