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.

Security Health Analytics remediation

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

For finding types that are mapped to CIS Benchmarks, the remediation guidance comes from Center for Internet Security (CIS), unless otherwise stated. For more information, see Detectors and compliance.

Automatic deactivation of findings

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. Disabling a detector in Security Health Analytics also sets the state of any findings generated by that detector to INACTIVE. 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. If you want to remove a finding for a deleted resource from your display while you are waiting for Security Health Analytics to detect that the resource is deleted, you can mute the finding. To mute a finding, see Mute findings in Security Command Center.

Do not use mute to hide remediated findings for existing resources. If the issue recurs and Security Health Analytics restores the ACTIVE state of the finding, you might not see the reactivated finding, because muted findings are excluded from any finding query that specifies NOT mute="MUTED", such as the default finding query.

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.

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

AlloyDB auto backup disabled

Category name in the API: ALLOYDB_AUTO_BACKUP_DISABLED

An AlloyDB for PostgreSQL cluster doesn't have automatic backups enabled.

To help prevent data loss, turn on automated backups for your cluster. For more information, see Configure additional automated backups.

To remediate this finding, complete the following steps:

1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

   Go to AlloyDB for PostgreSQL clusters

2. Click a cluster in the Resource Name column.

3. Click Data protection.

4. Under the Automated backup policy section, click Edit in the Automated backups row.

5. Select the Automate backups checkbox.

6. Click Update.

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

AlloyDB backups disabled

Category name in the API: ALLOYDB_BACKUPS_DISABLED

An AlloyDB for PostgreSQL cluster has neither automatic nor continuous backups enabled.

To help prevent data loss, turn on either automated or continuous backups for your cluster. For more information, see Configure additional backups.

To remediate this finding, complete the following steps:

1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

   Go to AlloyDB for PostgreSQL clusters

2. In the Resource Name column, click the name of the cluster that is identified in the finding.

3. Click Data protection.

4. Set up a backup policy.

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

AlloyDB CMEK disabled

Category name in the API: ALLOYDB_CMEK_DISABLED

An AlloyDB cluster 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 About CMEK. CMEK incurs additional costs related to Cloud KMS.

To remediate this finding, complete the following steps:

1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

   Go to AlloyDB for PostgreSQL clusters

2. In the Resource Name column, click the name of the cluster that is identified in the finding.

3. Click Create Backup. Set a backup ID.

4. Click Create.

5. Under the Backup/Restore section, click Restore next to the Backup ID entry you chose.

6. Set a new cluster ID and network.

7. Click Advanced Encryption Options. Select the CMEK that you want to encrypt the new cluster with.

8. Click Restore.

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

AlloyDB log min error statement severity

Category name in the API: ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY

An AlloyDB for PostgreSQL instance does not have the log_min_error_statement database flag set to error or another recommended value.

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. The higher the severity, the fewer messages that are recorded. If set to a severity level that is too high, error messages might not be logged.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

   Go to AlloyDB for PostgreSQL clusters

2. Click the cluster in the Resource Name column.

3. Under the Instances in your cluster section, click Edit for the instance.

4. Click Advanced Configuration Options.

5. Under the 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

6. Click Update Instance.

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

AlloyDB log min messages

Category name in the API: ALLOYDB_LOG_MIN_MESSAGES

An AlloyDB for PostgreSQL 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 AlloyDB for PostgreSQL clusters page in the Google Cloud console.

   Go to AlloyDB for PostgreSQL clusters

2. Click the cluster in the Resource Name column.

3. Under the Instances in your cluster section, click Edit for the instance.

4. Click Advanced Configuration Options.

5. Under the 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

6. Click Update Instance.

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

AlloyDB log error verbosity

Category name in the API: ALLOYDB_LOG_ERROR_VERBOSITY

An AlloyDB for PostgreSQL instance does not have the log_error_verbosity database flag set to default or another less restrictive value.

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 another less restrictive value.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

   Go to AlloyDB for PostgreSQL clusters

2. Click the cluster in the Resource Name column.

