About Alert Processing
Detailed Explanation of Alert Processing Workflows
9.0
, you should refer to this pageThe 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.
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:
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.
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.
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.