SPLK-2003 Customizations

Customizations Detailed Explanation

Customization is what makes Splunk SOAR powerful and flexible. It allows you to adjust the platform to fit your workflows, your data, and your team’s preferences — instead of forcing you to use a rigid system.

Three main types of customization:

1. Interface Customizations

2. Automation Customizations

3. Integration Points

1. Interface Customizations

These changes affect how users see and interact with SOAR through the user interface (UI).

Custom Fields

• You can add custom fields to:

  • Events

  • Artifacts

  • Cases

Example: If your SOC tracks asset location, you could add a field called “Region” or “Business Unit”.

These fields can be:

• Text fields, dropdowns, checkboxes, or numbers.

• Required or optional.

• Used in searches, filters, reports, and dashboards.

Custom Layouts

You can change where and how fields appear on the screen.

• Rearrange panels on event/case pages.

• Group related fields together.

• Hide or show fields depending on the case type or user role.

This helps analysts focus on what matters most to them.

Themes and Branding

Organizations often want the platform to reflect their identity.

• You can change the logo, color scheme, and login page text.

• This is especially useful for:

  • MSSPs (Managed Security Service Providers)

  • Companies using SOAR as part of a larger SOC suite

2. Automation Customizations

These let you extend or enhance automated behavior to better fit your playbooks, tools, and decision-making logic.

Custom Actions

Sometimes the out-of-the-box actions provided by apps aren’t enough. In that case, you can write your own custom actions using Python.

• These actions are added to apps or playbooks.

• Can perform:

  • Advanced logic

  • API calls to internal tools

  • Data transformation

Example: A custom action that checks an internal vulnerability scanner before deciding to isolate a host.

Dynamic Menus

Dynamic menus are used in user prompts (interactive blocks in playbooks).

• Instead of a static list (e.g., "Yes / No"), the menu pulls data from inside SOAR or from an external system.

• Example sources:

  • Asset list

  • Threat levels

  • Available user groups

This makes analyst input smarter and context-aware.

Event Tags and Labels

Tags help you classify and organize events automatically.

• Example Tags: “phishing”, “malware”, “internal”, “VIP user”

• Tags can be applied:

  • Manually by analysts

  • Automatically by playbooks or ingestion rules

• Tags can trigger playbooks:

  • “If an event is tagged ‘ransomware’, run the ransomware response playbook”

Think of tags as shortcuts to smart automation.

3. Integration Points

Custom integrations allow SOAR to talk to your internal tools, even if they’re not supported natively.

Customize REST Endpoints

Splunk SOAR has a built-in REST API. But in some cases, you can:

• Extend existing endpoints

• Create new routes to expose your own data or workflows

This is useful for teams building custom dashboards or internal tools that need to push or pull data from SOAR.

Add Webhooks for External Alerts

You can create custom webhooks to allow external systems (like firewalls, ticketing tools, or SIEMs) to send data directly to SOAR.

• Example: A firewall detects a suspicious connection → Sends alert via webhook to SOAR → SOAR opens a case and triggers playbooks.

Webhooks are simple and fast ways to enable event ingestion without needing a full app.

Summary

Customization Area	What You Can Do
Custom Fields	Track extra data on cases, events, or artifacts
Custom Layouts	Reorganize how data appears in the UI
Branding	Apply company logos and colors
Custom Actions	Write Python code to add new logic or integrations
Dynamic Menus	Create intelligent, context-aware dropdowns in prompts
Event Tags	Use tags to classify and trigger automation
REST Extensions	Add custom APIs for internal system integration
Webhooks	Accept real-time data from external alerting systems

Customizations (Additional Content)

1. Dynamic Menus – Data Source Types

Dynamic menus enhance user prompts by providing context-aware dropdowns based on live data. Unlike static lists, dynamic menus are populated at runtime.

Supported Data Sources:

• Internal SOAR Objects:

  • Assets (e.g., list of configured VirusTotal or Splunk instances)

  • User Groups / Roles (e.g., show “SOC Tier 1”, “SOC Tier 2” options)

  • Labels or pre-existing artifacts within the container

• External Systems:

  • Custom REST API calls (via playbooks or app actions)

  • Threat intel platforms

  • Configuration management databases (CMDBs)

This flexibility allows analysts to select from current and valid entries, reducing human error and enhancing automation precision.

Exam Tip:

“Which of the following is not a valid source for dynamic menu population in SOAR?”

Incorrect option trap: “Only hardcoded dropdown values are allowed”

Correct understanding:
Dynamic menus can pull from assets, user groups, API calls, or any queryable data source via playbook logic.

2. Where Are Custom Fields Created?

Custom fields allow SOAR to capture additional metadata for:

• Cases

• Events (containers)

• Artifacts

How to Create:

• Via Web UI:

  • Navigate to: Administration > Custom Fields

  • Define:

    • Field name and type (text, dropdown, checkbox, etc.)

    • Field scope (case, artifact, event)

    • Default values, validation rules, and required status

• NOT required via code:

  • No need for YAML or scripting; this is GUI-driven

Exam Tip:

“Can custom fields only be created via code or API?”

Correct answer: No. They can be created and managed through the Admin UI.

“Are custom fields limited to cases?”

Correct answer: No. They can be used on containers, artifacts, or cases depending on configuration.

3. Webhook vs. REST API – Key Differences

These two integration mechanisms serve different purposes. Many exam questions test your ability to distinguish between them in context.

Feature	REST API	Webhook
Type	Active (poll or push)	Passive (waits for events)
Direction	Client sends requests to SOAR	External system sends data to SOAR
Use Case	Query case status, run playbooks, fetch artifacts	Receive alerts from firewalls, SIEMs, third-party systems
Auth	Token-based or session-based	May use shared secrets or IP allowlists
Common Use	Data sync, app integrations	Real-time alert ingestion

Simple Summary:

REST API = SOAR asks or tells something

Webhook = SOAR listens for something

Exam Tip:

“Which mechanism is best suited for receiving immediate alerts from an external tool?”

Correct answer: Webhook

“Which integration type allows SOAR to pull asset configuration details on demand?”

Correct answer: REST API

Summary

Topic	Key Insight
Dynamic Menu Sources	Can pull from SOAR assets, users, and external APIs
Custom Field Creation	Done via UI by Admins; no scripting required
REST vs. Webhook	REST = active interaction; Webhook = passive data reception