Skip to main content
Blink’s Automated Case Management Process streamlines how security teams ingest, enrich, investigate, and respond to alerts from multiple monitoring tools and 3rd-party sources. By automating these tasks end-to-end, it enables faster and more consistent triage of potential threats. The purpose of Blink’s Automated Case Management Process is to reduce manual overhead, maintain data consistency, and accelerate incident response by connecting alert data with contextual information, enrichment tools, and response actions. This documentation provides a breakdown of each phase in the automated case management pipeline, including data transformations, enrichment logic, response strategies and use case examples.

​
Key Stages

The process is composed of four key stages and is designed to streamline the entire incident handling from alert ingestion to case remediation

​
Flow Diagram Showing the Case Management Automated Processes

The following flow diagram provides an in-depth explanation of how Blink handles alert and case processing, offering insights into each stage of the workflow, associated subflows, data transformations, and examples for testing.

​
Detailed Guide of the Automated Case Management Process - Use Case Example

Blink’s Automated Case Management Process is fully customizable to support a wide range of client requirements, workflows, and tools.
Scenario: CrowdStrike detected a suspicious file /Users/wilder/whoami.rtf being executed as a command, despite its rtf extension suggesting a benign document. This behavior is characteristic of the Masquerading technique, where adversaries disguise executable files using misleading extensions.
Description: This workflow is triggered by a CrowdStrike Webhook Event, initiating the ‘Alert Ingestion’ process automatically upon receiving an event from CrowdStrike. How It Works: Upon receiving a webhook event from CrowdStrike, the workflow performs the following steps:
  • Get Alert Details – Retrieves detailed information about the alert using the configured CrowdStrike connector.
  • Create Alert – Uses the retrieved data to create a new alert record in the Alert Table
  • From there, it proceeds to the next stage in the pipeline—Alert Processing, where additional alert analysis and case handling actions are performed.
Once the alert is recorded in the Alert Table, Blink continues the investigation by extracting meaningful data and observables.

​
Create Observable Extraction Rules

  • Description: Observable Extraction Rules are configured to define which data fields from the alert payload should be extracted and classified as observables and relations(if they exist).
  • How it Works: These rules look into the alert’s structured data (JSON format) and match specific fields, such as agent_id, user_name, sha256, etc. Each extracted observable is then assigned a type (e.g., IP address, file hash) and a relation to the alert (e.g., Target Host, Attacker IP). This mapping helps define the scope of the threat and gives investigators a clearer view of how entities are related.
In the following example, the following observables and its relations are defined in the Observable Extraction Rules:
Note: Not all extracted observables will have observable relations, and defining such relationships is not mandatory. However, when relations exist—such as a file being associated with a specific IP address or command execution—these will be automatically extracted and identified as part of the process. This helps build a clearer picture of the attack chain and supports better investigation and response.

​
Execute the Extract Observable action

  • Description: The Extract Observable action automatically identifies and stores key observables based on the configured rules.
  • How it works:This action runs the extraction logic and outputs matched observables along with their context and relationships. The observables are stored in the Observables Table and are available for further enrichment or case correlation.

​
Create Deduplication Rules

  • Description: Deduplication Rules define how Blink identifies alerts that are likely part of the same incident. These rules help avoid duplicate case creation and ensure incident responders have full context.
  • How It Works: For every alert, Blink applies pre-defined or custom deduplication logic using key fields (such as filename, hash, host, tactic/technique). These rules match patterns across similar alerts to decide whether to group them into a single case.

​
Execute the Case Deduplication action

  • Description: Blink checks whether the current alert matches an existing case using deduplication logic. It then decides to either create a new case or append the alert to an existing one.
  • How It Works:
    • A deduplication rule (like False Executable) is applied to the incoming alert.
    • If the alert matches an existing case, it is added to that case, updating the case’s observable and alert lists.
    • If no match is found, a new case is created and populated with observables, alerts, and other metadata like severity, case type, and ID.
Description: This stage enriches any newly extracted observables to provide analysts with additional context during investigation.How It Works:
  • This stage takes newly discovered observables listed in the new_observables field (as seen in the output from the Extract Observables step).
  • Each observable’s type is automatically detected. In this example, the Agent Device observable type is detected.
  • Observables are passed to the Enrich Observables- Main Router, which dynamically routes them to the appropriate enrichment logic based on their type.ֿ
  • The corresponding enrichment actions are then executed—each tailored to the specific observable type.
  • the results are appended to the observable metadata and made available in the case for analyst review.
In the provided example, the Enrich Observables- Main Router is configured to handle various observable types through conditional logic:
  • The observable with type Device Agent ID (e.g., cdd5be18804244df8b849069294563e4) triggers the first case in the switch logic.
  • This routes the observable to the CrowdStrike enrichment step (Enrich - Agent ID - CrowdStrike) to retrieve relevant device data.
Additional cases (not shown here) can be configured for usernames, file hashes, domains, and more. This approach ensures observables are enriched consistently and automatically, without requiring hardcoded paths for each case.
  • Description: Blink triggers automated workflows to respond to the alert.
  • How It Works:
    • Workflows include actions such as blocking an IP, disabling a user account, or notifying a security team.
    • Response steps are configured based on the severity and type of the alert.
Response Example:
  • Triggered Action: Block IP address “192.168.1.1” via firewall.
  • Workflow Execution Log: