SPLK-2003 Introduction to Playbooks

Introduction to Playbooks Detailed Explanation

In Splunk SOAR, playbooks are the heart of automation. They help your security team respond to threats quickly, consistently, and accurately without having to do everything manually.

If SOAR were a factory, playbooks would be the assembly line — taking in security events and pushing them through a series of logical, automated, and human steps.

1. What is a Playbook?

A playbook is an automated workflow that defines exactly what should happen when a security event or case occurs.

Instead of having an analyst:

• Manually look up an IP address,

• Search a firewall log,

• Ask a team member for permission to block it...

...a playbook does these tasks automatically, following a predefined structure.

2. Core Concepts of Playbooks

a. Trigger

The trigger is what causes the playbook to start. It answers the question:
“When should this playbook run?”

Examples:

• When a new event is received (e.g., from Splunk).

• When a case is created or its severity changes.

• When a user manually clicks "Run Playbook".

Playbooks can run automatically or be triggered manually by analysts.

b. Actions

Actions are the actual steps that the playbook performs. They usually involve calling an asset to interact with an external tool.

Examples:

• Query VirusTotal to get the reputation of a file hash.

• Block an IP using a firewall.

• Disable a user in Active Directory.

These actions are powered by apps and assets that you’ve already set up in SOAR.

c. Decisions

A decision is a logic block that helps the playbook make choices based on information.

Examples:

• “If the IP reputation score is above 80, then mark as malicious.”

• “If email sender domain is not whitelisted, escalate the case.”

Decisions allow your playbook to follow different paths depending on results.

Think of this like a series of if-then-else conditions in code — but often built using visual blocks.

d. User Prompts

Sometimes automation can’t decide everything. You may want an analyst to approve or provide input before taking action.

Examples:

• Prompt: “Do you want to quarantine this device?”

• Prompt: “Select severity level based on the available info.”

User Prompts:

• Pause the playbook until a user responds.

• Can include dropdowns, text boxes, or Yes/No choices.

• Can be assigned to specific users or roles.

This enables human-in-the-loop decision-making.

3. Types of Playbooks

Splunk SOAR supports different scopes of playbooks, depending on how and where they should be used.

a. Global Playbooks

• Can be used across any container, case, or event type.

• Designed to be reusable and universal.

• Example: A global playbook for enriching IP addresses.

Use these when your workflow applies to many situations.

b. Local Playbooks

• Tied to a specific use case, container type, or asset configuration.

• Example: A phishing playbook that uses a specific VirusTotal asset and email source.

Use these when you need narrow, context-specific workflows.

4. Benefits of Playbooks

Why are playbooks such a big deal? Because they bring these three major advantages:

a. Consistency

• Playbooks run the same process every time.

• No steps are skipped or forgotten.

• This ensures every analyst (no matter their skill level) follows the same procedure.

b. Speed

• Automation can handle repetitive tasks much faster than humans.

• This reduces time-to-containment — which is critical during active incidents.

• Playbooks can run 24/7 without fatigue.

c. Auditability

• Every step taken by a playbook is logged and time-stamped.

• Helps with:

  • Post-incident analysis

  • Compliance audits

  • Training reviews

You can clearly see what was done, when, and by whom — even if it was automated.

Summary

Component	Description
Trigger	What causes the playbook to start
Actions	Steps performed by the playbook using external tools
Decisions	Logic that controls which path the playbook follows
User Prompts	Analyst inputs requested during automation
Global Playbooks	Reusable across all use cases
Local Playbooks	Designed for specific scenarios or configurations
Key Benefits	Speed, consistency, transparency in incident response

Introduction to Playbooks (Additional Content)

1. Trigger Types: Automatic vs. Manual

While it's already known that playbooks in Splunk SOAR can be triggered either automatically or manually, it's important to clearly distinguish how and when each method is used.

Automatic Triggers:

• Playbooks can be set to run automatically based on:

  • Event type (e.g., phishing, malware)

  • Tags (e.g., VIP, ransomware)

  • Data properties (e.g., severity level or specific field values)

These triggers are defined in automation rules and are useful for consistent and immediate response.

Manual Triggers:

• Analysts can manually run a playbook from:

  • The Investigation Page

  • The Case View

  • The Playbook Library

Manual execution is often used in:

• Human-in-the-loop workflows

• Testing

• Secondary investigations

Clarifying Sentence:

“Automatic triggers are configured based on event types, tags, or conditions, while manual triggers are typically used when analyst judgment or review is required.”

Exam Relevance:

Questions may ask:

• Which playbook trigger method is most appropriate for triaging alerts with dynamic severity?

• Correct answer: Manual

2. Relationship Between Assets and Actions in Playbooks

Playbooks consist of actions, which are powered by apps and executed via configured assets.

Key Concept:

• Actions (e.g., block IP, lookup domain) are provided by SOAR apps.

• Assets are the specific, configured instances of those apps (including API keys, IPs, and authentication credentials).

Failure Condition:

If a required asset is:

• Not configured, or

• Lacking proper permissions, or

• Experiencing connection issues,

Then the action block in the playbook will fail at runtime.

Clarifying Sentence:

“If the asset associated with a playbook action is missing or misconfigured, the action may fail, interrupting the playbook’s execution.”

Exam Relevance:

Common question type:

• Why did the ‘block IP’ playbook step fail?

• Correct answer: Asset misconfiguration or connection failure.

3. Playbook Execution Logs and Troubleshooting

While this detail may not be emphasized in user-facing documentation, understanding where to check logs is essential for troubleshooting.

Log File Location:

• The primary log for playbook execution is:

  /var/log/phantom/playbook.log
  

• It records:

  • Block-level execution results

  • Input/output data

  • Errors and tracebacks

Usage:

• Used by developers and analysts to diagnose failed steps

• Can be combined with phantom.debug() output for in-depth inspection

Clarifying Sentence:

“Playbook execution activity is logged in /var/log/phantom/playbook.log, which provides detailed insight into block performance and failure causes.”

Exam Relevance:

Potential question:

• Where can an analyst view playbook-level errors if the execution result is not as expected?

• Correct answer: /var/log/phantom/playbook.log

Summary

Topic	Clarification
Trigger Type Usage	Automatic is data-driven; manual is analyst-controlled
Asset Dependency	Unconfigured or failed assets will cause action failures
Log Location	Playbook logs are stored in /var/log/phantom/playbook.log