SPLK-2003 Custom Lists and Data Routing

Custom Lists and Data Routing Detailed Explanation

In security automation, it's not enough to react — you need to make decisions based on your organization's context. Custom Lists and Data Routing help Splunk SOAR do exactly that.

1. Custom Lists

What Is a Custom List?

A Custom List is a user-created dataset stored within Splunk SOAR. These lists can be used by playbooks to:

• Compare values

• Make logic decisions

• Filter or enrich data

They act like reference tables for your automation.

Use Cases

Custom Lists can contain anything that helps classify or act on incoming data.

Examples:

• Approved Domains:

  • List of trusted sender domains.

  • Use it to whitelist known-good email senders.

• Internal IP Ranges:

  • Define which IP addresses belong to your own network.

  • Prevent SOAR from flagging internal devices as suspicious.

• High-Risk Countries:

  • List of geolocations flagged by your threat intel team.

  • If an IP geolocates to a country on the list, trigger escalation.

These lists help make your playbooks context-aware.

Management

To manage custom lists:

1. Go to Administration > Custom Lists in the web UI.

2. Click “Add List”.

3. Name your list (e.g., "KnownBadDomains").

4. Add values — either one at a time or in bulk (CSV upload supported).

Each list can have:

• Single-column values (e.g., just IPs)

• Multi-column values (like name + reason)

Admins can edit lists at any time without editing playbooks.

Data Access

Custom lists are accessible inside playbooks in two main ways:

1. Decision Blocks or Filter Blocks:

• Use list selectors to check if a value appears in a custom list.

• Example:
  “If sender domain is not in ApprovedDomains, continue playbook.”

2. Python Scripting:

• Use Phantom functions to access list contents in a code block.

Example:

phantom.get_list("HighRiskCountries")

This allows custom logic to use lists dynamically.

2. Data Routing

What Is Data Routing?

Data routing is the process of controlling how data moves through SOAR — deciding which playbooks or assets should handle specific types of events or artifacts.

It ensures that the right actions happen at the right time, based on the content and context of each event.

Routing Rules

Routing rules are conditions that determine:

• Which playbook to run

• Which user or team to assign to a case

• Which tags or severity to apply

You define rules in:

• Ingestion settings

• Case creation templates

• Playbooks (via logic blocks)

Example: “If event type is 'phishing', and severity is 'high', run the advanced response playbook.”

Dynamic Routing

Sometimes you can’t define all rules up front. You want playbooks to make real-time decisions based on incoming data.

Examples:

• Route an alert to the Malware Team if the filename ends in .exe.

• Choose Asset A for internal IPs and Asset B for external IPs.

• Use different child playbooks depending on the alert source.

This is called dynamic routing, and it uses:

• Decision blocks

• Filters

• Playbook logic

It adds flexibility and intelligence to your response workflows.

Tags and Labels

Tags and labels are used to help route data and classify it more easily.

• Tags: Free-form keywords added to events, artifacts, or cases.

  • Example: phishing, VIP user, needs escalation

• Labels: Predefined categories applied to containers (e.g., endpoint alert, email alert)

You can:

• Set rules like: “If tag = ransomware, assign to Tier 2”

• Trigger playbooks based on labels and tags

• Filter queues using tags

These are lightweight but powerful tools for directing automation and analyst attention.

Summary

Feature	Purpose
Custom Lists	Store whitelists, blacklists, internal resources, or other reference data
List Use Cases	Whitelist domains, detect risky IPs, block suspicious locations
List Access	Use in filters, decisions, and Python scripts
Routing Rules	Direct data to the right playbook, team, or asset
Dynamic Routing	Make routing decisions at runtime using logic blocks
Tags and Labels	Classify and organize data to control automation paths

Custom Lists and Data Routing (Additional Content)

1. Data Structure Limitations of Custom Lists

Purpose:
To ensure compatibility and reliability when using custom lists in automation logic or API integrations, it's essential to understand how Splunk SOAR handles data structures within custom lists.

Key Constraints:

• Maximum Row Count:

  • There is no explicitly documented hard limit on the number of rows in a custom list. However, for performance reasons, lists with more than 10,000 rows may cause performance degradation during searches or filtering.

• Nested JSON Support:

  • Not supported. Custom Lists are flat structures and do not support nested JSON or hierarchical key-value pairs.

  • Only strings, integers, and flat CSV-like fields are supported.

• Empty Cell Behavior:

  • Empty cells are treated as empty strings. When queried via logic blocks or scripting (e.g., phantom.get_list()), these empty values are still included in the result.

  • If your playbook logic expects non-empty fields, add validation to skip empty rows.

Practical Example:

If a REST API call expects an input like {"domain": "example.com", "type": "CNAME"}, but your Custom List only contains a column "domain", you must either hardcode the "type" or enrich the list using pre-processing code blocks.

Best Practice: Always validate and transform custom list entries in a code block before sending them into an external API or playbook action.

2. Tags and Automation Use Case Extension

Tags are more than just visual labels — they can actively control automation behavior when used strategically.

Advanced Use Cases:

• Auto-Closure Based on Tags:

  • Playbooks can contain logic such as:

    if "auto-close" in container.tags:
        phantom.set_status(container["id"], "closed")
    

  • This is useful for auto-resolving known false positives or duplicate events.

• Trigger Alerts or Notifications:

  • If an event has a tag like "vip" or "compliance-critical", your playbook can:

    • Trigger an escalation workflow.

    • Send an immediate email or Slack message to leadership.

• Activate Conditional Playbooks:

  • You can use tags like "requires_manual_review" to skip certain automation steps or pause execution until an analyst intervenes.

Best Practice:
Design tags not only for filtering in the UI but also as automation flags in decision logic. This enables flexible, tag-driven playbook design.

3. Practical Guide to Dynamic Asset Selection Using Decision Blocks and Parameters

In advanced workflows, analysts often want to dynamically choose which asset to use based on the event context — for example, selecting a different EDR tool for internal vs. external IPs.

Implementation Workflow:

1. Prepare Playbook Input Parameter:

• In a child playbook or a dedicated action block, define a parameter like target_asset.

2. Use Decision Block to Evaluate Input:

• Use logic such as:

  • If IP starts with "10." → Internal → Set target_asset = "CrowdStrike_Internal"

  • Else → External → Set target_asset = "VirusTotal_External"

3. Set Run Data or Input Parameter:

• In a code block:

  if ip.startswith("10."):
     phantom.save_run_data("asset_selection.asset", "CrowdStrike_Internal")
  else:
     phantom.save_run_data("asset_selection.asset", "VirusTotal_External")
  

4. Use Variable in Action Block:

• In the subsequent action block, reference the variable:

  • Asset: {run_data.asset_selection.asset}

Caution:
If you use a variable to dynamically set an asset, ensure the asset name is spelled exactly as defined in SOAR. Misspellings or incorrect references will cause the action to fail.

Summary

Topic	Key Details
Custom List Limits	Flat structure, no JSON, large lists may degrade performance
Automation via Tags	Use tags to trigger auto-close, escalate, or modify flow
Dynamic Asset Routing	Use Decision Blocks + phantom.save_run_data() to select assets at runtime