Alert Processing
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.
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.
The "On New Table Record- Process Alert" consists of all the Subflows created in the Alert Processing section.
The following Subflows make up the entire "On New Table Record- Process Alert" automated Workflow:
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.
For a detailed explanation of the "Subflow 1- Extract Observables", please visit this page
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.
For a detailed explanation of the "Subflow 2- Create Case", please visit this page
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,
For a detailed explanation of the "Subflow 2.1 - Get Deduplication Rule Workflow", please visit this page.
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.
If the “Name” parameter 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.
For a detailed explanation of the "Subflow 2.2- Check for Case Duplicates", please visit this page.
Subflow 2.3- Link Alert to Existing Case
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.
For a detailed explanation of the "Subflow 2.3- Link Alert to Existing Case", please visit this page.
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).
For a detailed explanation of the "Subflow 3-Enrich Observables", please visit this page.
Subflow 4- Responses
Ths subflow is a user-customizable subflow designed to initiate automated responses to alerts and cases.
Please note that it is only triggered after all Observables have been enriched.
For a detailed explanation of the "Subflow 4- Responses", please visit this page.
