SPLK-1002 Creating and Using Workflow Actions

Creating and Using Workflow Actions Detailed Explanation

Workflow Actions in Splunk enhance interactivity by allowing users to trigger external resources, run scripts, or execute additional searches directly from the search results. This guide will walk you through the details of creating and using Workflow Actions, providing examples and best practices for implementation.

1. What Are Workflow Actions?

Definition

Workflow Actions are custom interactions that you can configure in Splunk to:

• Redirect users to external systems or dashboards.
• Send data to external endpoints for further processing.
• Execute additional searches to drill deeper into your Splunk data.

Purpose

• Enable seamless integration with external systems.
• Provide contextual actions for specific data points in your search results.
• Automate repetitive tasks or enhance troubleshooting workflows.

2. Types of Workflow Actions

Workflow Actions come in three types:

2.1. GET

• Redirects users to a specified URL with field values passed as parameters.
• Use Case: View detailed information in an external system.

Example

Action: Open an external log viewer.

• URL Template:

  http://logs.example.com?ip=$src_ip$
  

• Behavior: Redirects the user to the specified URL, appending the value of the src_ip field.

2.2. POST

• Sends data to an external endpoint for further processing.
• Use Case: Submit data to a REST API or external system.

Example

Action: Report suspicious IPs.

• Endpoint:

  http://api.example.com/report
  

• Fields Sent: src_ip, threat_level.

• Behavior: Submits a POST request with these fields to the specified endpoint.

2.3. Search

• Executes another Splunk search based on field values in the current result.
• Use Case: Drill down into related data within Splunk.

Example

Action: View all logs for a specific user.

• Search Query:

  search user=$user_id$
  

• Behavior: Opens a new search tab with the expanded query.

3. How to Create Workflow Actions

Steps to Create Workflow Actions

1. Navigate to Settings > Fields > Workflow Actions.
2. Click New Workflow Action.
3. Define the following:
   • Name: A descriptive name for the action.
   • Type: Select GET, POST, or Search.
   • URI: Specify the URL, API endpoint, or search query.
   • Fields: Choose which fields from the search results will be used in the action.
4. Save the action.

4. Examples of Workflow Actions

Example 1: GET Action for External Links

• Action Name: View Detailed Logs

• Type: GET

• URI:

  http://logs.example.com/view?session_id=$session_id$
  

• Fields: session_id

• Behavior: Redirects users to a URL that displays detailed logs for the specified session_id.

Example 2: POST Action for Reporting

• Action Name: Report Threat

• Type: POST

• URI:

  http://security.example.com/report
  

• Fields: src_ip, threat_level

• Behavior: Sends a POST request with the specified fields to report a threat.

Example 3: Search Action for Drilling Down

• Action Name: Investigate User Activity

• Type: Search

• Query:

  search index=user_logs user_id=$user_id$
  

• Fields: user_id

• Behavior: Executes a new search to retrieve all logs related to the specified user.

5. Use Cases for Workflow Actions

5.1. Drilling Down for Context

• Use Workflow Actions to drill down into related logs or events for further investigation.

5.2. Integrating with External Systems

• Redirect to external dashboards, APIs, or tools with relevant parameters.

5.3. Automating Incident Response

• Submit suspicious events to an incident response system via a POST request.

6. Best Practices

6.1. Use Meaningful Names

• Choose descriptive names for actions to make their purpose clear.

6.2. Test Thoroughly

• Test Workflow Actions in a staging environment to ensure they behave as expected.

6.3. Restrict Scope

• Limit Workflow Actions to relevant apps or roles to avoid cluttering the user interface.

6.4. Secure API Calls

• For POST actions, ensure that sensitive data is transmitted securely (e.g., use HTTPS).

6.5. Optimize Field Mapping

• Use only necessary fields to keep actions focused and relevant.

7. Practical Exercises

Exercise 1: Create a GET Action

