If you are using Case Management version 9.0, you should refer to this page

The Alert Processing process extracts key observables from raw alert data using predefined templates in the Alert Templates Table. The system checks whether each alert has already been processed and flags unprocessed alerts for further attention, ensuring efficient and accurate data handling.

TIP: We recommend leaving these workflows unchanged to prevent potential errors in the future.

​
Flow Diagram Showing the Alert Processing Phase

​
On New Table Record- Process Alert

This workflow handles the complete lifecycle of an alert, from its ingestion and processing to response actions, aiming to streamline alert triage, deduplication, enrichment, and response.

INFO

The following Subflows make up the entire “On New Table Record- Process Alert” automated Workflow:

  1. Subflow 1- Extract Observables
  2. Subflow 2- Create Case
  3. Subflow 2.1- Get Duplication Rule Workflow
  4. Subflow 2.2- Check for Case Duplicates
  5. Subflow 2.3- Link Alert to Existing Case
  6. Subflow 3-Enrich Observables
  7. Subflow 4- Responses

​
Subflow 1- Extract Observables

Using specific templates from the Alert’s Template Table, this subflow parses the alert’s raw data to identify observables—data points like IPs, URLs, and file hashes that represent key entities in the alert.

​
Subflow 2- Create Case

This subflow is responsible for deciding whether the alert should be linked to an existing case or if a new case needs to be created.

​
Subflow 2.1- Get Duplication Rule Workflow

This Subflow identifies the best deduplication rule for an alert based on a priority hierarchy. It starts by looking for a specific rule linked to the alert in The Deduplication Table. If no specific rule is found, it will then search for a universal rule for the vendor. If there’s no universal rule available, it will create one using “Name” as the default deduplication parameter.

​
Subflow 2.2- Check for Case Duplicates

This subflow identifies if the alert has any duplicates in any open case or in a case that has been closed . If duplicates are found, it provides the case ID, flags whether the case should be reopened, and if no duplicate exists.

NOTE

  • If the “Name” paramater is selected as a deduplication parameter, it will cancel any other parameter and be used exclusively for the deduplication.

  • If multiple observables are valid for deduplication (e.g., the deduplication parameter is “User” and multiple users are linked), the first case found will be used. If there are multiple cases, the most recently updated one will be selected.

This subflow links the alert, along with its associated observables, to the identified case. It also updates the case severity to match the alert’s severity if the alert’s severity is higher.

​
Subflow 3-Enrich Observables

This subflow is designed to identify observables that have not yet been enriched and perform the necessary enrichment tasks. It systematically processes each observable, ensuring that the correct subflows are triggered based on the type of observable (Users, Devices, or Observable).

​
Subflow 4- Responses

Ths subflow is a user-customizable subflow designed to initiate automated responses to alerts and cases.

NOTE

Please note that it is only triggered after all Observables have been enriched.