Skip to main content

Blink's Automated Case Management

Important Terminology​

  1. Alerts - Incidents generated by 3rd party security systems or through custom detection workflows.

  2. Observables - field of interest extracted from incoming alerts. Examples include IP address, file hash, DNS, or User, Email, etc. Observables are used to identify and correlate multiple alerts as well as measure the risk of the alert.

  3. Cases - A collection of related alerts that are grouped together for investigation and response. Cases help analysts track and manage security incidents more efficiently.

  4. Alert Ingestion - The process of receiving/ingesting alerts from 3rd party sources.

  5. Alert Processing - The process of extracting data such as name, severity and observables from ingested alerts and either creating a new case for the alert or appending the alert to an already existing case.

  6. Enrichment- The process of enriching observables with additional information from 3rd party sources. This may either be threat intelligence to score the risk of the observable (e.g. DNS www.evilabc.com is Malicious), or may be simple enrichment such as providing additional information on the observable (e.g. User ‘John Smith’ works at R&D and reports to ‘Bob Shnider’)

  7. Response- The process of investigating and taking action with regards to the case. This can either be automated or manual. For example, isolating an infected device or automatically closing the case because it’s a ‘False Positive’

Case Management Automated Processes​

Alert Ingestion​

In the Alert Ingestion process, alerts are harvested from external systems, such as SIEMs (Security Information and Event Management) or other monitoring tools, in real time. This step collects raw alert data as soon as it is generated by the vendor. The primary action in this stage is to open an alert record, which stores the received payload for further processing. This is the starting point of the workflow where data enters the system.

Alert Processing​

The Alert Processing phase 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.

Enrichments​

The Enrichment process is designed to enrich and maintain the enrichment of observables. This phase is fully customizable for each customer, allowing adjustments based on their specific toolset and preferred enrichment methods. It consists of vendor-specific subflows, which can be selected or tailored per client.

Response​

The Response process is designed to automate the response process for cases. This phase can be fully customized to suit each customer's specific tools and preferred workflows.

Flow Diagram Showing the Case Management Automated Processes​

Thumbnail

Detailed Guide of Flow Diagram​

This guide 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.

1. Alert Ingestion​

  • Description: This is the entry point where Blink ingests events from third-party systems or monitoring tools.
  • How It Works:
    • Events are received via APIs, webhooks, or file-based ingestion methods.
    • Blink normalizes and stores the raw data to make it compatible with the workflow engine.
  • Data Example:
    {
      "event_id": "12345",
      "source": "SIEM",
      "timestamp": "2024-12-12T12:34:56Z",
      "event_type": "failed_login",
      "details": {
        "user": "admin",
        "ip_address": "192.168.1.1"
      }
    }

2. Alert Processing​

  • Description: Once an alert is created, Blink identifies whether it matches a known alert template and extracts observables for further processing.
  • How It Works:
    • Templates contain pre-defined rules or patterns to categorize alerts (e.g., by severity, source, or type).
    • Observables such as IP addresses, file hashes, or user IDs are extracted for enrichment.
  • Example Template Match:
    If event_type == "failed_login" AND source == "SIEM", THEN categorize as "Login Alert".
  • Extracted Observables:
    {
      "ip_address": "192.168.1.1",
      "user": "admin"
    }

3. Alert Processing: Dedup Check​

  • Description: Blink checks for duplicate alerts and either creates a new case or appends the alert to an existing one.
  • How It Works:
    • A hash or unique identifier is generated for each alert to detect duplicates.
    • If duplicates are found, the alert is appended to an existing case for context.
    • If no duplicates are detected, a new case is created, associating relevant observables and metadata.
  • Data Transformation Example:
    • Input Alert:
      {
        "event_id": "12345",
        "ip_address": "192.168.1.1"
      }
    • Generated Case:
      {
        "case_id": "67890",
        "alerts": ["12345"],
        "status": "Open"
      }

4. Enrichment: Observable Enrichment​

  • Description: Observables are enriched with additional context from internal or external sources.
  • How It Works:
    • Blink queries threat intelligence platforms, databases, or internal systems to gather more information about observables.
    • Examples of enrichment include geolocation data for IP addresses or reputation scores for domains.
  • Enrichment Example:
    • Input Observable:
      { "ip_address": "192.168.1.1" }
    • Enriched Data:
      {
        "ip_address": "192.168.1.1",
        "geo": { "country": "US", "city": "New York" },
        "threat_score": 85
      }

5. Response: Execute Response Workflows​

  • 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:
      {
        "action": "block_ip",
        "target": "192.168.1.1",
        "status": "Success"
      }

Sample Data Flow​

Input:​

{
  "event_id": "12345",
  "source": "SIEM",
  "event_type": "failed_login",
  "details": {
    "user": "admin",
    "ip_address": "192.168.1.1"
  }
}

Output:​

{
  "case_id": "67890",
  "alerts": [
    {
      "event_id": "12345",
      "category": "Login Alert",
      "observables": {
        "ip_address": {
          "value": "192.168.1.1",
          "geo": { "country": "US", "city": "New York" },
          "threat_score": 85
        },
        "user": "admin"
      }
    }
  ],
  "status": "Open",
  "actions": [
    { "action": "block_ip", "target": "192.168.1.1", "status": "Success" }
  ]
}

Example of Case Management Workspace and the Automated Workflow's Processes​

Thumbnail