Alert Ingestion Workflows

Configure how alerts are ingested into Blink’s automated case management pipeline from external sources.

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

Parameter	Description
Name	The name of the Alert
Vendor	The Vendor associated with the alert
Event	The Alert Event
Alert Type	The alert type defines the classification or category assigned to the alert.
Add New Values To The Alert Types List	When checked, a new alert type will be added to the alert types list in the Case Management Settings.
Severity	This is the severity rank of your Case. If you don’t want to 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 Cases	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:

{
  "id": "ind:bc44a7a3e758465f857867dcf4ac8c17:565469335361356727",
  "name": "FalseExecutableExtension",
  "description": "An executable was run with a contradicting file extension",
  "cmdline": "./whoami.rtf",
  "filename": "whoami.rtf",
  "filepath": "/Users/wilder/whoami.rtf",
  "alleged_filetype": "rtf",
  "platform": "Mac",
  "os_version": "Monterey (12)",
  "hostname": "DT-BART-SIMPSON",
  "user_name": "sam.gamgee",
  "md5": "32ff28d4fdb4b244c355d7f8378fa2b1",
  "sha256": "8d3f68b16f0710f858d8c1d2c699260e6f43161a5510abb0e7ba567bd72c965b",
  "severity": 50,
  "tactic": "Defense Evasion",
  "technique": "Masquerading",
  "timestamp": "2024-07-24T15:25:00Z",
  "falcon_host_link": "https://falcon.us-2.crowdstrike.com/activity-v2/detections/..."
}

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:

1. Trigger Type – Event-Based (Polling): The workflow is triggered by polling Wiz every 1 minute for new issues.

2. 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, and severity, 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.