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.
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.
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.
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 IOCs).
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.
