This page provides an overview of the activation process thattakes place when you enable Security Command Center. It aims to answer commonquestions:

• What happens when Security Command Center is enabled?
• 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?

Overview

When you first enable Security Command Center, an activation process must completebefore Security Command Center can start scanning your resources. Then the scansmust complete before you see a complete set of findings for yourGoogle Cloud environment.

How long the activation process and scans take to complete depends on anumber of factors, including the number of assets and resources in yourenvironment and whether Security Command Center is activated at theorganization levelor theproject level.

With organization-level activations, Security Command Center must repeatcertain steps of the activation process for each project in theorganization. Depending on the number of projects in an organization,the time required for the activation process can range from minutes tohours. For organizations with more than 100,000 projects,a lot of resources in each project, and other complicating factors,enablement and initial scans can take up to 24 hours or more to complete.

With project-level activations of Security Command Center, the activationprocess is much faster, because the process is limited to the single project inwhich Security Command Center is activated.

The factors that can introduce latency in starting scans, processingchanges to settings, and the runtime of scans are discussed in the followingsections.

Latency in onboarding

Before scans start, Security Command Center discovers and indexes your resources.

Indexed services include App Engine, BigQuery, Cloud SQL,Cloud Storage, Compute Engine, Identity and Access Management, and Google Kubernetes Engine.

For project-level activations of Security Command Center, the discovery andindexing is limited to the single project in which Security Command Centeris activated.

For organization-level activations, Security Command Center discovers andindexes resources across your organization.

During this onboardingprocess, 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, identities, accesspolicies, enrolled users, and other resources. This process is usually completedwithin minutes.

API activation

As resources are discovered, Security Command Center enables parts ofGoogle 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 APIsto be enabled on protected projects to function.

When you activate Security Command Center at the project level, API activationusually takes less than a minute.

With organization-level activations, Security Command Center iterates throughall of the projects that you select for scanning to enable the necessary APIs.

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

The time needed to enable services across projects scales linearly. Thatmeans, generally, it takes twice as long to enable services and securitysettings in an organization with 30,000 projects than one with 15,000 projects.

For an organization with 100,000 projects, onboarding and enablement of thePremium tier should be completed in under five hours. Your time canvary depending on many factors, including the number of projects or containersthat you are using and the number of Security Command Center services that youchoose to enable.

Scan latency

When you set up Security Command Center, you decide which built-in and integratedservices to enable, and select the Google Cloud resources that you want tohave analyzed, or scanned, for threats and vulnerabilities. As APIs areactivated for projects, selected services begin their scans. The duration ofthese 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 in the following sections.

• Agent Engine Threat Detection (Preview) has the following latencies:
  • Activation latency of up to 3.5 hours for newly onboarded projects ororganizations.
  • Detection latency of minutes.
• Cloud Run Threat Detection has the following latencies:
  • Activation latency of up to 3.5 hours for newly onboarded projects ororganizations.
  • Detection latency of minutes.
• Container Threat Detection has the following latencies:
  • Activation latency of up to 3.5 hours for newly onboarded projects ororganizations.
  • Activation latency of minutes for newly created clusters.
  • Detection latency of minutes for threats in clusters that havebeen activated.

• Event Threat Detection activation occurs within seconds for built-indetectors. For new or updated custom detectors, it can take up to 15 minutesfor your changes to take effect. In practice, it typically takes less than 5minutes.

  For built-in and custom detectors, detectionlatencies are generally less than 15 minutes, from the time a log is writtento when a finding is available in Security Command Center.

• Issues data for the Security Command Center Premium andEnterprise tiers can take approximately 6 hours to appear.

• Security graph data for the Security Command Center Premium and Enterprise tierscan take approximately 2 hours to appear.

• Security Health Analytics Security Health Analytics scans start approximately one hour after the service is enabled. The firstSecurity Health Analytics scans can take up to 12 hours to complete for Security Command Center Premium and Enterprise and 48 hours to complete for Security Command Center Standard. Afterward, most detections run inreal time against asset configuration changes (exceptions are detailed inSecurity Health Analytics DetectionsLatency).

• VM Threat Detection has an activation latency of up to 48 hours for newlyonboarded organizations. For projects, the activation latency is up to15 minutes.

• Vulnerability Assessment for Amazon Web Services (AWS) begins scanning the resourcesin an AWS account approximately 15 minutes after the requiredCloudFormation template is firstdeployed in the account. When a software vulnerability is detectedin the AWS account, the corresponding finding becomes available inSecurity Command Center approximately 10 minutes later.

  How long it takes to complete a scan depends on the number of EC2instances. Typically, a scan of a single EC2 instance takes less than5 minutes.

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

• Data Security Posture Management (DSPM) scans cantake up to 24 hours to start after the service is enabled.

Security Command Center runs error detectors, which detect configurationerrors related to Security Command Center and its services. These error detectorsare activated by default and can't be deactivated. Detection latencies varydepending on the error detector. For more information, seeSecurity Command Center errors.

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 for which you are granted access. To learn more aboutSecurity Command Center roles, seeAccess control.

Preliminary findings

You might see some findings in the Google Cloud console while initialscans are taking place but before the onboarding process is complete.

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

Subsequent scans

Changes made within your organization or project, such as moving resourcesor, for organization-level activations, adding new folders and projects,usually won't significantly impact resource discovery timeor the runtime of scans. However, some scans proceed on set schedules, whichdetermine how quickly Security Command Center detects changes.

• Agent Engine Threat Detection (Preview) uses a watcher process to collect event information while the agentic workload is running. The watcher process can take up to one minute to start and collect information.
• Cloud Run Threat Detection uses a watcher process to collect container and event information for the complete duration of a Cloud Run workload. The watcher process can take up to one minute to start and collect information.
• Event Threat Detection and 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: Security Health Analytics runs in real time when turned on and detects new or changed resources in minutes, excluding the detections that are listed later.
• VM Threat Detection: For memory scanning, VM Threat Detection scans each VM instanceimmediately after theinstance is created. In addition, VM Threat Detection scans each VM instance every 30 minutes.
  • For cryptocurrency mining detection, VM Threat Detection generates one finding per process, per VM, per day. Each finding includes only the threats associated with the process that is identified by the finding. If VM Threat Detection finds threats but can't associate them with any process, then, for each VM, VM Threat Detection groups all of the unassociated threats into a single finding that it generates once per each 24-hour period. For any threats that persist longer than 24 hours, VM Threat Detection generates new findings once every 24 hours.
  • For kernel-mode rootkit detection, VM Threat Detection generates one finding per category, per VM, every three days.

  For persistent disk scanning, which detects the presence of known malware, VM Threat Detection scans each VM instance at least daily.

• Vulnerability Assessment for AWS runs scans three times a day.

  How long it takes to complete a scan depends on the number of EC2instances. Typically, a scan of a single EC2 instance takes less than5 minutes.

  When a software vulnerability is detectedin an AWS account, the corresponding finding becomes available inSecurity Command Center approximately 10 minutes later.

• Web Security Scanner: Web Security Scanner runs weekly, on the same day as the initial scan. Because it runs weekly, Web Security Scanner won't detect 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 runon-demand scans to check new or changed resources between scheduled scans.

• DSPM: Findings that are generated by DSPMshow up in near real time on the DSPM dashboard.

Security Command Center error detectors run periodically in batch mode. Batchscanning frequencies vary depending on the error detector. For more information,seeSecurity 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. OnceSecurity Health Analytics is enabled, any relevant resource configuration changesresult 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, forexample, a detection runs against information outside of a resource'sconfiguration. These detections, listed in the following table, run periodically andidentify misconfigurations within 12 hours. ReadVulnerabilities andfindings for more details onSecurity Health Analytics detectors.

Attack path simulations

Attack path simulations run every six hours, approximately. As yourGoogle Cloud organization grows in size or complexity, the timebetween intervals can increase.

When you first activate Security Command Center, the attack path simulations use adefault high-value resource set, which focuses on a subset of the supportedresource types found in your organization. For more information, refer to thelist of supported resourcetypes.

When you start defining your own high-value resource set by creating aresource value configuration, you might see the time between simulationintervals drop if the number of resource instances in your high-valueresource set is significantly lower than the default set.

What's next

• Learn aboutusing Security Command Center in the Google Cloud console.
• Learn aboutdetection services.