3. Under the Instances in your cluster section, click Edit for the instance.

4. Click Advanced Configuration Options.

5. Under the Flags section, set the log_error_verbosity database flag with one of the following recommended values, according to your organization's logging policy.

   • default
   • verbose

6. Click Update Instance.

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

AlloyDB Public IP

Category name in the API: ALLOYDB_PUBLIC_IP

An AlloyDB for PostgreSQL database instance has a public IP address.

To reduce your organization's attack surface, use private instead of 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 AlloyDB for PostgreSQL clusters page in the Google Cloud console.

   Go to AlloyDB for PostgreSQL clusters

2. In the Resource Name column, click the name of the cluster that is identified in the finding.

3. Under the Instances in your cluster section, click Edit for the instance.

4. Under the Connectivity section, uncheck the box for Enable Public IP.

5. Click Update Instance.

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

AlloyDB SSL not enforced

Category name in the API: ALLOYDB_SSL_NOT_ENFORCED

An AlloyDB for PostgreSQL database instance doesn't require all incoming connections to use SSL.

To avoid leaking sensitive data in transit through unencrypted communications, all incoming connections to your AlloyDB database instance should use SSL. Learn more about Configuring SSL/TLS.

To remediate this finding, complete the following steps:

1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

   Go to AlloyDB for PostgreSQL clusters

2. In the Resource Name column, click the name of the cluster that is identified in the finding.

3. Under the Instances in your cluster section, click Edit for the instance.

4. Under the Network Security section, click the box for Require SSL Encryption.

5. Click Update Instance.

read_more 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 Edit principal next to the principal.
   2. To remove permissions, click delete Delete role next to the role.
   3. Click Save.

read_more 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.

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.

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.

read_more 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, click more_vert Actions.
   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.
   5. Click Save. It might take up to five minutes for settings to take effect.

read_more 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, click more_vert Actions.
   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.
   6. Click Save.

read_more 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.

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, click more_vert Actions.

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

read_more 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. Rotating 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 Best practices for managing API keys.

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, click more_vert Actions.
   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, click refresh Rotate key. A new key is generated.
   4. Optionally, change the API key name.
   5. Click Create.
   6. Update your applications to use the new key.
   7. After you have updated your applications, return to the Edit API key page and click Delete the previous key to delete the old key. The old key won't be deleted automatically.

read_more 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 Google Cloud Observability 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, 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, go to the Log-based Metrics page:

   Go to Log-based Metrics

   If you use the search bar to find this page, then select the result whose subheading is Logging.

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

3. Click More more_vert, 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.

read_more 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 Google Cloud Observability pricing.

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 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 Delete next to each name.
   3. Click Save.

read_more 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. In the Google Cloud console, go to the Cloud SQL Instances page.

   Go to Instances

2. Click the instance name.

3. Click Backups.

4. Next to Settings, click edit Edit.

5. Select the Automated daily backups checkbox.

6. Optional: In the Number of days box, enter how many days of backups you want to retain.

7. Optional: In the Backup window list, select the time window in which to take backups.

8. Click Save.

read_more 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 Edit.
   3. Under Management, select Enable auto-repair.
   4. Click Save.

read_more 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 Edit.
   3. Under Management, select Enable auto-upgrade.
   4. Click Save.

read_more 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.

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.

read_more 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 edit Edit 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.

read_more 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.

read_more 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 Google Cloud Observability 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:

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, go to the Log-based Metrics page:

   Go to Log-based Metrics

   If you use the search bar to find this page, then select the result whose subheading is Logging.

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

3. Click More more_vert, 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.

read_more 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.

read_more 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 edit Edit access control model.

5. In the dialog, select Uniform.

6. Click Save.

read_more 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 Google Cloud Observability pricing.

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 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.

read_more 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 Google Cloud Observability pricing.

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 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.

read_more 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 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.

read_more 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 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.

read_more 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 Edit Shielded GKE nodes.

4. Select the Enable Shielded GKE nodes checkbox.

5. Click Save Changes.

