Overview of the finding lifecycle

Security Command Center and detection services manage findings through the following phases:

  • Detection: Detection services scan your environment to identify potential security problems, including vulnerabilities, misconfigurations, or threats and generate findings.
  • Triage and remediation: You investigate the root cause and address the underlying problem. After you resolve the problem, you can manually change the finding state to INACTIVE, or the detection service might automatically set the finding state to INACTIVE.
  • Mute: To reduce noise during an investigation, you can optionally set the mute state of one or more findings to filter them from default dashboards and notification workflows.
  • Retention: Security Command Center stores findings and snapshots according to data retention policies.

Detection

A detection service identifies a security condition and creates a finding in Security Command Center. Based on the condition, the service defines the finding class. If the detection service doesn't specify a class, the finding class is Finding class unspecified.

When a detection service first generates a finding, it sets the finding state to ACTIVE with the following properties:

  • Event time (event_time): the date and time that the service first detected the finding or last updated information in the finding. To minimize noisy notifications, a service might update the event_time only when there are meaningful changes to the condition that created the finding, such as when it changes the state to INACTIVE.
  • Create time (create_time): the date and time that the detection service created the finding record in Security Command Center.

Security Command Center sets the create_time property automatically, and you can't change it manually. The detection service sets the event_time property initially, and then might update the value when there is a meaningful change to information about the finding.

Triage and remediation

To indicate that you remediated a finding, you can manually set the finding state to INACTIVE.

Some detection services change the finding state automatically. Both the finding type and the behavior of the detection service determine whether the service automatically sets the finding state to ACTIVE or INACTIVE.

If you manually change a finding state to INACTIVE, and the detection service manages the state, it might reset the value to ACTIVE until it identifies that the condition that created the finding has been resolved.

The following sections explain when a detection service might automatically change finding properties.

Vulnerability and misconfiguration findings

Information in this section describes properties of a finding that you might evaluate when investigating vulnerability and misconfiguration findings.

Updates to the event_time property

The event_time indicates when the service first detected the condition or last updated information about the condition.

In a vulnerability or misconfiguration finding, a detection service might update the event_time value when it detects a change to the condition that created the finding and also updates other finding fields. Detection services might not update the event_time with each scan.

Because detection services might not update event_time with each scan, if a detection service changes a finding's state to INACTIVE after a specific active state period, the active state period might not align with the event_time of the finding in Security Command Center.

Some changes to a finding, such as muting a finding and annotating a finding with security marks don't change the finding event_time property.

Security Command Center automatically updates the event_time value every 30 days, if no change has occurred, to help ensure that the finding is returned by queries for recent ACTIVE findings.

Updates to the state property

You can remediate vulnerabilities and misconfigurations by doing one of the following:

  • Fix the condition that caused the finding. For example, close an open firewall port, restrict access to the resource, or apply a patch.
  • Delete the affected resource.

If the service identifies that the problem no longer exists or that the resource no longer exists, it automatically changes the finding state from ACTIVE to INACTIVE.

The time it takes a service to update the finding state depends on several factors, including the following:

For information about how a specific detection service manages finding states, see the documentation for that service.

Threat findings

A threat finding identifies suspicious activity in your Google Cloud environment.

You investigate threat findings, determine a suitable way to remediate the condition, and then manually change the finding state to INACTIVE. Threat detection services don't automatically set the state of a threat finding to INACTIVE. For more information, see Approach to threat finding remediation.

Toxic combination and chokepoint findings

Risk Engine creates Toxic combination and chokepoint findings during periodic attack path simulations. A toxic combination identifies a set of security-related conditions that could result in access to a high-value resource. A chokepoint identifies a resource where multiple attack paths converge.

For more information about how to change a finding to INACTIVE, see Remediating toxic combinations and chokepoints.

Posture violation findings

Posture violation findings identify resource configurations that don't align with your organization's security posture.

For information about how to change the finding state, see documentation specific to the service:

Error findings

Error findings identify problems with the configuration of your Security Command Center environment. Configuration problems prevent detection services from generating findings. Security Command Center automatically changes error findings to INACTIVE when it detects that the configuration problem no longer exists.

Issues

Risk Engine creates issues to identify security risks in your Google Cloud environment.

For information about the lifecycle of the following issue types, see the respective document:

  • For Correlated Threats issues, see the Issue lifecycle section in "Correlated Threats overview".
  • For Toxic combination and Chokepoint issues, see the Issue lifecycle section in "Issues overview".

Mute findings

You can reduce the volume of findings that you review by muting some findings. This hides the findings from default dashboards and the default findings query. Muted findings continue to be available in Security Command Center, and you can query them.

The mute state of a finding (MUTED or UNMUTED) is independent of the finding state. You can mute a finding that also has an ACTIVE state.

You can't mute SCC error findings.

For more information about creating mute rules, see Mute findings in Security Command Center.

For information about how muting a finding affects toxic combinations and chokepoints, see Findings that receive attack exposure scores.

Retention of findings

Security Command Center retains findings and snapshots for a specific period based on the finding class, state, and service tier.

For more information about data retention and deletion policies across resources, see Data and infrastructure security overview.