Case Deduplication
Case deduplication is the process of automatically identifying and linking related alerts and their observables to an existing case, rather than creating a new case for each alert. This reduces noise, prevents alert fatigue, and provides a consolidated view of an ongoing incident.
The Case Deduplication action relies on defined conditions—such as matching observables (e.g., usernames, file hashes, IP addresses) and their relationships— defined in the Deduplication Rules section to determine if a new alert is part of an existing investigation. When a match is found, the alert and its observables are linked to the existing case, enabling more efficient triage, investigation, and response. If no match is found, a new case is created entirely.
How It Works
-
Duplication Check
-
When an alert is processed, the action first looks for a matching deduplication rule based on the alert name and/or vendor associated with the alert. These rules are defined in the Deduplication Rules Section.
-
These rules specify the criteria for identifying whether an incoming alert should be linked to an existing case.
-
Name-Based Check:
- If the deduplication rule focuses on the alert’s name, the system searches for cases with the same name. If a match is found, it updates the variables to include details from the duplicate case.
-
Observable-Based and/or Relation-Based Check:
- If the rule uses observables (e.g.,
file hashes,IPs,URLs) or observable relations (such as “Source” or “Created By”), the system searches for cases related to those observables or observable relations.
- If the rule uses observables (e.g.,
-
-
-
Linking to an Existing Case:
- If a match is found, the system links the alert and its observables and its relations (if they exist) to the identified existing case. This helps consolidate all related information under one case, making it easier to analyze and respond efficiently.
- The system considers the following during the deduplication check:
- Open cases are always eligible for deduplication.
- Closed cases are considered only if they fall within a defined lookback period, which determines how far back the system searches for duplicates among closed cases.
-
Creating a New Case:
- If no duplicate is found, the system creates a new case. It pulls relevant data from the alert, such as observables and metadata, and structures it into a new case record.
Case Deduplication Action Fields
Case Deduplication Action Fields
| Parameter | Description | |
|---|---|---|
| Alert ID | The Alerts ID | |
| Create a case for unique alerts | When checked, a new case will be created if no duplicate is found. | |
| Case Name | The title of the case. | |
| Case Status | The Current status of the Case - (i.e New, In Progress, Closed). | |
| Case Type | The case type defines the classification or category assigned to the case. | |
| Case Manager | The user or group assigned to handle the case. | |
| Severity | The Case’s severity rank- (i.e Low, Medium, High or Critical) | |
| Inherit highest alert severity | If checked, the case’s severity will automatically update to match the highest severity among newly linked alerts. | |
| Append Alert’s Vendor | If checked the alert’s vendor will automatically be added to the case’s “Vendors” field. |
‘Case Deduplication’ Action Output
When a deduplication match is found, the alert is automatically associated with the appropriate case, helping reduce redundancy and improve investigation efficiency. If no match is found, a new case will be created. The structured JSON output provide output from this action informs downstream workflow steps about how the alert was handled, which case it relates to, and what observables were involved.
JSON outputs are provided for illustrative purposes only. The actual results you see may vary depending on how you have configured the Case Deduplication action and the associated Deduplication Rules.'Case Deduplication' Action Output Example
'Case Deduplication' Action Output Example
Breakdown of the `JSON` Key-Value Pairs
Breakdown of the `JSON` Key-Value Pairs
is_unique: Specifies whether the current alert generated a new, distinct case.
true: No existing cases matched; a new case was created.false: The alert matched an existing case and was deduplicated accordingly.
matched_rule: Indicates whether a deduplication rule was triggered.
true: A deduplication rule matched based on the extracted observables.false: No rule matched, and the alert may continue to new case creation.
rule: The name of the deduplication rule that was triggered. Deduplication rules determine how observables (such as hash, IP, domain) are matched to existing cases.
case: Contains metadata about the case the alert was associated with or resulted in.
name: The name of the case, typically based on the deduplication rule or observable grouping.case_ids: Optional- Related case identifiers, if any.close_reason: Optional- The reason the case was closed.updated_by: The ID of the user or automation that last modified the case.auto_id: An internally incremented identifier used for sorting or indexing cases.id: The system-generated UUID used to uniquely identify the case record.closed_by_automation: Indicates whether the case was automatically closed by a rule or system logic.task_ids: Optional- List of task IDs associated with the case.mitre_attack: Optional- MITRE ATT&CK tactics or techniques linked to the case.closed_by: Optional- ID of the user or system that closed the case.alert_ids: A list of alert IDs associated with this case.attachment_ids: Optional- List of files or artifacts attached to the case.severity: Numerical severity rating of the case.created_by: ID of the user or automation that initially created the case.type: The category or classification of the case, such as “Malware” or “Phishing”.case_tags: Optional- Tags applied for filtering or grouping similar cases.collaborators: Optional- User or team IDs participating in the case.sla_expiry: Optional- SLA expiration timestamp, if an SLA is defined.closed_at: Optional Timestamp indicating when the case was closed.status: The current status of the case, such asNEW,IN_PROGRESS, orRESOLVED.sla: Optional- SLA policy or parameters tied to the case.observable_ids: A list of observables extracted or linked to the case.overview: Optional- High-level narrative or summary of the case context.updated_at: Timestamp of the most recent update to the case.created_at: Timestamp when the case was first created.summary: Optional- Short summary or commentary about the case.case_manager: Optional- ID of the lead responder or case owner.vendors: Optional- Any third-party vendors or integrations relevant to the case. (Reminder- If the ‘Append Alert’s Vendor’ checkbox is checked in the ‘Case Deduplication’ action, the alert’s vendor will automatically be added to the case’s “Vendors” field. )case_id: A human-readable case reference ID (e.g., “INC-00004”) used for display and tracking.
‘Case Deduplication’ Action – Use Case Example
Case Deduplication: Suspicious File Execution Detected Use Case Example
Case Deduplication: Suspicious File Execution Detected Use Case Example
Continued from the, Suspicious File Execution Detected Use Case Example.
Step 4: Create ‘Case Deduplication’ Rule
Before processing alerts, configure a Case Deduplication Rule to prevent duplicate cases from being created for alerts with the same root cause.
This deduplication rule ensures that any new CrowdStrike “FalseExecutableExtension” alert raised within a 15-day window is grouped into an existing case—rather than creating a new one—if that case already contains:
- An alert with the same name (
FalseExecutableExtension), - A Username observable whose relation is Target User, and
- A File Hash observable whose relation is Suspicious File.
When all three conditions are met, Blink will link the incoming alert (and its extracted observables) to the matching case, preventing duplicate investigations for the same user–file combination.
Step 5: The ‘Extract Observable’ action is Executed
This configuration links new alerts to existing cases if they involve the same user and the same suspicious file, which in this case is bart.s executing whoami.rtf.