Security Command Center latency overview

This page provides an overview of the Security Command Center activation process that takes place after you enable the service. It aims to answer common questions:

  • What happens after an organization is enabled?
  • Why is there a delay before the first scan starts?
  • What is the expected runtime for the first scan and ongoing scans?
  • How will changing resources and settings impact performance?

Overview

Most Security Command Center customers do not experience significant delays in onboarding or enablement. About 99% of users are up and running within four hours of enabling the service. While these figures represent the typical user's experience, there are factors that can cause the enablement process to take longer. Sometimes, typically for organizations with more than 100,000 projects, enablement and scans can take up to 24 hours or more to complete. The factors discussed below can introduce latency in starting scans, processing changes to settings, and the runtime of scans.

Topology

The figure below provides a high-level illustration of the onboarding and enablement process.

Illustration of Security Command Center onboarding (click to enlarge)
Illustration of Security Command Center onboarding (click to enlarge)

Latency in onboarding

Before scans start, Security Command Center discovers and indexes resources that belong to your organization from across Google Cloud. Indexed services include App Engine, BigQuery, Cloud SQL, Cloud Storage, Compute Engine, Identity and Access Management, and Google Kubernetes Engine. During this onboarding process, two critical steps take place.

Asset scan

Security Command Center conducts an initial asset scan to identify the total number, location, and state of projects, folders, files, clusters, identity and access policies, enrolled users, and other resources. This process is usually completed within minutes.

API activation

As resources are discovered, Security Command Center enables parts of Google Cloud that are needed for Security Health Analytics, Event Threat Detection, Container Threat Detection, and Web Security Scanner to operate. Some detection services require specific APIs to be enabled on protected projects to function. API activation is the process of iterating through the projects you select for scanning and automatically enabling those APIs.

The number of projects in an organization largely determines the length of the onboarding and enablement processes. Because APIs must be activated for projects one by one, API activation is usually the most time-consuming task, particularly for organizations with more than 100,000 projects.

Enabling services across projects scales linearly. That means, generally, it takes twice as long to enable services and security settings in an organization with 30,000 projects than one with 15,000 projects.

For all but the largest organizations, onboarding should be completed within four hours.

Findings

When you set up Security Command Center, you decide which built-in services to enable and select the Google Cloud resources that you want to have analyzed, or scanned, for threats and vulnerabilities. As APIs are activated for projects, selected services begin their scans. The duration of these scans also depends on the number of projects in an organization.

Findings from built-in services are available as each completes its initial scans. Each service may experience latency as described below.

  • Container Threat Detection has the following latencies:
    • Activation latency of up to 3.5 hours for newly onboarded organizations.
    • Activation latency of up to 30 minutes for newly created clusters.
    • Detection latency of minutes for threats in clusters that have been activated.
  • Event Threat Detection activation occurs within seconds. Detection latencies are generally less than 15 minutes, from the time a log is written to when a finding is available in Security Command Center.

  • Security Health Analytics scans start approximately one hour after the service is enabled. The first Security Health Analytics scans can take up to 12 hours to complete. After that, most detections run in real time against asset configuration changes (exceptions are detailed in Security Health Analytics Detections Latency).

  • Web Security Scanner scans can take up to 24 hours to start after the service is enabled and run weekly after the first scan.

Preliminary findings

You may see some findings in the Security Command Center dashboard while the initial scan is taking place but before the onboarding process is complete.

Preliminary findings are accurate and actionable, but they are not comprehensive. Using these findings for a compliance assessment within the first 24 hours is not recommended.

Subsequent scans

Changes made within your organization, such as adding new folders and projects and moving resources, usually won't significantly impact resource discovery time or the runtime of scans. However, some scans proceed on set schedules, which determine how quickly Security Command Center detects changes.

  • Web Security Scanner: runs weekly, on the same day as the initial scan. Because it runs weekly, Web Security Scanner won't detect organizational changes in real time. If you move a resource or alter an application, the change might not be detected for up to a week.
  • Event Threat Detection/Container Threat Detection: these services run in real time when they are turned on and immediately detect new or changed resources, such as clusters, buckets, or logs, in enabled projects.
  • Security Health Analytics: runs in real time when turned on and detects new or changed resources in minutes, excluding the detections listed below.

Security Health Analytics Detection Latency

Security Health Analytics detections run all at once when the service is enabled or one by one in real-time mode when the configuration of a related asset changes. Once Security Health Analytics is enabled, any relevant resource configuration changes result in updated misconfiguration findings in near-real time (within 10 minutes, but often faster).

Some Security Health Analytics detectors do not support real-time scanning mode if, for example, a detection runs against information outside of a resource's configuration. These detections, listed in the table below, run periodically and identify misconfigurations within 12 hours. Read Vulnerabilities and findings for more details on Security Health Analytics detectors.

Security Health Analytics detections that do not support real-time scanning mode
API_KEY_EXISTS
API_KEY_NOT_ROTATED
API_KEY_APIS_UNRESTRICTED
API_KEY_APPS_UNRESTRICTED
COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED
COMPUTE_SERIAL_PORTS_ENABLED
DISK_CSEK_DISABLED
FULL_API_ACCESS
MFA_NOT_ENFORCED (previously named 2SV_NOT_ENFORCED)
OS_LOGIN_DISABLED
PUBLIC_IP_ADDRESS
SSH_PASSWORD_ENABLED
SQL_NO_ROOT_PASSWORD
SQL_WEAK_ROOT_PASSWORD
WEAK_SSH_PASSWORD

What's next