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 toINACTIVE. - 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 theevent_timeonly when there are meaningful changes to the condition that created the finding, such as when it changes thestatetoINACTIVE. - 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:
- The frequency of service scans. Each service scans at different intervals. For information about service scan intervals, see When to expect findings in Security Command Center.
- The time that it takes you to permanently delete a resource. For example, projects remain in a recovery period before permanent deletion. For more information, see Delete a project. A service might not identify that you deleted a resource until the deletion is permanent.
The time that it takes Cloud Asset Inventory to update a resource. Depending on the type of resource, it might take time to update information about the resource.
Updates to Microsoft Azure or AWS resources might take longer than updates to Google Cloud resources. For information, see the following:
A specific time window during which a finding remains
ACTIVE. Some services, such as Vulnerability Assessment for Google Cloud and Artifact Registry vulnerability assessment, retain a finding in theACTIVEstate for a specific time window.
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:
For the security posture service, see Remediate posture findings.
For Compliance Manager, see Monitor your frameworks for compliance.
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.