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.

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.

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.

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.

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.

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.

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.

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.

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.

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 principal next to the principal.
    2. To remove permissions, click Delete role next to the 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.

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.

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

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

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

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

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

  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.

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.

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

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.

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

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

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

    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.

  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.

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

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