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 Security Command Center is enabled for an organization?
- Why is there a delay before the first scans start?
- What is the expected runtime for the first scans and ongoing scans?
- How will changing resources and settings impact performance?
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 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 initial 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.
The figure below provides a high-level illustration of the onboarding and enablement process.
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.
Security Command Center conducts an initial asset scan to identify the total number, location, and state of projects, folders, files, clusters, identities, access policies, enrolled users, and other resources. This process is usually completed within minutes.
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.
The time needed to enable 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 and enablement should be completed within four hours.
When you set up Security Command Center, you decide which built-in and integrated 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 initial scans are completed. Services 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 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 Detection Latency).
VM Threat Detection has an activation latency of up to 48 hours for newly onboarded organizations.
Web Security Scanner scans can take up to 24 hours to start after the service is enabled and run weekly after the first scan.
Security Command Center runs error detectors, which detect configuration errors related to Security Command Center and its services. These error detectors are activated by default and can't be deactivated. Detection latencies vary depending on the error detector. For more information, see Security Command Center errors.
Security Command Center roles are 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 for which you are granted access. To learn more about Security Command Center roles, see Access control.
You might see some findings in the Security Command Center dashboard while initial scans are 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.
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. You can run on-demand scans to check new or changed resources between scheduled scans.
- 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 Command Center error detectors run periodically in batch mode. Batch scanning frequencies vary depending on the error detector. For more information, see Security Command Center errors.
Security Health Analytics Detection Latency
Security Health Analytics detections run periodically in batch mode after the service is enabled, as well as 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 some cases, updates might take several minutes, depending on the asset type and change.
Some Security Health Analytics detectors do not support immediate 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|
|MFA_NOT_ENFORCED (previously named 2SV_NOT_ENFORCED)|