Alert Ingestion Workflows
Alert ingestion workflows are event-based workflows which are set up to trigger in real-time, meaning it responds as soon as an alert is available. It can be activated either by a webhook event (an automatic push from the vendor’s system) or by polling (Blink’s system periodically checks for new alerts). This setup allows the workflow to immediately capture alerts as they happen, maintaining continuous, up-to-date alert monitoring. Once triggered, it creates an alert record in Blink’s Case Management, obtaining or logging the alert payload as received from the selected vendor.
Alert Ingestion Workflows Structure
Each alert ingestion workflow consists of one or two key steps:
Event-Based Trigger: Initiates the workflow when a new alert is detected, either via webhook or polling. Webhooks provide real-time notification without delay, while polling ensures alerts are retrieved on a regular schedule if webhooks are not available.
Alert Retrieval (Optional): In some cases, the initial event does not include all necessary alert details. When this happens, an additional API call is made to the vendor’s platform to retrieve the full alert payload. For example, with integrations like CrowdStrike, the webhook only provides a reference ID, requiring a follow-up request to gather complete alert information.
Create Alert: Once the alert data is collected, this step creates a new alert record within Blink’s Case Management system, ensuring the alert is properly logged for tracking, investigation, and response.
Create Alert Action Fields
Create Alert Action Fields
Parameter | Description |
---|---|
Name | The name of the Alert |
Vendor | The Vendor associated with the alert |
Event | The Alert Event |
Severity | This is the severity rank of your Case. If you dont want use the built in severity levels, you can map severity values from an incoming alert payloads to Blink’s system severity levels (e.g., ‘10’ → ‘Low’). Use the mapping settings in Advanced Settings. |
Link Cased | The Name and ID of the Case you want to add to this Alert to |
Description | A brief explanation explaining the Alert |
Custom Fields (JSON Format) | Add a Custom Field in JSON format. Please note that this applies only if you have manually added a custom record column to the subject table. |
Advanced- Dedup Table | The selected table to evaluate the duplicated condition (Dedup Condition)against. |
Advanced- Dedup Condition | The duplicate condition to check whether to insert the record or not. When the condition is met, the record will not be inserted. |
Advanced- Linked Observables | The Name and ID of the Observable you want to link to this Alert |
Advanced- Linked Alerts | The Name and ID of the Alert you want to link to this Alert. |
Advanced- Linked Attachments | The Name and ID of the Attachment you want to link to this Alert. |
Advanced- Linked Tasks | The Name and ID of the Tasks you want to link to this Alert. |
Advanced- Default Severity | Default severity for un-resolved severities. |
Advanced- Low Severity Mapping | A comma-separated list of vendor-specific severity values that map to Blink’s Case Management’s Low severity level. |
Advanced- Medium Severity Mapping | A comma-separated list of vendor-specific severity values that map to Blink’s Case Management’s Medium severity level. |
Advanced- High Severity Mapping | A comma-separated list of vendor-specific severity values that map to Blink’s Case Management’s High severity level. |
Advanced- Critical Severity Mapping | A comma-separated list of vendor-specific severity values that map to Blink’s Case Management’s Critical severity level. |
Mapping Alert Severity to Blink’s System
Different security tools often report severity using their own scales—numeric values, labels, or custom levels. To ensure consistent prioritization in Blink, you can map these varying severity values, in the advanced settings of the Create Alert action, to Blink’s standardized severity levels (Low=1, Medium=2, High=3, Critical=4). For Example:
Example Payload:
In the Severity Parameter:
The incoming alert payload specifies a severity of 50
.
In Advanced Settings:
A severity value of 50
is mapped to Blink’s High severity level, which corresponds to a severity rank of 3
in the output.You can customize these mappings to ensure external alert severity levels align with your internal triage and prioritization standards.
Blink’s severity levels are ranked as:
- Low =
1
- Medium =
2
- High =
3
- Critical =
4
Example of an Alert Ingestion Workflow
The alert ingestion workflow for Wiz, as shown in the image, follows this logic:
-
Trigger Type – Event-Based (Polling): The workflow is triggered by polling Wiz every 1 minute for new issues.
-
Step – Create Alert:
Once a new issue is detected from Wiz:
- It captures the full payload of the issue.
- Extracts relevant fields like
name
,event
, andseverity
,vendor
etc. See Create Alert Action Fields table for all fields extracted. - Sets the alert type as “Network Intrusion” and identifies Wiz as the vendor.
- Creates a new alert record in Blink’s Case Management system with the status marked as “Unprocessed,” meaning it will proceed to further processing stages (i.e.,observable extraction, case deduplication, enrichment and response).
This setup ensures that any security issue reported by Wiz is automatically captured and logged in the case management system with essential metadata, ready for follow-up processing and response.