1. Define a GET action to open an external log viewer.

   • Name: Open Log Viewer

   • Type: GET

   • URI:

     http://logs.example.com?log_id=$log_id$
     

   • Field: log_id

2. Task: Verify that clicking the action redirects to the correct URL.

Exercise 2: Create a POST Action

1. Define a POST action to report a suspicious IP.

   • Name: Report Suspicious IP

   • Type: POST

   • URI:

     http://api.example.com/report
     

   • Fields: src_ip, threat_level

2. Task: Verify that the POST request is sent with the correct data.

Exercise 3: Create a Search Action

1. Define a search action to investigate logs for a specific user.

   • Name: Investigate User

   • Type: Search

   • Query:

     search index=user_logs user_id=$user_id$
     

   • Field: user_id

2. Task: Verify that clicking the action initiates a search for the selected user.

8. Advanced Configurations for Workflow Actions

8.1. Using Multiple Fields in a Workflow Action

Workflow Actions can incorporate multiple fields into their definitions, enabling more complex interactions.

Example: GET Action with Multiple Parameters

• Action Name: View Threat Details

• Type: GET

• URI:

  http://security.example.com/details?ip=$src_ip$&severity=$threat_level$
  

• Fields: src_ip, threat_level

• Behavior: Redirects to a URL displaying threat details based on the source IP and threat level.

8.2. Conditional Workflow Actions

You can configure Workflow Actions to appear only for specific conditions, ensuring relevance to the data.

How to Configure Conditions

1. Add conditions during the Workflow Action creation process.
2. Define criteria such as:
   • Field value matches a specific pattern.
   • Field exists or does not exist.

Example: Display Action Only for High Threats

• Condition:

  threat_level="high"
  

• Behavior: The action will only appear for events where threat_level is "high".

8.3. Redirecting to Splunk Dashboards

You can create Workflow Actions that link to specific Splunk dashboards, passing parameters as tokens.

Example: Link to a Dashboard

• Action Name: Investigate User Activity

• Type: GET

• URI:

  /app/my_app/user_dashboard?user_id=$user_id$
  

• Fields: user_id

• Behavior: Redirects to the user_dashboard dashboard, pre-filtered by user_id.

8.4. Executing Searches in Context

Search-based Workflow Actions can trigger contextual searches within Splunk, enabling users to investigate related events.

Example: Drill Down by Host

• Action Name: View Host Logs

• Type: Search

• Query:

  search index=logs host=$host$
  

• Fields: host

• Behavior: Opens a search for all logs related to the selected host.

9. Troubleshooting Workflow Actions

9.1. Workflow Action Not Visible

Cause

• The Workflow Action may not meet the conditions for display.

Solution

1. Check the conditions defined in the Workflow Action configuration.
2. Ensure the relevant field exists in the event data.
3. Verify the Workflow Action's scope (app context and permissions).

9.2. GET or POST Action Fails to Execute

Cause

• The URI may be incorrect or fields may not be passed correctly.

Solution

1. Verify the URI template:
   • Ensure fields are enclosed in $ (e.g., $field_name$).
2. Test the endpoint separately with sample data.

9.3. Search Workflow Action Produces Incorrect Results

Cause

• The query may not properly use field values or the field may be missing.

Solution

1. Test the search query in the Splunk Search bar with sample values.
2. Verify the selected field is present in the search results.

10. Optimization Strategies

10.1. Use Descriptive Action Names

• Ensure that Workflow Actions have meaningful names that reflect their purpose.
• Example: Use Open Threat Report instead of Action1.

10.2. Restrict Scope to Relevant Apps

• Limit Workflow Actions to specific apps or data sources to avoid clutter in irrelevant contexts.

10.3. Test with Sample Data

• Test Workflow Actions on real data to ensure that field values and URIs are correctly passed.

10.4. Use Secure URLs

• For GET and POST actions, ensure sensitive data is transmitted over secure protocols (e.g., HTTPS).