read_more 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 Edit.

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

5. Click Save.

read_more 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 Stop.

4. After the instance stops, click edit Edit.

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

6. Click Save.

7. Click play_arrow Start to start the instance.

read_more 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 Edit.

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

5. Click Save.

read_more 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.

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 Delete.

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

read_more 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 Edit .
   3. Under Nodes -> Image type, click Change.
   4. Select Container-Optimized OS, and then click Change.
   5. Click Save.

read_more 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 Google Cloud Observability 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:

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, go to the Log-based Metrics page:

   Go to Log-based Metrics

   If you use the search bar to find this page, then select the result whose subheading is Logging.

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

3. Click More more_vert, 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.

read_more 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.

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:[email protected]").

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 Delete cluster.

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

read_more 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.

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

read_more 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.

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.

read_more 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.

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 Delete VPC Network.

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

read_more 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 Stop.

4. After the instance stops, click edit 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.

read_more 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.

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 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.

read_more 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.

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 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.

read_more 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 Observability: 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 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 Edit policy.
     3. Set Logs to On.
     4. Click Save.

read_more 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.

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

Effectively Anonymous Users Granted GKE Cluster Access

Category name in the API: GKE_PRIVILEGE_ESCALATION_DEFAULT_USERS_GROUPS

Someone created an RBAC binding that references one of the following users or groups:

• system:anonymous
• system:authenticated
• system:unauthenticated

These users and groups are effectively anonymous and shouldn't be used in RoleBindings or ClusterRoleBindings. For details, see Avoid default roles and groups.

To remediate this finding, apply the following steps to your affected resources:

1. Open the manifest for each affected ClusterRoleBinding or RoleBinding.
2. Set the following restricted fields to one of the allowed values.

Restricted fields

• subjects[*].name

Allowed values

• Any groups, users, or service accounts not including system:anonymous, system:authenticated, or system:unauthenticated.

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.

read_more 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.

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

Firewall not monitored

Category name in the API: FIREWALL_NOT_MONITORED

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 Google Cloud Observability 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:

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, go to the Log-based Metrics page:

   Go to Log-based Metrics

   If you use the search bar to find this page, then select the result whose subheading is Logging.

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

3. Click More more_vert, 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.

read_more 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 Edit.

4. Under Logs, select On.

5. Click Save.

read_more 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 Edit.

6. Under Flow logs, select On.

read_more 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.

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 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.

read_more 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 and the API access scope set to 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. If the instance is running, click stop Stop.

4. When the instance is stopped, click edit Edit.

5. In the Security and access section, under Service accounts, select Compute Engine default service account.

6. Under Access scopes, select either Allow default access or Set access for each API. This limits the APIs that any process or workload that uses the default VM service account can access.

7. If you selected Set access for each API, do the following:

   • Disable Cloud Platform by setting it to None.
   • Enable the specific APIs that the default VM service account requires access to.

8. Click Save.

9. Click play_arrow Start to start the instance.

read_more 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 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.

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

Instance OS login disabled

Category name in the API: INSTANCE_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 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 Instance details page that loads, click stop Stop.

4. After the instance stops, click edit Edit.

5. In the Custom metadata section, ensure that the item with the key enable-oslogin has the value TRUE.

6. Click Save.

7. Click play_arrow Start to start the instance.

read_more 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.

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.

read_more 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.

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 edit Edit intranode visibility 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.

read_more 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.

read_more 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.

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 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 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.

read_more 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.

read_more 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 Edit.
   2. In the Edit permissions panel, next to the Owner role, click delete Delete.
   3. Click Save.

read_more 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 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 Delete to remove access for these principals.

read_more 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 Edit next to a principal.
   3. To remove permissions, click delete 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.

read_more 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 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.

read_more 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.

read_more 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.

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 Delete VPC Network.

read_more 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.

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 Edit.

4. Click Backend configuration.

5. In the Backend configuration page, click edit Edit.

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.

read_more 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 Bucket Lock.

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.

read_more 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.

read_more 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 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.

read_more 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