Cases overview

This document covers the concepts of cases in the Enterprise tier of Security Command Center and explains how to work with them.

Overview

In Security Command Center, use cases to obtain details about findings, attach playbooks to finding alerts, apply automatic threat responses, and track the remediation of security issues.

A finding is a record of a security issue that is generated by one of the Security Command Center detection services. In a case, findings and other security issues are presented as alerts, which are enriched using a playbook that collects additional information. Whenever possible, Security Command Center adds new alerts to existing cases, where they are grouped with other related alerts.

For more details about cases, see Case overview in the Google SecOps documentation.

Findings flow

In Security Command Center Enterprise, there are two flows for findings:

  1. Security Command Center threat findings go through the security information and event management (SIEM) module. After triggering the internal SIEM rules, findings turn into alerts.

    The connector collects the alerts and ingests them into the security orchestration, automation and response (SOAR) module where the playbooks process and enrich the alerts that are grouped into cases.

  2. Security Command Center posture findings, which consist of findings of software vulnerabilities, misconfigurations, and toxic combinations, go directly to the SOAR module. After the SCC Enterprise - Urgent Posture Findings Connector ingests and groups posture findings as alerts into cases, the playbooks process and enrich alerts.

In Security Command Center Enterprise, the Security Command Center finding becomes a case alert.

Investigate cases

During ingestion, findings are grouped into cases to let the security specialists know what to triage.

Multiple findings with the same parameters are grouped into one case. To learn more about the finding grouping mechanism, see Group findings in cases. If you are using a ticketing system, such as Jira or ServiceNow, a ticket is created based on a case, meaning that there is one ticket for all findings in a case.

Finding status

A finding can possess any of the following statuses:

  • Active: The finding is active.

  • Muted: The finding is active and muted. If all findings in a case are muted, the case is closed. To learn more about muting findings in cases, see Mute findings in cases.

  • Closed: The finding is inactive.

The finding status is displayed in the Finding state widget of the Case overview tab and the Finding Summary widget of an alert.

If you integrate with ticketing systems, enable synchronization jobs to keep the information about findings and their statuses up to date automatically and synchronize case data with relevant tickets. To learn more about case data synchronization, see Enable case data synchronization.

Finding severity versus case priority

By default, all findings contained in a case possess the same severity property. You can configure the grouping settings to include findings with different severities into one case.

Case priority is based on the highest finding severity. When the finding severity changes, Security Command Center automatically updates the case priority to match the highest severity property among all findings in a case. Muting findings has no impact on the case priority—if a muted finding possesses the highest severity, it defines the priority of the case.

In the following example, the priority for Case 1 is Critical because the severity of Finding 3 (though muted) is set to Critical:

  • Case 1: Priority: CRITICAL
    • Finding 1, active. Severity: HIGH
    • Finding 2, active. Severity: HIGH
    • Finding 3, muted. Severity: CRITICAL

In the next example, the priority for Case 2 is High because the highest severity for all the findings is High:

  • Case 2: Priority: HIGH
    • Finding 1, active. Severity: HIGH
    • Finding 2, active. Severity: HIGH
    • Finding 3, muted. Severity: HIGH

Review cases

To review a case, take the following steps:

  1. In Security Operations console, go to Cases.
  2. Select a case to review. The Case View opens, where you can find a finding summary along with all information about an alert or the collection of alerts grouped into a selected case.
  3. Check the Case Wall tab for details about the activity performed on the case and included alerts.

  4. Go to the Alert tab to get an overview of a finding.

    The Alert tab contains the following information:

    • List of alert events.
    • Playbooks attached to the alert.
    • A finding overview.
    • Information about the impacted asset.
    • Optional: ticket details.

Integrate with ticketing systems

By default, no ticketing system is integrated with Security Command Center Enterprise.

Cases containing vulnerability and misconfiguration findings have related tickets only when you integrate and configure the ticketing system. If you integrate a ticketing system, Security Command Center Enterprise creates tickets based on posture cases and forwards all information collected by playbooks to the ticketing system using the synchronization job.

By default, cases containing threat findings have no related tickets even when you integrate the ticketing system with your Security Command Center Enterprise instance. To use tickets for your threat cases, customize available playbooks by adding an action or create new playbooks.

Case assignee versus ticket assignee

Every finding has a single resource owner at any given time. The resource owner is defined using Google Cloud tags, Essential Contacts, or the Fallback Owner parameter value configured in the SCC Enterprise - Urgent Posture Findings Connector.

If you integrate a ticketing system, the resource owner is the ticket assignee by default. To learn more about automatic and manual ticket assignment, refer to Assign tickets based on posture cases.

The ticket assignee works with findings to remediate them.

The case assignee works with cases in Security Command Center Enterprise and doesn't triage or mitigate findings.

For example, a case assignee can be a Threat Manager or other Security Specialist who collaborates with an engineer (ticket assignee) and verifies that all alerts in a case are addressed. The case assignee never works with ticketing systems.

What's next

To learn more about cases, refer to the following resources in the Google SecOps documentation: