Troubleshooting steps

Learn about troubleshooting steps that might be helpful if you experience the following problems while using Security Command Center.

Enabling Security Command Center fails

Enabling Security Command Center most commonly fails if your organization policies restrict identities by domain. You and your service account must be part of an allowed domain:

  • Make sure you sign in to an account that's in an allowed domain before you try to enable Security Command Center.
  • If you're using an @*.gserviceaccount.com service account, add the service account as an identity in a group within an allowed domain.

Assets in Security Command Center aren't updating

If you're using VPC Service Controls, assets in Security Command Center can only be discovered and updated when you grant access to the Security Command Center service account.

To enable asset discovery, grant access to the Security Command Center service account. This allows the service account to complete asset discovery and display assets in the Google Cloud console. The service account name is in the form of service-org-organization-id@security-center-api.iam.gserviceaccount.com.

Viewing, editing, creating, and updating findings and assets

The IAM roles for Security Command Center can be granted at the organization, folder, or project level. Your ability to view, edit, create, or update findings, assets, and security sources depends on the level that you're granted access for. To learn more about Security Command Center roles, see Access control.

Missing or delayed notifications

In some situations, notifications might be missing, dropped, or delayed:

  • There might not be any findings that match the filters in your NotificationConfig. To test notifications, use the Security Command Center API to create a finding.
  • The Security Command Center service account must have the securitycenter.notificationServiceAgent role on the Pub/Sub topic. The service account name is in the form of service-organization-id@gcp-sa-scc-notification.iam.gserviceaccount.com.
    • If you remove the role, notification publishing is disabled.
    • If you remove the role and then grant the role again, notifications are delayed.
  • If you delete and recreate the Pub/Sub topic, notifications will be dropped.

External Exposure

The following sections describe troubleshooting steps that you might find helpful if you experience issues or unexpected traffic that is related to External Exposure.

Spikes in 403 Forbidden request logs from TsunamiSecurityScanner

You observe unexpected spikes in HTTP 403 Forbidden or HTTP 401 Unauthorized request logs on your public-facing endpoints, such as Cloud Run, Google Kubernetes Engine (GKE), or Cloud Load Balancing, with the user agent TsunamiSecurityScanner.

Cause

When External Exposure scans your public IP addresses and endpoints to detect exposed interfaces and vulnerabilities, the service sends probe requests using the user agent string TsunamiSecurityScanner.

If your endpoints or services enforce access controls, such as Identity and Access Management (IAM) authentication, Identity-Aware Proxy (IAP), or Google Cloud Armor security policies, the endpoints reject unauthenticated scanner requests. These rejections generate an HTTP 403 Forbidden or HTTP 401 Unauthorized log response. This behavior is expected and indicates that your security controls are blocking unauthenticated access.

Diagnose and resolve

To diagnose and resolve spikes in HTTP 403 Forbidden or HTTP 401 Unauthorized request logs from TsunamiSecurityScanner, follow these steps:

  1. To verify whether the HTTP 403 request logs originate from the scanner, on the Logs Explorer page, run the following query:

    httpRequest.userAgent="TsunamiSecurityScanner" AND httpRequest.status=403
    
  2. Confirm that the scanned services reside in projects where External Exposure is active. For more information about how scanner traffic appears in your logs, see Identify scanner traffic in your logs.

  3. Optional: If you have log-based alerts configured that trigger on HTTP 403 status codes, update the alert query to exclude scanner traffic:

    NOT httpRequest.userAgent="TsunamiSecurityScanner"
    

Web Security Scanner

This section contains troubleshooting steps that you might find helpful if you have problems using Web Security Scanner

Scan errors for Compute Engine and GKE

If the URL for a scan is misconfigured, Web Security Scanner rejects it. Possible reasons for rejection include:

URL has an IP address that is ephemeral

Mark this IP address as static:

  • For an application on a single VM, reserve the IP address on the VM
  • For an application behind a load balancer, reserve the IP address on the load balancer.

URL is mapped to a wrong IP address

To fix this finding, refer to the instructions from your DNS registrar service.

URL is mapped to an ephemeral IP address of the same VM

Mark this IP address as static.

URL is mapped to a reserved IP address

This error happens when the URL is mapped to an IP address that's reserved in a different project of the same organization. To resolve this, define security scans for the VM or HTTP load balancer in the project for which it is defined.

URL is mapped to more than one IP address

Make sure that all IP addresses that are mapped to this URL are reserved for the same project. If there is at least one IP address that isn't reserved for the same project, the Scan Create or Edit or Update operation fails.

What's next

Learn about Security Command Center errors.