11. Practical Exercises

Exercise 1: Create a GET Action with Multiple Fields

1. Define a GET action for threat investigation.

   • Name: View Threat Analysis

   • Type: GET

   • URI:

     http://analysis.example.com?ip=$src_ip$&severity=$threat_level$
     

   • Fields: src_ip, threat_level

2. Task: Verify that the action redirects to the correct URL with the provided parameters.

Exercise 2: Conditional Workflow Action

1. Define a Workflow Action that only appears for high-severity events.

   • Name: Report Critical Threat

   • Condition:

     threat_level="high"
     

   • Type: POST

   • URI:

     http://api.example.com/report
     

   • Fields: src_ip, threat_level

2. Task: Test the action with sample events and verify that it only appears for high-severity threats.

Exercise 3: Redirect to a Splunk Dashboard

1. Define a GET action to link to a user activity dashboard.

   • Name: Investigate User

   • Type: GET

   • URI:

     /app/my_app/user_dashboard?user_id=$user_id$
     

   • Fields: user_id

2. Task: Verify that clicking the action opens the dashboard filtered by user_id.

Exercise 4: Drill Down with Search

1. Define a search Workflow Action to view host-specific logs.

   • Name: Drill Down by Host

   • Type: Search

   • Query:

     search index=logs host=$host$
     

   • Fields: host

2. Task: Verify that the search is executed with the correct field value.

12. Summary of Key Points

1. Types of Workflow Actions:

   • GET: Redirects to URLs with parameters.
   • POST: Sends data to external endpoints.
   • Search: Executes additional searches in Splunk.

2. Best Practices:

   • Use meaningful names for actions.
   • Test actions thoroughly before deployment.
   • Secure sensitive data in POST requests.

3. Advanced Configurations:

   • Use multiple fields and conditions for dynamic behavior.
   • Integrate Workflow Actions with dashboards and external systems.

Creating and Using Workflow Actions (Additional Content)

1. Role-Based Access Control (RBAC) for Workflow Actions

Although Workflow Actions can be scoped to specific apps or search contexts, controlling visibility based on user roles is crucial for enterprise environments.

How to Control Access by Role:

Splunk uses metadata-based permissions to define who can view, edit, or execute a workflow action.

• Visibility Settings can be configured via:

  • Splunk Web UI under Permissions when creating/editing a workflow action.

  • Or by editing the metadata file directly.

Example Scenario:

Only security analysts should access the “Report Threat” POST action.

Steps:

1. Create the Workflow Action normally.

2. Set permissions so only the security_analyst role can read or execute it.

metadata example:

[]
access = read : [ security_analyst ], write : [ admin ]
export = none

Best Practice:

• Always limit sensitive actions (like external POSTs or internal escalations) to specific roles.

• Prevent unauthorized users from triggering or viewing sensitive data destinations.

2. Secure Handling of GET and POST Actions

Security Concern:

GET actions append data (like usernames, IPs, session tokens) directly to the URL. These values are:

• Visible in browser history

• Stored in web server logs

• Potentially exposed to third parties via URL sharing

Best Practice:

• Avoid passing sensitive or PII (personally identifiable information) via GET parameters.

• Instead, use POST actions to safely encapsulate and transmit data in the request body.

Example:

Avoid:

http://example.com/report?user=$user$&session=$token$

This exposes user/session info in the URL.

Use instead (POST):

POST to http://example.com/report
Payload: { "user": "$user$", "session": "$token$" }

Advanced Alternative:

• Tokenization: If GET must be used (e.g., redirect scenarios), consider replacing sensitive values with short-lived, obfuscated tokens that map to actual values on the server.

Summary of Enhancements

Topic	Description
RBAC for Workflow Actions	Use Splunk metadata permissions to control visibility and execution based on user roles.
Secure GET/POST Usage	Avoid including sensitive data in GET URIs. Use POST or secure tokens for data privacy.