v9.0
The alert processing phase is a critical first step in transforming raw, incoming alerts into structured, actionable intelligence. It begins by leveraging predefined templates—configured in the Observable Extraction Rules section—to extract key observables such as IPs, URLs, file hashes, and usernames from the alert payload. These observables provide the foundation for understanding and responding to potential threats. The system then determines whether the alert has already been handled to avoid duplication. If the alert is new, it’s flagged for further investigation, enrichment, and response. This process ensures alerts are triaged efficiently, consistently, and with minimal noise—enabling security teams to focus their attention where it matters most.
Flow Diagram Showing the Alert Processing Phase
On New Table Record- Process Alert
This is the parent workflow that orchestrates the entire lifecycle of a security alert. It begins with alert ingestion from 3rd party services, applies intelligent deduplication logic to prevent alert fatigue, enriches the alert with context from internal and external data sources, and then drives automated or semi-automated response actions. By coordinating these phases — triage, deduplication, enrichment, correlation, and response — this workflow reduces manual effort, improves consistency in decision-making, and accelerates time to resolution. It also supports branching logic for exception handling, such as missing templates or failed extractions, ensuring alerts are never dropped silently.
‘Extract Observables’
This action initiates the alert processing workflow by analyzing the raw alert payload and extracting key observables such as IP addresses, URLs, file hashes, hostnames, and usernames. These observables serve as the building blocks for understanding the alert and are essential for all downstream enrichment and response actions.To view all available observable types, navigate here.
For step-by-step guidance on troubleshooting the Extract Observables action, visit the Troubleshooting section.
Subflow- Daily Missing Template Report
This step only runs the Subflow -Daily Missing Template Report if the Extract Observables action fails. The purpose of this subflow is to notify the user when Blink is unable to extract observables from the alert. It helps ensure visibility into potential misconfigurations or unexpected alert formats.
‘Case Deduplication’
This action determines whether an incoming alert should be linked to an existing case or if a new case needs to be created, based on the configured Deduplication Rules. It ensures that alerts are efficiently grouped or separated, helping to streamline case management and avoid unnecessary duplication.
Enrich Observable- Main Router
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 steps are triggered based on the type of observable (Users, Devices, or Observable).
Responses- Main Router
Ths subflow is a user-customizable workflow designed to initiate automated responses to alerts and cases.Note: This subflow is only triggered after all Observables have been enriched.
