# Deployment, Installation, and Initial Configuration ### 1. Deployment Options Think of **deployment** like choosing how and where you want to "set up and run" Splunk SOAR. Different organizations have different needs — some are small teams, some are large corporations — so Splunk SOAR supports multiple deployment models. #### a. Standalone Deployment This is the **simplest way** to install SOAR. It's like putting everything in one box. - **What it means**: The user interface (what people interact with), the engine (which runs playbooks), and the database (which stores information) are all installed on the **same server**. - **Who it’s for**: Small teams, training labs, or people who want to try out SOAR. - **Pros**: - Easy to set up. - Less hardware needed. - **Cons**: - Doesn’t scale well. - If the server crashes, everything goes down. **Example**: Imagine you're a security team of 3 people. You don’t need a big setup, just one VM (Virtual Machine) running Splunk SOAR is enough. #### b. Distributed Deployment This is more advanced. Instead of one big box, you have **separate smaller boxes** doing different jobs. - **What it means**: The user interface (UI), automation engine (which runs playbooks), and database are installed on **different servers**. - **Who it’s for**: Medium to large organizations, especially those who have many users or a high volume of security alerts. - **Pros**: - Can handle more users and more data. - If one part crashes (like the UI), other parts may keep running. - **Cons**: - More complex to set up. - Needs more servers and management. **Example**: A company with 100+ security alerts every day might install: - UI on Server A - Engine on Server B - Database on Server C This way, each component can be optimized. #### c. Cloud Deployment Some companies don’t want to manage physical servers. They prefer the **cloud**. - **What it means**: You install SOAR on a cloud service (like AWS, Azure, Google Cloud), or use **Splunk Cloud**, where Splunk manages it for you. - **Who it’s for**: Teams that use cloud environments or want to avoid managing hardware. - **Pros**: - Flexible and scalable. - Can grow or shrink based on need. - No physical maintenance. - **Cons**: - May require cloud knowledge (e.g., AWS EC2 setup). - Cloud costs can grow over time. **Example**: A company running most of its systems on AWS might install SOAR on an AWS EC2 instance, with data stored in cloud databases. ### 2. Installation Methods Once you’ve chosen **how you want to deploy** Splunk SOAR (standalone, distributed, or cloud), the next step is: **how do you actually install it?** There are different ways to install SOAR depending on your environment and experience. #### a. Using OVA Images This is the **easiest method** if you’re using virtualization platforms like VMware. ##### What is an OVA? An OVA (Open Virtual Appliance) is a **pre-built virtual machine image**. Think of it like a ready-to-use machine with SOAR already installed on it. ##### When to use: - You’re using VMware or VirtualBox. - You want a quick start (e.g., for testing or training). - You don’t want to manually configure Linux. ##### Steps: 1. Download the OVA file from Splunk. 2. Import it into your virtualization software (e.g., VMware Workstation). 3. Start the virtual machine. 4. Access the web interface (via browser) using the VM’s IP address. 5. Follow the setup wizard to finish the configuration. ##### Pros: - Fast and easy. - No need to install Linux or dependencies. ##### Cons: - Not suitable for production in many environments. - Limited flexibility in customizing system resources. #### b. Manual Linux Installation This method gives you the **most control**, but it’s more technical. ##### What it means: You manually install SOAR on a Linux server (usually CentOS, RHEL, or Ubuntu), set up all system requirements, and then install the SOAR software. ##### When to use: - You’re preparing a **production** environment. - You want to control how everything is installed. - You’re experienced with Linux systems. ##### Typical Steps: 1. **Install Linux OS** (on physical or virtual server). 2. **Install dependencies**: - Python (usually 3.x) - PostgreSQL - Required libraries (like libxml2, libxslt, etc.) 3. **Download the SOAR installer script** from Splunk. 4. **Run the installer** with root or sudo privileges. 5. **Configure firewall**, hostname, static IP, etc. 6. **Access the web interface** to complete setup. ##### Pros: - Fully customizable. - Good for real-world production environments. ##### Cons: - Takes more time and Linux skills. - Errors in setup can be harder to troubleshoot for beginners. #### c. Automated Scripts Splunk provides **installation scripts** that help you skip many manual steps. These scripts automatically install required packages and configure the SOAR system. ##### When to use: - You want something faster than manual, but more flexible than OVA. - You’re setting up a **standard deployment** on a supported OS. ##### How it works: 1. Download the **automation script** from Splunk (often a `.sh` file). 2. Run it on a clean Linux machine. 3. The script installs all dependencies, downloads SOAR, and starts the services. 4. You finish configuration via the web interface. ##### Pros: - Much faster than manual install. - Still flexible enough for real environments. ##### Cons: - You need internet access on the server. - Some control is given up compared to manual installation. ### 3. Initial Configuration Once you’ve finished installing Splunk SOAR—whether through an OVA, manual Linux install, or automated script—the system isn’t ready to use just yet. You need to go through some **initial configuration steps** to make the system secure, accessible, and functional. #### a. Configure Network Settings When SOAR first boots up, you need to make sure it has a proper identity on your network. ##### Key Tasks: - **Set a static IP address**: - Prevents the server’s IP from changing unexpectedly (important for DNS, firewalls, and access). - **Set the hostname**: - Choose a name that identifies the server, like `soar.yourcompany.local`. - **Configure DNS**: - So the SOAR server can resolve domain names for cloud services and threat intel lookups. - **Check gateway and subnet settings**: - Ensure the server can communicate with the internet and other systems. ##### How: - For OVA-based installs, you can usually log in via terminal and use `nmtui` or `nmcli`. - For Linux-based installs, edit the `/etc/network/interfaces` or use `NetworkManager`. #### b. Set System Time and Timezone Why this matters: - SOAR logs all activities (alerts, playbook actions, user comments). - If your system time is incorrect, your **investigation timelines** and **log data** will be wrong. ##### Steps: - Use the Linux command `timedatectl` to set the correct timezone (e.g., `timedatectl set-timezone America/New_York`). - Make sure the system is syncing time using NTP (Network Time Protocol). - Test this by running `timedatectl status`. #### c. Install SSL Certificates (Optional but Recommended) SSL ensures that when you access SOAR via web browser (https://), the connection is encrypted. ##### Why it’s important: - Protects passwords and sensitive data from being intercepted. - Required in many organizations for security compliance. ##### Options: - **Self-signed certificate** (quick and free, but browsers show a warning). - **Trusted CA certificate** (issued by companies like DigiCert, Let's Encrypt). ##### How: - Place your `.crt` and `.key` files in the SOAR SSL directory (e.g., `/opt/phantom/ssl/`). - Update SOAR’s config to point to your certificate files. - Restart the web service (`sudo systemctl restart phantomd`). ### d. Run the Web-Based Setup Wizard Now go to your browser and type in the server’s IP or hostname (e.g., `https://192.168.1.100`). You’ll be greeted by the **initial setup wizard**. ##### Key steps in the wizard: - **Create the Admin Account**: - You’ll enter the username, password, and email for the first administrator. - Choose a strong password — this account has full control over the platform. - **Configure SMTP Server (Email)**: - SOAR can send email alerts, verification codes, and user prompts. - Enter your email server settings (e.g., SMTP server, port, username, password). - Test it by sending a sample email. - **Proxy Settings (Optional)**: - If your company uses a proxy to connect to the internet, enter the proxy URL here. - This is needed for SOAR to install apps or access external APIs. - **License Activation**: - You may need to upload your license file or connect to Splunk to verify it. - If you're in trial mode, this step can often be skipped. - **Default System Roles and Timeouts**: - Configure how long sessions stay active before logging out. - Set up basic user roles (like admin, analyst, viewer) and what each role can do. #### e. Post-Setup Checklist (Recommended) After the wizard is complete: - **Log into the platform** with your new admin account. - **Go to Administration > System Health** and make sure all services are green. - **Install core apps** like the Splunk app, phishing enrichment tools, or your preferred SIEM connectors. - **Create a backup** of this fresh setup so you can recover it later. --- # User Management ### 1. What is User Management? User Management in SOAR refers to how you control **who can access the platform**, **what they can see**, and **what they are allowed to do**. It helps ensure that only the right people have the right level of control — especially important in cybersecurity environments. ### 2. User Types Different users in Splunk SOAR have different roles, based on their job in the security team. #### a. Administrators - **Who they are**: The people who set up and manage the entire SOAR system. - **What they can do**: - Install apps - Manage users and permissions - Configure system settings - Create and modify playbooks - Change the system time, SMTP, and more **Think of them like “super users”** — they have full power and responsibility over the platform. #### b. Analysts - **Who they are**: Security team members who investigate alerts and incidents. - **What they can do**: - View events and artifacts - Run playbooks on incidents - Take ownership of cases - Add notes, interact with prompts - Close or escalate investigations **They are the ones actively using SOAR in their daily work** to respond to security threats. #### c. Custom Users - **What this means**: You can create roles with very specific permissions. - **Example**: - A **“Viewer”** who can only read data but not run anything. - A **“Junior Analyst”** who can view alerts and run playbooks, but not modify them. **Why it's useful**: You can make sure new or external users don't accidentally break something or see sensitive information. ### 3. Role-Based Access Control (RBAC) This is one of the **most important** parts of user management. #### What is RBAC? RBAC means that permissions are assigned to **roles**, not directly to users. Then, users are assigned to those roles. **Think of it like this**: Roles = job descriptions. Users = employees. Instead of giving permissions one by one to each employee, you define the permissions in the job description (role), and assign that role to each employee. #### How It Works in SOAR - You define a **role** (e.g., “SOC Analyst”, “Case Viewer”). - You decide what that role **can and cannot do**, such as: - Run or edit playbooks - See certain dashboards - Use specific assets - When you create or edit a user, you assign them one or more roles. #### Examples: | Role Name | Can View Cases | Can Run Playbooks | Can Modify Assets | | -------------- | -------------- | ----------------- | ----------------- | | Admin | Y | Y | Y | | Senior Analyst | Y | Y | N | | Junior Analyst | Y | N | N | This makes it easy to scale your SOAR system securely — you don’t need to manually set every permission for every person. ### 4. Authentication Options Authentication is the process of verifying a user’s identity when they log into Splunk SOAR. Splunk SOAR offers multiple ways to authenticate users, depending on your organization's needs and security requirements. #### a. Local Authentication This is the **simplest** form of authentication, and it works out of the box. ##### What it is: - Each user has a **username** and **password** stored directly in the SOAR system. - Users log in through the SOAR web interface with those credentials. ##### Pros: - Easy to set up. - Doesn’t require external systems. ##### Cons: - Not ideal for large teams. - Password policies need to be enforced manually. ##### Use Case: You’re setting up a small SOAR instance or testing environment with just a few users. #### b. LDAP / Active Directory Integration LDAP (Lightweight Directory Access Protocol) and Active Directory are widely used in enterprises to manage employee accounts and access. ##### What it is: - SOAR connects to your company’s **existing directory server**. - Users use their **corporate usernames and passwords** to log in. ##### Pros: - No need to manually create user accounts in SOAR. - Password policies and login history are managed centrally. - You can sync groups from AD and assign SOAR roles based on group membership. ##### Cons: - Requires some IT knowledge to configure. - Needs to be tested carefully before enabling in production. ##### Use Case: Your organization already uses Active Directory or LDAP for employee logins, and you want seamless access control. #### c. SAML (Single Sign-On) SAML (Security Assertion Markup Language) allows users to sign in using a **Single Sign-On (SSO)** provider like: - Okta - Azure Active Directory - Google Workspace - OneLogin ##### What it is: - When a user tries to log into SOAR, they are redirected to a trusted identity provider (IdP). - After logging in there, they are allowed into SOAR automatically — no separate password needed. ##### Pros: - Seamless user experience. - Very secure (especially with multi-factor support). - Centralized login control across multiple platforms. ##### Cons: - Requires configuration on both the SOAR and the IdP side. - Misconfiguration can prevent users from logging in. ##### Use Case: Your company uses Okta or Azure AD and wants all employees to use the same login everywhere. #### d. Two-Factor Authentication (2FA) Two-Factor Authentication adds a **second step** to the login process. After entering a password, the user must enter a **one-time code** from a mobile app. ##### What it is: - SOAR supports TOTP (Time-based One-Time Password) apps like: - Google Authenticator - Authy - Microsoft Authenticator ##### How it works: 1. The user logs in with username + password. 2. They are prompted to enter a 6-digit code from their authenticator app. 3. If both steps are correct, access is granted. ##### Pros: - Strong protection against stolen passwords. - Easy to set up per user. ##### Cons: - If a user loses their phone, they’ll need to reset access. - Not available by default with all auth methods (e.g., some SSO setups handle this externally). ##### Use Case: You want to protect admin accounts or all logins with stronger security. ### Summary Table: | Method | Easy Setup | Good for Small Teams | Enterprise Ready | Secure (2FA Support) | | ----------------------- | ---------- | -------------------- | ---------------- | -------------------- | | Local Authentication | Y | Y | N | Y (optional) | | LDAP / Active Directory | N | N | Y | Y (via AD config) | | SAML / SSO | N | N | Y | Y (via IdP) | | 2FA (TOTP) | Y | Y | Y | Y | --- # Apps, Assets, and Playbooks ### 1. What’s the Relationship? Before diving into each part, here’s a quick overview of how they relate: - **Apps**: These are like “adapters” that connect SOAR to external tools. - **Assets**: These are specific “configured copies” of apps, with your environment’s settings. - **Playbooks**: These are the “automated workflows” that use assets to take actions when security events happen. Think of it like this: **Apps = Software tools** **Assets = Configured accounts** **Playbooks = Step-by-step instructions that use those tools** ### 2. Apps #### What is an App? An **App** in Splunk SOAR is a package that lets the platform communicate with an **external service** (e.g., a threat intelligence platform, firewall, SIEM, or cloud service). #### Examples: - **VirusTotal**: Look up file hashes, URLs, IPs. - **Splunk**: Run saved searches, fetch logs. - **AWS**: Start or stop EC2 instances, check IAM roles. - **Palo Alto Networks**: Block an IP, check firewall status. #### What Apps Provide: - **Predefined Actions**: Each app comes with specific actions you can use in playbooks. - Example actions: - `ip reputation` (VirusTotal) - `block user` (Active Directory) - `run query` (Splunk) #### How to Install Apps: 1. **App Store (Built-in)**: - Go to **Administration > Apps**. - Search and click “Install.” - Some apps may require internet access to install this way. 2. **Manual Upload**: - Download the `.tgz` app file from Splunkbase or GitHub. - Upload it via the SOAR UI. - Then configure it as an asset. *Remember*: Apps alone do not perform actions — they need to be configured into **Assets**. ### 3. Assets #### What is an Asset? An **Asset** is a specific, configured instance of an app. It contains all the connection details and credentials needed to talk to the external system. ##### For example: - The VirusTotal app becomes a “VirusTotal Asset” when you add: - An API Key - A description - Possibly a custom timeout setting #### What an Asset Includes: - **Authentication Details**: API keys, usernames, passwords, or OAuth tokens. - **Network Info**: IP address, base URL, or port. - **Additional Settings**: Timeout settings, log levels, optional headers. #### Setup Process: 1. Go to **Administration > Assets**. 2. Click “Add Asset.” 3. Choose an app (e.g., Splunk). 4. Fill in the required fields like: - Server URL - Authentication method - Role-based access settings 5. Click **Save and Test Connectivity**. #### Why Assets Matter: - Without an asset, the playbook has no way to interact with the external system. - You can have **multiple assets for the same app**. For example: - `Splunk-Test` for dev logs. - `Splunk-Prod` for production alerts. #### Access Control: - You can **limit which users or roles can access each asset**. - This helps enforce **security policies** (e.g., only admins can use the firewall asset). ### 4. Playbooks #### What is a Playbook? A **Playbook** is an automated script or flowchart that tells SOAR **what to do when something happens**. It’s like a robot that follows instructions when an event comes in. #### When is a Playbook Triggered? - **Automatically**: When a new event (container) is ingested. - **Manually**: When an analyst clicks “Run Playbook.” - **Scheduled**: Set to run at specific times or intervals. #### What Does a Playbook Contain? Playbooks are built from blocks such as: - **Actions**: Use an asset to call an external tool. - E.g., “Run IP reputation check” using VirusTotal. - **Conditions / Logic Blocks**: Decide what to do based on action results. - E.g., “If score > 80, mark as malicious.” - **Format Blocks**: Prepare data for reporting or logging. - **Prompts**: Ask analysts for input if automation can't decide. #### How Are They Built? - **Visual Editor**: Drag-and-drop interface (easy for beginners). - **Python Scripting**: Full control for advanced users. - **Hybrid**: Use visual design with occasional code blocks for flexibility. #### Advanced Features: - **Version Control**: Save and publish changes in different versions. - **Modularity**: Use smaller playbooks inside larger ones. - **Input/Output Handling**: Pass data between blocks or between parent/child playbooks. ### Summary | Component | Purpose | Key Function | | --------- | ------------------------- | ------------------------------------------ | | App | Enables integration | Provides the actions SOAR can call | | Asset | Custom instance of an app | Stores credentials and config for real use | | Playbook | The automation logic | Uses assets to respond to security events | --- # Analyst Queue ### 1. Overview The **Analyst Queue** is one of the most important operational features in Splunk SOAR. It acts like a **control room or dashboard** where security analysts manage all incoming security events. This is where they decide **what needs to be done, who should do it, and when**. You can think of it as a **task inbox** for your security operations center (SOC), but specifically designed for incidents, alerts, and cases. ### 2. Key Features #### a. Prioritized Event Feed When new events (also called “containers”) come into Splunk SOAR — whether from Splunk, firewalls, email systems, or any other source — they appear in the **event feed**. This feed is: - **Continuously updated** in real time. - **Sorted** based on key factors such as: - Severity (High, Medium, Low) - Tags (e.g., “phishing”, “malware”) - Timestamp (most recent first) - Event source (e.g., firewall, endpoint, cloud) ##### Why this matters: - Analysts don’t have to dig through all data. - They can focus on **what’s most urgent or most relevant** right away. #### b. Manual Assignment Analysts can manually **claim** incidents from the queue. How it works: - Each event starts in an "Unassigned" state. - An analyst clicks "Assign to me" or "Assign to [Analyst Name]". - Ownership is shown in the event’s metadata. ##### Benefits: - Clear accountability — each incident has a responsible person. - Prevents duplicate work — two people aren’t working on the same issue unknowingly. #### c. Auto Assignment For busy or large teams, SOAR can **automatically assign** events to the right analyst or team. This is done using **rules**, such as: - If the event type is “Phishing”, assign to Analyst A. - If it arrives outside business hours, assign to on-call team. - If it’s High Severity, assign to Senior Analysts. ##### How to set it up: - Go to **Administration > Ingestion Settings > Ingest Settings Rules**. - Define filters and the analyst or group to assign to. ##### Benefits: - Saves time. - Ensures faster response to critical events. - Keeps workloads balanced. #### d. Queue Filtering Sometimes analysts only want to focus on certain types of work. Filters help them narrow down the list of events. Examples: - Only show events tagged “malware”. - Only show unassigned, high-severity events. - Only show events created in the last 24 hours. Filters can be: - **Preset by Admins**. - **Customized by Users** for personal workflow. ##### Why this is useful: - Analysts can focus only on **what they’re best suited to handle**. - Senior analysts can use filters to **review high-risk activity**. - Managers can track team performance based on filtered views. ### 3. Benefits of the Analyst Queue Here’s why the Analyst Queue is a critical tool for any SOC using Splunk SOAR: #### a. Balanced Workload - Distributes incidents evenly across the team. - Prevents analyst fatigue or overload. - Can be tied to shift schedules, seniority, or specialization. #### b. Increased Visibility and Accountability - Everyone can see which events are open, assigned, or resolved. - Managers can track who handled what and when. - Reduces the chance of alerts being ignored or lost. #### c. Faster Triage and Escalation - Priority events are immediately visible at the top. - Analysts can quickly run playbooks or escalate complex cases. - Time from detection to resolution is significantly reduced. ### Summary | Feature | Purpose | | ----------------- | ------------------------------------------------- | | Prioritized Feed | Shows analysts the most important events first | | Manual Assignment | Lets analysts claim events they will handle | | Auto Assignment | Uses rules to automatically assign events | | Filters | Helps focus on specific event types or severities | | Key Benefits | Faster response, better teamwork, clear ownership | --- # The Investigation Page ### 1. Purpose The **Investigation Page** is the central workspace in Splunk SOAR where analysts **interact with a specific incident or case**. Think of it as your **mission control panel** for each alert. Once an event is triggered and turned into a case or investigation, this is where all the details live and where analysts do their hands-on work. It brings together all of the information, playbook results, actions, and notes into one place — making the incident easier to understand, respond to, and document. ### 2. Key Components #### a. Timeline View ##### What it shows: - A **chronological list** of everything that has happened related to the case. - This includes: - Automated actions (from playbooks). - Manual analyst actions. - Decision outcomes. - Notes and comments. - Event status changes (e.g., from Open → Closed). ##### Why it’s important: - Helps you **see the full story** of the incident. - Makes it easier to audit or review what actions were taken and when. - Provides clear documentation for reporting and compliance. #### b. Artifacts Panel ##### What are artifacts? Artifacts are **pieces of evidence or data** that were collected during the event or incident. These can include: - IP addresses - File hashes (MD5, SHA1, SHA256) - URLs - Usernames - Email addresses - Hostnames ##### What the panel does: - Displays all artifacts in a **structured table**. - Lets you sort or filter them by type. - Allows you to **select specific artifacts** and take action on them directly (e.g., check reputation, enrich data, run a playbook). ##### Why it’s helpful: - You don’t need to scroll through raw logs. - All critical data points are extracted and clearly shown. - You can quickly interact with just the parts you care about. #### c. Manual Actions Panel ##### What it does: - Lets analysts **manually trigger actions or playbooks** from within the investigation. - You can: - Run a specific asset action (e.g., “Query IP reputation” using VirusTotal). - Choose a playbook to run just for one artifact. - Customize input parameters before execution. ##### Why this matters: - Sometimes automation can’t decide everything — human judgment is needed. - Gives analysts **flexibility** and **control** during investigations. - Helps analysts respond to new developments as the investigation unfolds. #### d. Notes Section ##### Purpose: - Provides a space for analysts to **write comments, observations, and updates** throughout the investigation. ##### How it’s used: - Log hypotheses or findings (e.g., “This IP is part of a known phishing campaign”). - Collaborate with other analysts in shifts or across teams. - Record decisions made manually (e.g., “User was contacted and confirmed unusual activity”). ##### Benefits: - Keeps everything documented in one place. - Makes it easier for team members to stay aligned. - Provides historical reference for future investigations or audits. ### 3. Use Cases Let’s look at how analysts **actually use the Investigation Page** during their workflow: #### a. Perform Enrichment of Indicators Example: - You see an IP address in the artifact panel. - You run an enrichment playbook to: - Get geolocation - Query threat intelligence sources - Check past behavior in your SIEM This helps determine if the IP is **benign or malicious**. #### b. Launch Containment Actions From the same interface, you can: - Block a suspicious IP on a firewall. - Disable a compromised user account. - Quarantine an infected endpoint. These actions can be triggered **manually** or via **playbooks** with just a few clicks. #### c. Monitor and Intervene During Automation Playbooks don’t always run perfectly. In the Investigation Page, analysts can: - Watch live as each step of the playbook runs. - Pause, cancel, or adjust the playbook flow. - Step in to provide manual input if the playbook needs a decision or clarification. This lets analysts **blend automation and human expertise** for faster, smarter incident response. ### Summary | Component | Function | | -------------------- | -------------------------------------------------------------------- | | Timeline View | Shows a complete history of everything done on the case | | Artifacts Panel | Displays and allows action on data like IPs, hashes, URLs | | Manual Actions Panel | Lets analysts run playbooks and actions manually | | Notes Section | Used to document findings, decisions, and collaborate with teammates | --- # Case Management and Workbooks In Splunk SOAR, incidents don’t just come and go—they're tracked, analyzed, documented, and resolved as **cases**. To help structure this process, SOAR uses **Workbooks**, which act as a roadmap for investigation. ### 1. Case Management #### What is a Case? A **case** in Splunk SOAR is like a **folder that collects and organizes all the information related to a specific security incident**. It's used to manage that incident from beginning to end: detection, analysis, containment, and resolution. Cases are more than just records—they guide the incident response lifecycle, make collaboration easier, and help standardize how your team handles threats. #### Key Case Features ##### 1. Case Creation There are **two ways** cases can be created: - **Automatically**: Based on event conditions (e.g., severity level, source, type), SOAR can auto-generate a case from an incoming event. - Example: Every “Phishing” event with “High” severity becomes a case. - **Manually**: Analysts can convert an event into a case when they believe it requires deeper investigation. This flexibility ensures that only relevant events become full cases, preventing clutter. ##### 2. Case Fields Each case includes multiple fields to capture **essential information**: - **Title**: Name of the case (e.g., “Phishing email to HR team”). - **Severity**: Low, Medium, High, Critical. - **Status**: Open, In Progress, Resolved, Closed. - **Owner**: Assigned analyst or team responsible for investigation. - **Tags**: Keywords like "phishing", "ransomware", "internal", etc. - **Associated Events**: Lists all related events and artifacts. These fields make it easier to search, filter, sort, and prioritize cases. ##### 3. Case Linking Sometimes multiple alerts or events are related to **the same incident**. - In SOAR, you can **link multiple events** to a single case. - This is useful when: - Several endpoints are affected by the same malware. - Multiple users receive the same phishing email. Case linking reduces duplication and gives you a **complete picture** of a security incident. ##### 4. Case Templates A **Case Template** is a predefined format used to create new cases with consistent structure. - Useful when dealing with repeatable incident types like: - Phishing - Malware infections - Unauthorized access - Templates define: - Which fields are required. - Default values (e.g., default tags, severity). - Which workbook to attach. Templates help teams respond **faster and more consistently** by removing guesswork. ### 2. Workbooks #### What is a Workbook? A **Workbook** in Splunk SOAR is a **step-by-step investigation guide** attached to a case. It helps analysts follow a structured, repeatable process. Think of a workbook as a **checklist with automation** — combining human tasks with machine-executed playbooks. #### Key Features ##### 1. Stages and Tasks A workbook is divided into **Stages**, and each stage contains **Tasks**. - **Stages** are investigation phases like: - Detection - Triage - Containment - Eradication - Recovery - **Tasks** are what you do in each stage, such as: - “Verify sender domain” - “Query user login history” - “Isolate affected endpoint” These help guide even junior analysts through the correct process. ##### 2. Task Types There are **two types of tasks** in a workbook: - **Manual Tasks**: Require human input (e.g., writing a note, reviewing an alert). - **Automated Tasks**: Run playbooks in the background to complete the task (e.g., fetch file reputation, disable user). This blend of automation + human decision-making ensures **speed and accuracy**. ##### 3. Tracking Progress Every task and stage in the workbook can be: - Marked as **Pending**, **In Progress**, or **Completed**. - Tracked in real-time in the case interface. - Used for reporting (e.g., “What stage are most cases stuck in?”). Managers can monitor how far along a case is and identify bottlenecks. ##### 4. Customization You’re not stuck with default templates — Splunk SOAR lets you build your **own workbook templates**. - Create new stages and tasks. - Define which tasks are automated vs manual. - Link specific playbooks to tasks. - Save templates for phishing, malware, insider threat, etc. Customization ensures your workflows match **your company’s policies and response playbooks**. ### Summary | Feature | Function | | ----------------- | ----------------------------------------------------------------- | | Case Creation | Automatically or manually create a case to track an incident | | Case Fields | Define metadata like title, severity, tags, and ownership | | Case Linking | Combine multiple related events into one unified case | | Case Templates | Standardize case setup for common incident types | | Workbook Stages | Organize incident response into structured investigation phases | | Workbook Tasks | Guide analysts with manual steps and automated playbook execution | | Progress Tracking | Monitor task/stage completion and case resolution over time | | Customization | Tailor workbook templates to fit your internal processes | --- # Customizations 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 | --- # System Maintenance Splunk SOAR is a powerful platform, but like any software system, it needs regular care and maintenance to run smoothly. This includes **monitoring system health**, **backing up data**, **applying updates**, and **troubleshooting issues**. ### 1. System Monitoring Monitoring helps you ensure the SOAR system is healthy and performing well. It also helps identify problems early before they cause downtime. #### Health Dashboard - Found in the **web interface under Administration > System Health**. - Shows real-time information about: - **CPU Usage** - **Memory Consumption** - **Disk Space** - **Service Status** (like playbook engine, web server, etc.) **Green = Good**, **Yellow = Warning**, **Red = Critical** Use this to catch issues like: “Disk usage at 95%” or “Engine not responding.” #### Log Files Logs provide detailed records of what’s happening inside the platform. - Location: `/var/log/phantom/` - Common log files: - `phantomd.log`: Main service log. - `playbook.log`: Tracks playbook execution results. - `api.log`: Records all API requests and responses. - `celery.log`: Related to background task execution. Logs help diagnose issues like: Why did a playbook fail? Why didn’t an API call work? What happened right before a service crashed? #### Service Checks Splunk SOAR runs several internal services. One of the most important is: - **`phantomd`**: The core service that handles web interface, automation logic, and more. Use `systemctl status phantomd` (or `sudo service phantomd status`) to check if it's running. Other services may include: - `splunkd` (if integrated with Splunk) - `postgresql` (for the database) - `nginx` (for the web server) **Best Practice**: Set up automated alerts if services go down. ### 2. Backup and Restore Creating regular backups is essential to protect your configuration and data. If something goes wrong (like hardware failure or a corrupted update), you can restore your SOAR system without losing everything. #### What to Back Up - **Playbooks**: All your automation logic. - **Apps & Assets**: Configuration and credentials for integrations. - **Cases**: Active and closed investigations. - **System Settings**: User roles, custom fields, dashboards. #### How to Back Up - Use the **command-line interface (CLI)** or automation scripts. - Example command: ```bash /opt/phantom/bin/phantom_backup.sh --output /opt/backups/soar_backup.tar.gz ``` - Store backups **off the server**, ideally in a secure cloud or remote server. #### How Often? - **Daily or Weekly** backups for production environments. - Automate this using `cron` jobs or external scripts. ### 3. Updates and Patching Keeping your Splunk SOAR up to date is vital for: - **Fixing security vulnerabilities** - **Improving performance** - **Gaining access to new features and bug fixes** #### How to Update 1. Download the latest update package from Splunk. 2. Stop services. 3. Run the update utility or package manager. 4. Restart services and verify system health. **Always back up** before running updates! ### 4. Troubleshooting Tools When something goes wrong, Splunk SOAR provides tools to help diagnose and fix the issue. #### Command Line Utilities - **`phantom-syslog`**: Helps with analyzing system logs and events. - **`splunkd`**: Used if SOAR is connected to Splunk Enterprise. - **`phenv`**: A special shell environment for executing Splunk SOAR commands safely. Example use: ```bash phenv python3 playbook_test.py ``` #### Support Packages If you need to contact Splunk Support: - Use the **“Generate Support Package”** feature from the admin UI or CLI. - This collects: - Logs - Configuration files - Health stats The support team uses this to quickly diagnose problems. ### Summary | Maintenance Area | Key Purpose and Tools | | --------------------- | ------------------------------------------------------------------- | | Health Dashboard | Monitor performance and service status | | Log Files | Investigate issues and errors | | Service Checks | Ensure core services like `phantomd` are running | | Backups | Protect data and configurations with scheduled backups | | Updates & Patches | Fix bugs, close vulnerabilities, and add features | | Troubleshooting Tools | Use `phantom-syslog`, `phenv`, and support packages for diagnostics | --- # Introduction to Playbooks 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 | --- # Visual Playbook Editor ### 1. Purpose The **Visual Playbook Editor** in Splunk SOAR is a **drag-and-drop interface** that allows you to build playbooks **without writing any code**. It’s ideal for: - Analysts who are not familiar with Python. - Teams who want to quickly prototype automation flows. - Environments where clarity, documentation, and team collaboration are important. It turns automation into a **visual workflow**, so you can see exactly what will happen, step by step. ### 2. Key Features #### Canvas Interface The **canvas** is your workspace — a large visual grid where you place and connect blocks. - Drag blocks (also called **nodes**) from the side menu onto the canvas. - Connect them with arrows to define the order of execution. - You can zoom in, out, and drag the canvas to move around. Each block represents a specific function — an action, a condition, a prompt, etc. #### Node Types Here are the **main types of nodes** you'll use to build playbooks visually: ##### 1. Start Block - The **entry point** of the playbook. - Defines when and why the playbook should start running. - Can be triggered by: - A new event arriving. - A manual user action. - A scheduled time or case update. This block always appears at the top of the canvas. ##### 2. Action Block - Performs a task using a configured **asset**. - Examples: - Query IP reputation using VirusTotal. - Block a user in Active Directory. - Get alert details from Splunk. - You select: - The app/asset (e.g., VirusTotal). - The specific action (e.g., `ip reputation`). - Input parameters (e.g., IP address from an artifact). Action blocks are the **workhorses** of your playbook. ##### 3. Decision Block - Adds **logic** to your workflow. - Evaluates the result of a previous block and branches the flow accordingly. Example: - If VirusTotal score > 80 → go down the “Malicious” path. - Else → go down the “Safe” path. - You can define multiple conditions using: - Text comparisons (`==`, `contains`, etc.) - Number ranges (`>`, `<`) - Presence checks (`is empty`, `exists`, etc.) This is how your playbook becomes **smart and responsive**. ##### 4. Prompt Block - Sends a **question** to an analyst during the playbook run. - Useful when human input is required before taking action. Examples: - “Should we isolate this host?” - “What priority level should this case have?” - You can define: - Prompt message. - Input type (dropdown, text, number). - Who receives the prompt (specific user or role). The playbook will **pause** until someone responds. ##### 5. Format Block - Prepares information for display or output. - Can be used to: - Format messages to send via email or Slack. - Create summaries to log in the timeline. - Structure data before writing it to a case note. - Uses **template strings** (e.g., `IP address: {artifact:*.cef.destinationAddress}`). This is how you make outputs **readable and professional**. ### 3. Best Practices To make the most out of the Visual Playbook Editor, follow these tips: #### a. Keep the Flow Linear (Where Possible) - Try to keep blocks flowing from **top to bottom** or **left to right**. - Avoid tangled, spaghetti-like diagrams. - Group related logic together and use whitespace for readability. A clean flow helps others (and future you) understand what’s happening. #### b. Use Comments and Labels - Add **text labels** to groups of blocks to explain what they do. - Use the **description fields** in blocks for details. - This is especially important for complex workflows with decisions and branches. Documentation makes your automation **maintainable** and **team-friendly**. #### c. Test with Simulated Data Before deploying a playbook in production: - Use **test events or containers** to simulate real scenarios. - Watch how the playbook behaves in the Investigation Page. - Check logs and outputs to ensure everything runs as expected. Testing helps you **avoid mistakes and surprises** during live incidents. ### Summary | Component | Purpose | | ---------------- | ---------------------------------------------------------------- | | Canvas Interface | Workspace to visually arrange and connect workflow blocks | | Start Block | Defines when and why the playbook is triggered | | Action Block | Executes tasks using assets and apps | | Decision Block | Controls branching based on logic or data values | | Prompt Block | Requests analyst input before continuing | | Format Block | Creates clean, human-readable output messages | | Best Practices | Keep layout clear, label your blocks, and test before going live | --- # Logic, Filters, and User Interaction In Splunk SOAR, **automation isn't just about doing things fast — it's about doing them smart.** That’s where logic and filters come in. And when automation needs help, user interaction bridges the gap with human decision-making. ### 1. Logic in Playbooks Logic determines **how your playbook reacts to different conditions**. It controls the **flow** of automation based on the results of actions, inputs, or events. #### Decision Blocks A **Decision Block** is the main logic element in visual playbooks. It lets you ask yes/no or multi-condition questions like: - **"Is this IP in a blacklist?"** - **"Is the file hash reputation unknown?"** - **"Is the case severity greater than 'Medium'?"** Depending on the answer, the playbook can: - Branch into different paths. - Run different actions. - End early or escalate the case. Example: If `reputation_score > 80` → Mark as malicious. Else → Mark as benign. #### Comparison Operators Decision blocks support a wide range of **comparison operations** to define conditions: - `==` (equals) - `!=` (not equals) - `>` / `<` (greater than / less than) - `>=` / `<=` (greater than or equal to / less than or equal to) - `in` (value exists in a list) - `not in` (value does not exist in a list) - `is empty`, `is not empty` These operators allow for very specific control over playbook behavior. #### Nested Logic You can **chain or nest** multiple decision blocks together to handle complex scenarios. Example: - First decision: Is it a phishing email? - Yes → Check if sender domain is known. - No → Escalate to analyst. - Yes → Proceed with containment. This lets your playbook act more like a **human analyst thinking through a situation**. ### 2. Filters Filters help the playbook **work with only the relevant data**, which improves both accuracy and performance. #### Artifact Filters Artifacts are the data items (e.g., IPs, file hashes) extracted from an event. You can use **artifact filters** to: - Select only certain types of artifacts. - Example: “Only process artifacts where type = ‘IP Address’” - Ignore low-priority data. - Example: “Ignore URLs with risk score < 50” Filters make sure that **actions only target the right data**. #### Action Filters Some playbooks apply filters **before calling an action**, so it only runs when the input meets specific criteria. Example: - Run VirusTotal lookup **only if** the file hash is not already known. - Block IP **only if** its risk score is above 70. This avoids unnecessary or redundant actions, which improves performance and reduces cost (especially with APIs). #### Performance Benefits Filters reduce the amount of data and the number of operations in each playbook run: - Faster execution - Lower chance of errors - More scalable for large volumes of alerts ### 3. User Interaction Even with powerful automation, sometimes a **human decision is necessary** — that’s where **user interaction** features come in. #### Prompts Prompts are used to **pause the playbook and ask a question** to an analyst. Example: - *“Do you want to isolate the affected endpoint?”* Prompts include: - A message/question - Input fields (Yes/No, dropdown, free text, etc.) - An assigned user or role Until someone responds, the playbook will wait. #### Choices Prompts can offer **multiple selectable options**, such as: - Severity levels: Low / Medium / High - Action types: Quarantine / Notify / Escalate - Teams: SOC Tier 1 / Tier 2 / Legal These options make responses **standardized** and easier to process. #### Delays Sometimes you want the playbook to **pause before continuing**, either to: - Wait for external systems to respond. - Give analysts time to review. - Throttle sensitive actions. Example: Delay 5 minutes before auto-closing a resolved case. #### Targeted Prompts You can assign a prompt to: - A specific **user** - A specific **role** - A **group/team** This ensures that the **right person** is making the decision — not just anyone logged into SOAR. ### Summary | Category | Feature | Purpose & Example | | ---------------- | -------------------- | ------------------------------------------------------- | | Logic | Decision Block | Branch playbook based on score, status, or other values | | Logic | Comparison Operators | Define conditions (`==`, `>`, `in`, etc.) | | Logic | Nested Decisions | Handle complex, multi-step evaluations | | Filters | Artifact Filter | Focus only on IPs, URLs, or other specific artifacts | | Filters | Action Filter | Only perform actions when conditions are met | | Filters | Performance Boost | Reduce unnecessary operations | | User Interaction | Prompts | Pause playbook for human input | | User Interaction | Choices | Provide dropdowns or options for structured input | | User Interaction | Delays | Wait for a certain amount of time before next step | | User Interaction | Targeted Prompts | Direct questions to the right analyst or team | --- # Formatted Output and Data Access In Splunk SOAR, automation isn't just about doing things — it's also about **communicating clearly** what was done, what was found, and what it means. That’s where **formatted output** and **data access** come into play. ### 1. Formatted Output Playbooks often generate results (like IP reputation scores, usernames, domain info, etc.). These results can be turned into **alerts, messages, or summaries** using **Format Blocks**. #### What is a Format Block? A **Format Block** is a special step in a playbook that lets you build clean, readable messages using: - **Text templates** - **Variables from previous blocks** - **Data pulled from artifacts, actions, or inputs** Instead of sending messy JSON or raw data, you build messages that are easy to read and act on. #### Message Templates You can combine **static text** (hardcoded) and **dynamic variables** (pulled from the event or playbook) into a message. ##### Example Template: ``` "Malicious IP detected: {artifact:*.cef.destinationAddress}" ``` - **`{artifact:*.cef.destinationAddress}`** is a variable. - It gets replaced with the actual IP address extracted from the event. Other variables might include: - `{container.name}` – the name of the event or case. - `{action_result.data}` – result from a previous action. Templates help deliver **actionable intelligence** in plain language. #### Multiline Formatting You can write messages that span multiple lines — useful for: - Case summaries - Email alerts - Slack notifications - Audit logs ##### Example: ``` Incident Summary: - Event: {container.name} - Severity: {container.severity} - Affected IP: {artifact:*.cef.destinationAddress} - Analyst: {user.name} ``` The result is a **clean, structured message** instead of a wall of JSON. #### Output Channels Formatted messages can be sent to many places, including: - **Email**: Notify SOC team or manager. - **Slack / Microsoft Teams**: Send updates to a specific channel. - **Ticketing Systems**: Add information to Jira, ServiceNow, etc. - **Case Timeline Logs**: Record a summary of playbook activity. - **Custom Dashboards**: Show results in visual dashboards for SOC leads. Format Blocks help your automation **communicate effectively** with both humans and systems. ### 2. Accessing Data To format messages or make decisions, playbooks need to **access data** — both from incoming events and from previous steps. #### Phantom Functions Splunk SOAR provides special **Python functions** for accessing and manipulating data in playbooks (especially in code blocks). ##### 1. `phantom.collect2()` - Collects specific data from: - Artifacts - Action results - Custom fields ###### Example: ```python phantom.collect2(container=container, datapath=["artifact:*.cef.sourceAddress"]) ``` - This collects all source IPs from the container’s artifacts. ##### 2. `phantom.debug()` - Used to print variables and data into the playbook logs for **troubleshooting**. ###### Example: ```python phantom.debug("IP Reputation: {}".format(reputation_score)) ``` This is especially helpful when testing or debugging new playbooks. #### Variables and JSON Access Much of the data in SOAR is structured like **JSON**, so you access it using keys or dot notation. ##### Examples: ```python results[0]['summary']['status'] ``` - Gets the **status** from the **summary** of the first result. ```python action_result.get("data", [{}])[0].get("risk_score") ``` - Gets the `risk_score` from a previous action result. You can use these variables in **code blocks**, **decision logic**, or **format templates**. ### 3. Use Cases Let’s explore how formatted output and data access are used in real-world playbooks: #### a. Display Formatted Results to Users - When a prompt is shown to an analyst, include a **summary of findings**. - Makes it easier for them to make informed decisions. #### b. Log Summaries to Case Timeline - After a playbook runs, use a Format Block to write a **summary message** into the case timeline: - “Blocked IP 192.168.1.50 on Palo Alto” - “User account jsmith was disabled after suspicious activity” #### c. Create Incident Reports for External Systems - Format a message and send it to: - **Jira** (for ticket creation) - **ServiceNow** (for change tracking) - **Email** (for compliance or management reports) This ensures your incident response is **documented and shareable**. ### Summary | Feature | Purpose | | -------------------- | ------------------------------------------------------------------ | | Format Block | Builds readable output from raw data | | Message Templates | Combines text and variables into clear messages | | Multiline Formatting | Creates structured summaries or notifications | | Output Channels | Sends messages to email, Slack, tickets, dashboards, or logs | | `phantom.collect2()` | Collects data from artifacts and action results | | `phantom.debug()` | Outputs debug info to logs for troubleshooting | | JSON Access | Allows deep inspection of results and decision making in playbooks | --- # Modular Playbook Development As playbooks grow in complexity, it becomes harder to maintain them if everything is built into one large workflow. That’s where **modular playbooks** come in. They help break down large tasks into **smaller, reusable units**, just like good programming practices. ### 1. Concept #### What Is a Modular Playbook? A **modular playbook** is a small, self-contained playbook that performs **one specific task** — for example, checking an IP address reputation or disabling a user account. Instead of building one huge playbook with 50+ steps, you split it into smaller playbooks and use a **parent-child model**. #### Parent-Child Structure This structure allows you to organize workflows more efficiently. - **Parent Playbook**: - Acts as the main orchestrator. - Controls the overall flow of logic and decision-making. - Calls child playbooks as needed. - **Child Playbook**: - Performs a focused task such as: - File enrichment - Email analysis - Host isolation - Returns results back to the parent. Think of the parent as a project manager and the children as specialized workers. #### Playbook Blocks To use a child playbook, the parent must include a **Playbook Block**. - It’s just like using an Action Block, but instead of calling an app, it calls a **playbook**. - You select: - Which child playbook to call. - What data to send in (e.g., an IP address). - What results to return and use later. This block makes modular design **plug-and-play**. ### 2. Benefits #### a. Reusability - Write once, use many times. - If multiple playbooks require IP enrichment, you only need **one child playbook** that performs that task. - Reduces duplication across workflows. #### b. Maintainability - If something changes (e.g., the way you block users), you only update the **child playbook** — not every parent playbook that uses it. - Easier to test and troubleshoot individual units. #### c. Scalability - Large enterprise workflows can get complicated fast. - By breaking things into **smaller modules**, it becomes easier to: - Understand each part. - Assign work across teams. - Scale playbooks for more use cases. You’re essentially **applying software engineering best practices to automation design**. ### 3. Best Practices #### a. Keep Child Playbooks Focused Each child playbook should do **one thing and do it well**. - Examples: - Child Playbook A: Check domain reputation - Child Playbook B: Isolate endpoint - Child Playbook C: Notify the user Avoid bundling unrelated logic into one child playbook. #### b. Pass and Return Clear, Structured Data Data between parent and child playbooks should be: - **Clearly defined** - **Consistent** - **Structured**, preferably using **JSON** format This makes it easier to: - Parse results - Pass multiple values - Avoid data mismatches Tip: Use Format Blocks to structure your output cleanly in the child playbook. #### c. Handle Failures Gracefully in the Parent Sometimes child playbooks can fail (e.g., API timeout, invalid input). Your **parent playbook** should: - **Check return status** from the child playbook. - Use **decision blocks** to handle errors (e.g., retry, log, escalate). - Avoid letting one failure stop the entire parent playbook. Automation should be **resilient**, not fragile. ### Summary | Concept | Description | | ----------------- | ---------------------------------------------------------------- | | Modular Playbooks | Small, task-specific playbooks used as components | | Parent Playbook | Controls overall workflow and calls children | | Child Playbook | Performs a single action (e.g., enrichment, notification) | | Playbook Block | Special block to run a child playbook inside a parent | | Reusability | Use the same child playbook across multiple workflows | | Maintainability | Update logic in one place without editing many playbooks | | Scalability | Break complex workflows into smaller, easier-to-manage parts | | Best Practices | Keep focused, pass structured data, and handle errors gracefully | --- # Custom Lists and Data Routing 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: ```python 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 | --- # Configuring External Splunk Search ### 1. Purpose Splunk SOAR is an automation platform, but it becomes **far more powerful when connected to a Splunk instance**. This integration allows SOAR to: - Run **real-time searches** in Splunk. - Pull back logs, alerts, or historical data. - Use those results to **enrich**, **validate**, or **correlate** security events in playbooks. In short: SOAR asks questions, and Splunk gives the answers. ### 2. Configuration Steps To connect SOAR with a Splunk instance, follow these basic setup steps: #### Step 1: Install the Splunk App on SOAR - Go to **Apps > App Store** in the SOAR interface. - Search for the **Splunk app** (developed by Splunk). - Click **Install**. This app includes pre-built actions for querying Splunk using SPL (Search Processing Language). #### Step 2: Create an Asset for Splunk Once the app is installed, configure an **Asset** to connect to your specific Splunk instance. ##### Asset Settings: - **Splunk Server URL**: The URL of your Splunk search head (e.g., `https://splunk.company.com:8089`) - **Authentication**: - Username and password for a Splunk account with **search privileges** - **Query Timeout**: - How long SOAR should wait for a search to complete (e.g., 60 seconds) - **Index Scope**: - Define which indexes the user can search (e.g., `main`, `wineventlog`, `network_traffic`) You may need to generate an **API token** from Splunk, depending on how authentication is handled. #### Step 3: Test the Connection - After saving the asset, click **Test Connectivity**. - If everything is configured correctly, you should get a success message. If it fails: - Check the URL and port. - Confirm the Splunk user has REST API and search permissions. - Review firewall rules and network connectivity. ### 3. Search Usage in Playbooks Once your Splunk asset is set up, you can start using it inside your playbooks. #### Search Block The **Search Block** allows you to run SPL queries directly from SOAR. ##### Example Query: ```spl search index=network_traffic src_ip=10.0.0.1 ``` You can insert variables into the query using data from artifacts or playbook inputs. This allows your automation to dynamically search for related logs based on the incoming event. #### Use Cases Splunk search integration can be used in many security automation scenarios: ##### 1. Enrichment - Add context to a suspicious indicator. - Example: Pull logs showing how many times an IP communicated with internal systems. ##### 2. Validation - Confirm whether an alert is a false positive or part of a larger pattern. - Example: Check if a user has logged in from multiple geographies in a short time. ##### 3. Threat Hunting / Correlation - Use Splunk to **find lateral movement**, **command-and-control activity**, or **data exfiltration**. - Example: Find all outbound connections from a compromised host in the past 24 hours. These use cases help turn raw alerts into actionable incidents. ### 4. Considerations #### a. Search Permissions Make sure the Splunk account used in the asset has: - Permission to **search the correct indexes**. - Access to required **SPL commands**. - Ability to **use the REST API**. Without proper permissions, searches may fail silently or return incomplete results. #### b. Large Result Sets - Be careful with queries that return **huge volumes of data**. - Large datasets can: - **Slow down playbooks** - Cause **timeouts or memory issues** - Lead to **action failures** ##### Best Practices: - Use **limits** in your SPL (e.g., `| head 100`) - Filter by **host**, **index**, **source type**, and **time range** - Use **summary indexing** or saved searches for very heavy queries ### Summary | Feature | Purpose and Function | | ----------------------- | ------------------------------------------------------------------- | | Splunk App Installation | Adds the ability to run SPL searches from within SOAR | | Asset Configuration | Connects SOAR to your Splunk instance with credentials and settings | | Search Block | Executes SPL queries dynamically in playbooks | | Enrichment Use Case | Pull related logs to add context to an alert | | Validation Use Case | Confirm user behavior or system activity | | Correlation Use Case | Identify broader attack patterns like lateral movement | | Permissions Requirement | Ensure Splunk user can access indexes and API | | Result Set Management | Avoid performance issues with large data pulls | --- # Integrating SOAR into Splunk ### 1. Overview Many people think of Splunk SOAR as a tool that **pulls data from Splunk**, but the reverse is also true: Splunk (as a SIEM) can actively **push alerts and events into SOAR**, where they are automatically investigated, enriched, and responded to. This **bi-directional integration** allows analysts to move seamlessly between detecting threats in Splunk and responding to them in SOAR. Think of Splunk as the **alert generator** and SOAR as the **response engine**. ### 2. Integration Points Let’s look at the two key integration mechanisms that let Splunk and SOAR work together: #### a. Splunk App for SOAR This app is installed **on the Splunk platform** (not SOAR), and it enables: - **Forwarding alerts from Splunk to SOAR**: - Alerts from correlation searches or data models can be sent directly to SOAR as events. - These events then trigger playbooks automatically. - **Viewing SOAR data inside Splunk**: - The app includes dashboards that show: - Open SOAR cases - Automation timelines - Analyst decisions - This lets Splunk users track response progress without switching tools. This app makes the integration feel **native and seamless** from the Splunk side. #### b. Adaptive Response Framework (ARF) The **Adaptive Response Framework (ARF)** is a Splunk Enterprise Security (ES) feature that lets you **take action directly from search results**. ##### What it does: - Lets analysts **right-click** or select a field (e.g., an IP, username) in a notable event. - Choose a **response action**, such as: - “Send to SOAR for investigation” - “Run playbook: Quarantine Host” - “Request Enrichment from SOAR” ##### How it works: - The chosen action sends the necessary data to SOAR (via REST API or app integration). - A playbook is triggered in SOAR to handle the response. ARF empowers analysts to **go from detection to action in one click**. ### 3. Data Flow Here’s what a typical integration workflow looks like: 1. **Detection** - Splunk runs a **correlation search** and detects suspicious activity. - A **notable event** is generated in Splunk Enterprise Security. 2. **Forwarding** - A **custom alert action** (from the SOAR app or ARF) sends the event to SOAR. - Data is sent via REST API with key fields like IPs, users, domains, etc. 3. **Playbook Execution** - SOAR ingests the event and launches a **playbook**. - The playbook enriches the data, checks threat intelligence, and performs actions. 4. **Feedback Loop** - SOAR can send: - **Enrichment results** (e.g., IP is malicious). - **Case updates** (e.g., investigation closed). - Back to Splunk, where it can be: - Logged - Shown in dashboards - Used to update notable events This tight integration creates a **closed-loop security operations workflow**. ### 4. Use Cases This integration unlocks many real-world security automation scenarios: #### a. Trigger SOAR Playbooks from Correlation Searches - Use Splunk searches (e.g., “User logged in from 2 countries in 5 minutes”) to: - Automatically send the event to SOAR. - Trigger a prebuilt investigation playbook. Reduces time to triage and supports consistent response procedures. #### b. Automate Threat Responses - Once SOAR is triggered, it can: - Disable compromised user accounts. - Block malicious IPs at the firewall. - Notify stakeholders or start case management. This turns **manual actions** into **automatic remediation**. #### c. View SOAR Case Status from Splunk - Dashboards in the Splunk SOAR App let analysts: - See case progress and status. - Understand which actions were taken. - Follow automation timelines. This provides **end-to-end visibility** without switching tools. ### Summary | Feature | Description | | --------------------------- | ----------------------------------------------------------------------- | | Splunk App for SOAR | Sends alerts to SOAR and shows SOAR data in Splunk | | Adaptive Response Framework | Allows manual triggering of SOAR playbooks from search results | | Detection to Response Flow | Splunk detects → Sends to SOAR → SOAR investigates → Sends results back | | Use Case: Auto-Triage | Use correlation rules to launch playbooks | | Use Case: Auto-Remediation | Automatically block IPs, disable accounts, escalate incidents | | Use Case: Case Visibility | View SOAR case progress and resolution inside Splunk dashboards | --- # Custom Coding ### 1. Purpose While Splunk SOAR provides many visual tools and built-in integrations, **custom coding** lets you go beyond what’s available out of the box. It gives you full control over: - Data parsing - Decision-making - Custom workflows - Integrating with systems that don’t have native SOAR apps If you can write it in Python, you can likely automate it in SOAR. ### 2. Key Components There are **three main ways** to use custom code in SOAR: #### a. Custom Functions **Custom Functions** are Python scripts you can build once and use in **multiple playbooks**. ##### Key Features: - Accept inputs (like a list of IPs or strings). - Perform a task (e.g., normalize data, calculate scores). - Return structured output (typically a dictionary or JSON). ##### Example: - A function that takes a list of domain names and extracts only the top-level domains (TLDs). - Output: a list like `[".com", ".net", ".org"]` ##### Benefits: - Reusable across teams. - Easy to maintain and version. - Promotes clean modular design. Ideal for logic that doesn’t belong to a specific app or asset. #### b. Playbook Scripts (Code Blocks) These are **Python scripts embedded directly in a visual playbook** using the **Code Block node**. ##### Use Cases: - Perform string operations. - Loop through a list of artifacts. - Filter out unwanted items. - Format data in a custom way. - Log variables for debugging. ##### Example: ```python for ip in ip_list: if ip.startswith("192.168"): internal_ips.append(ip) ``` Code blocks give you **fine-grained control** over data within a playbook. #### c. App Development If SOAR doesn’t have an app for a specific tool, you can **build your own app** from scratch using Python. ##### Components of a Custom App: - **YAML Metadata File**: - Defines action names, parameters, descriptions, and required fields. - **Python Action Handlers**: - Implement the actual code for each action. - Often use REST API requests to external systems. - **Optional REST Endpoints**: - Expose parts of your app as a callable API. - Can be used by other systems or internal SOAR tools. Apps are best for **full integrations** that need to be reused across the platform. ### 3. Use Cases Here’s how custom coding enhances SOAR capabilities: #### a. Advanced String Manipulation or Data Parsing - Example: Extract a username from a log entry like `"user=jdoe@company.com"` - Or format time values, remove special characters, etc. When visual filters aren’t enough, Python can clean and reshape your data exactly how you want. #### b. Dynamic Logic Not Supported Visually - Visual decision blocks are powerful, but they can be limited. - Python lets you: - Run loops - Handle multiple conditions - Create fallback logic or retry strategies More flexible than drag-and-drop logic. #### c. Custom Integrations - Some internal tools or third-party APIs don’t have official SOAR apps. - Use Python to: - Send API requests - Parse custom formats (XML, YAML, etc.) - Handle authentication (OAuth, tokens) Python bridges the gap where native support is missing. ### 4. Best Practices To write secure, maintainable code in SOAR, follow these tips: #### a. Sanitize Input Data - Avoid code injection by cleaning input. - Never trust external values without checking or escaping them. Especially important when using user input, file paths, or unverified data. #### b. Use Logging for Debugging - Use `phantom.debug()` to log values and variables: ```python phantom.debug("Score is: {}".format(score)) ``` - Helps you understand how your playbook behaves. Use logging generously when testing or troubleshooting. #### c. Follow Splunk SDK and Documentation - Splunk provides clear developer documentation for: - Custom app development - Code standards - YAML schema - Use the official **SDK** and templates to build apps faster and more reliably. Proper use of SDK tools reduces bugs and improves performance. ### Summary | Component | Purpose & Use | | --------------------- | -------------------------------------------------------- | | Custom Functions | Reusable Python scripts used across multiple playbooks | | Playbook Scripts | Logic blocks embedded directly into visual playbooks | | App Development | Full Python integrations using YAML + API logic | | Use Case: Parsing | Clean and structure data not handled by visual filters | | Use Case: Logic | Complex decision-making beyond drag-and-drop tools | | Use Case: Integration | Connect to tools without official Splunk SOAR apps | | Best Practices | Sanitize input, use debug logging, follow SDK guidelines | --- # Using REST ### 1. Overview Splunk SOAR provides a **RESTful API** that allows external systems, scripts, and developers to **interact with the platform programmatically**. This means you can automate operations, fetch data, trigger playbooks, and more — all without needing to log in to the web interface. Think of the REST API as a **remote control** for Splunk SOAR. ### 2. API Capabilities The SOAR REST API supports a wide variety of operations. You can: #### a. Create and Update: - **Events (Containers)** - Automatically send alerts into SOAR from other systems. - **Artifacts** - Add indicators of compromise (IOCs) like IPs, hashes, domains. - **Cases** - Create, assign, and update investigation cases. #### b. Query System Objects: - **Playbooks** - **Assets** - **Users** - **Roles** - **Lists** You can retrieve current system settings, configurations, or object metadata. #### c. Execute Playbooks Manually: - You can use the API to **trigger a specific playbook** on a container or case. Useful for integrating SOAR with external ticketing, detection, or workflow systems. #### d. Upload Files: - Attach logs, documents, screenshots, or forensic files to a case using the API. ### 3. Authentication To use the REST API securely, you must authenticate each request. #### Token-Based Authentication (Recommended) - You can create API tokens in: - The **Web UI** (under User Profile > API Tokens) - The **`/login` endpoint**, using a script ##### Token Format: ```bash Authorization: Bearer ``` Best for scripts, integrations, and automation tools. #### Session Cookie-Based Authentication - Used when accessing the API from a **browser-based client**. - Requires an authenticated session cookie. Less secure for automation but useful for internal tools with UI elements. ### 4. Common Endpoints Here are some frequently used API calls: | Endpoint | Description | | ------------------------- | ------------------------------------------------ | | `POST /rest/container` | Create a new container (event) | | `GET /rest/artifact` | Retrieve artifact data | | `POST /rest/playbook_run` | Trigger a playbook execution | | `GET /rest/system_info` | Get system metadata like version, status, uptime | These endpoints help integrate SOAR with **detection systems, ticketing tools, and case managers**. ### 5. Security Considerations Any time you're exposing an API, **security is critical**. Follow these practices: #### a. Always Use HTTPS - Do not expose your API over HTTP. - Use a valid SSL certificate to **encrypt all traffic**. #### b. Limit Token Permissions - Don’t use admin-level tokens unless necessary. - Create tokens with the **minimum role or scope required**. #### c. Rotate Tokens Regularly - Set expiry periods for tokens. - Revoke and replace tokens periodically. - Remove unused or inactive tokens. #### d. Audit API Usage - Monitor logs to detect suspicious behavior (e.g., failed logins, unexpected requests). - Keep an eye on volume and access times. ### 6. Tools for API Testing and Integration #### Postman - A user-friendly API testing tool. - Great for exploring endpoints, building requests, and debugging responses. #### Curl - Command-line tool for sending API requests. - Useful for scripting and quick tests. ##### Example: ```bash curl -X GET https://soar.company.com/rest/container \ -H "Authorization: Bearer " ``` #### Python + `requests` Library - Ideal for building custom integrations or automation scripts. - Easily handle GET/POST requests, headers, JSON payloads, and error handling. ##### Example: ```python import requests headers = { "Authorization": "Bearer YOUR_TOKEN", "Content-Type": "application/json" } response = requests.get("https://soar.company.com/rest/container", headers=headers) print(response.json()) ``` ### 7. Real-World Use Cases - **Ticketing Integration**: Auto-create SOAR events from ServiceNow or Jira tickets. - **Threat Feed Ingestion**: Push threat indicators from intel platforms. - **Cross-SOAR Sync**: Share containers, cases, and results across SOAR environments. - **Dashboards**: Build custom dashboards outside of SOAR using live API data. ### Summary | Feature | Description | | ----------------------- | ------------------------------------------------------------------------------ | | REST API Purpose | Programmatically control and integrate with SOAR | | Capabilities | Create/update containers, artifacts, playbooks, assets, users | | Auth Methods | Token-based (preferred) or session cookie | | Common Endpoints | `/rest/container`, `/rest/playbook_run`, `/rest/artifact`, `/rest/system_info` | | Security Best Practices | Use HTTPS, restrict permissions, rotate tokens, monitor usage | | Tools | Postman, curl, Python `requests` | | Use Cases | Integrations with SIEMs, ticketing, threat intel, SOAR-to-SOAR syncing | --- # Deployment, Installation, and Initial Configuration (Additional Content) ### 1. **System Requirements and Compatibility** Although the platform compatibility was briefly introduced (e.g., CentOS, RHEL, Ubuntu), it is important to be aware of the **recommended hardware requirements and supported OS versions**. #### a. Minimum System Resources While not always explicitly tested, understanding baseline infrastructure requirements helps ensure successful deployment. Typical guidelines include: - **CPU**: Minimum 4 cores (8 or more recommended for production environments) - **Memory (RAM)**: At least 16 GB (32 GB+ recommended for high event volumes) - **Disk Space**: Minimum 100 GB; production systems often require 500 GB or more depending on data retention and backup frequency These values ensure that the platform can handle ingestion, playbook execution, and concurrent analyst operations without performance degradation. #### b. Supported Operating Systems Splunk SOAR is officially supported on: - **RHEL**: Versions 7.6 – 8.x - **CentOS**: Versions 7.6 – 7.9 - **Ubuntu**: Typically 18.04 and 20.04 LTS (other versions may not be stable or supported) Deploying on unsupported or outdated versions may result in failed installations or missing dependencies (e.g., Python libraries, PostgreSQL compatibility). ### 2. **License Types: Evaluation vs. Commercial** SOAR licensing affects **feature availability**, **system behavior**, and **expiration limits**. #### a. Evaluation Mode - **Duration**: Typically valid for **30 days** from the date of installation - **Functionality**: Provides **full platform functionality** (including automation, playbooks, app usage), but: - May restrict user counts or integrations in some builds - Will prompt license warnings as expiration approaches - Once expired, the platform may: - Limit login access - Prevent new events from being ingested - Block execution of playbooks #### b. Commercial (Enterprise) License - **Binding**: Tied to machine-level identifiers (e.g., MAC address or system UUID) - **Renewal**: Must be manually uploaded or configured via the **admin interface** - **Support**: Grants access to Splunk support and updates - May include **tiered user counts, storage limits, or app caps** based on purchase agreement #### Practical Consideration In exam scenarios, you may encounter questions that test understanding of **SOAR feature limitations after license expiration**, or how licensing affects long-term automation strategies. ### 3. **Command-Line Management Tools** SOAR provides system-level control both via GUI and the command line. These utilities may be especially relevant during **troubleshooting**, **log analysis**, or **service recovery**. #### a. System Service Controls To manage the core SOAR daemon (`phantomd`), the following commands are commonly used: ```bash sudo systemctl status phantomd # Check service status sudo systemctl restart phantomd # Restart SOAR sudo systemctl stop phantomd # Stop the service ``` These operations are often required after **config changes**, **app installations**, or **log retention tuning**. #### b. Common Log File Paths Knowing where logs are stored helps diagnose failed actions or startup issues: - **Main logs**: `/var/log/phantom/phantomd.log` - **Playbook execution**: `/var/log/phantom/playbook.log` - **API logs**: `/var/log/phantom/api.log` - **App-specific issues**: `/var/log/phantom/connector_.log` Exam scenarios may ask where to look for error messages if a playbook fails to start or if asset communication fails. ### 4. **Automated Backup Strategy (Not Manual Snapshots)** Splunk SOAR supports **command-line and scheduled backups**, which are essential for **business continuity** and **system recovery**. #### a. Backup Capabilities - SOAR includes a CLI tool: ```bash /opt/phantom/bin/phantom_backup.sh ``` - You can schedule this with `cron` to perform daily or weekly backups #### b. What Gets Backed Up - **Playbooks** - **Apps and Assets** - **Cases, containers, and artifacts** - **Users and roles** - **System configuration and custom lists** #### c. Storage Best Practice - Backups should be stored **outside the primary server** — typically to: - Mounted NFS volumes - Secure S3 buckets - Encrypted local partitions This reduces the risk of **data loss** in case of host failure or corruption. ### Final Tip for Exam Candidates Although you may not be asked to recall exact command syntax or license renewal steps, expect questions that involve: - Diagnosing a system issue using log locations - Identifying compatible operating systems - Understanding the impact of an expired license - Describing how SOAR ensures business continuity through automated backups --- # User Management (Additional Content) ### 1. **Account Lockout Mechanisms and Password Policy** SOAR supports several **local authentication security mechanisms** that help enforce **security compliance** within enterprise environments. #### a. Account Lockout on Failed Logins - Splunk SOAR **does support configurable lockout policies** for failed login attempts. - Admins can define: - The **maximum number of failed login attempts** - The **duration of the lockout period** - This is useful to **prevent brute-force login attacks**. This configuration is typically managed through the **Admin UI under Authentication Settings**, and it applies to users who authenticate using **local credentials** (not via SAML or LDAP). #### b. Password Complexity Enforcement - SOAR **supports local password policy configuration**, including: - **Minimum password length** - **Character complexity requirements** (e.g., uppercase, lowercase, numeric, special characters) - These rules can be applied **only to locally managed users**, not those managed by external identity providers. #### c. Password Expiration and Rotation - Admins can also enforce: - **Password expiration intervals** (e.g., every 90 days) - **Password history rules** (e.g., disallow reuse of the last N passwords) - **Mandatory password changes on first login** This feature supports **compliance mandates** such as NIST, PCI-DSS, or ISO/IEC 27001. ##### Summary: | Capability | Supported for Local Users? | | --- | --- | | Lock after failed attempts | Yes | | Password complexity | Yes | | Expiration policies | Yes | | Applies to SAML/LDAP users | No (controlled externally) | ### 2. **User Auditing and Activity Logging** Monitoring user activity is essential for both **security** and **compliance auditing**. #### a. What Is Tracked? Splunk SOAR maintains detailed **audit logs** for: - **Login attempts** (success/failure) - **User account changes** (creation, role changes, deletions) - **Playbook executions** - **Manual actions** taken during investigations - **Modifications to system settings or configurations** This enables tracking of **who did what, when, and where** within the platform. #### b. Where to View User Activity Logs - Logs can be found in the **UI under**: `Administration > Audit Logs` or `Administration > System Settings > Logs` - Alternatively, logs are also written to the file system: - **Authentication and web activity**: `/var/log/phantom/phantomd.log` - **Playbook execution and actions**: `/var/log/phantom/playbook.log` - Logs can be exported and **ingested into Splunk** for long-term retention, alerting, and correlation. #### c. Use Case for Exams Example question: **“How can an administrator verify whether User A manually triggered a playbook yesterday?”** Answer: Use the **Audit Logs** section or query the relevant **log files** for timestamped user activity. ### 3. **Default Roles and Built-in Permissions** Splunk SOAR includes several **predefined user roles** with varying levels of access. Understanding these roles is important for both platform governance and exam scenarios. #### a. Built-in Roles Typical default roles include: | Role | Description | | --- | --- | | **Administrator** | Full control over the platform, including user and system configuration | | **Automation** | Designed for machine accounts or app integrations; can execute playbooks but **not access the UI** | | **Analyst** | Can view and respond to incidents, run playbooks, add notes | | **Manager** | Similar to Analyst, but may have broader visibility and reporting access | These roles are **not hardcoded** — administrators can customize permissions further by cloning and modifying roles. #### b. Role Permissions and Limitations - **Automation role**: - Can run actions and playbooks via API - Cannot log into the web interface - **Analyst role**: - Can **manually execute playbooks** - Cannot modify system settings or user configurations - **Only Admins**: - Can create or delete users - Can install apps and configure assets #### Common Exam Trap: A question may ask: **“Can a user with the Automation role trigger playbooks via API?”** Yes. However, they cannot access the UI. ### Final Tip for Exam Readiness Expect multiple-choice questions that challenge your understanding of: - What happens when login attempts fail repeatedly - Who can perform system-level actions - How audit logs can verify user behavior --- # Apps, Assets, and Playbooks (Additional Content) ### 1. **Asset Tagging and Group Management** In environments where dozens or hundreds of **assets** are configured, Splunk SOAR provides support for **tags and asset groups** to help with organization and filtering. #### a. Tags for Assets - Admins can assign **tags** to assets to classify them by: - Function (e.g., *Firewall*, *Intel*, *SIEM*) - Environment (e.g., *Dev*, *Prod*) - Owner or Team (e.g., *SOC Tier 1*, *Engineering*) - These tags are **user-defined keywords** that improve **searchability and filtering** in the UI. #### b. Use Case in Exams Some questions may ask: “How can analysts quickly locate a specific AWS asset configured for the Dev environment?” Correct approach: Use the **filter panel in the Assets section**, and apply the **relevant tag** like `"Dev"` or `"AWS"`. #### c. Asset Groups (Not a default concept, but possible via tagging logic) Although SOAR does not support "asset groups" as a standalone feature, you can simulate groups by **assigning the same tag to multiple assets**. For example: - Tag several Splunk assets as `"Monitoring"` to group them logically. ### 2. **Playbook Debugging and Testing Features** Understanding how to troubleshoot and validate playbooks is essential — both in real-world automation and for exam scenarios. #### a. Test Mode - Playbooks can be executed in **test mode** from the UI: - Choose a sample container or event - Run the playbook interactively - This allows analysts to **observe each block’s behavior** and review outputs step by step. #### b. Debugging with `phantom.debug()` - Inside **code blocks**, use: ```python phantom.debug("Variable value: {}".format(variable_name)) ``` - This logs the value to the **playbook log**, viewable via the **Investigation page** or system logs (`playbook.log`). #### c. Playbook Execution Log - Each action or block generates **output logs** that include: - Input parameters used - Return status (success/failure) - Returned data (such as JSON or lists) - You can see this in: - The **timeline** of the container - The **“Execution” tab** in the playbook designer #### d. Exam Relevance “What’s the best way to identify why a playbook failed at a specific step?” Correct answer: **Review the debug logs and output of that specific block or use test mode**. ### 3. **App Categories – Types and Use Cases** Apps in Splunk SOAR act as **connectors** to external systems and are categorized based on the type of service they integrate with. Understanding these types helps you **map use cases to the correct integration**. #### a. Security Intelligence Apps Used to **enrich indicators** or evaluate threat intelligence. - **Examples**: - VirusTotal - OTX (Open Threat Exchange) - Recorded Future - **Typical Actions**: - IP/domain/file reputation lookup - Threat score evaluation - **Use Case**: “Is this IP part of a known botnet?” #### b. Network and Firewall Apps Used to **control or monitor network security infrastructure**. - **Examples**: - Palo Alto Networks - Cisco Firepower - Fortinet - **Typical Actions**: - Block IP - Retrieve logs - Add firewall rule - **Use Case**: “Quarantine a host or block outbound traffic.” #### c. Cloud Service Apps Used to manage and secure cloud infrastructure. - **Examples**: - AWS - Azure - GCP - **Typical Actions**: - Stop/start EC2 instance - Check IAM role usage - Audit cloud logs - **Use Case**: “Disable a cloud user account or stop a suspicious VM.” #### d. Tooling / DevOps / ITSM Apps Used for integration with **operations and workflow platforms**. - **Examples**: - JIRA - ServiceNow - Slack - Splunk - **Typical Actions**: - Create ticket - Add comment - Run Splunk search - Send notification - **Use Case**: “Create a Jira issue based on a phishing case,” or “Send Slack message to SOC team.” ### Summary – Extended Knowledge Table | Feature | Purpose | | --- | --- | | **Asset Tags** | Organize and filter assets by environment, use case, or team | | **Playbook Test Mode** | Run playbooks against test containers for step-by-step verification | | **Debugging** | Use `phantom.debug()` to inspect variables and flow | | **Security Apps** | Enrich indicators with external threat intelligence | | **Firewall/Network Apps** | Control endpoints or block traffic | | **Cloud Apps** | Secure and audit cloud services (AWS, Azure) | | **ITSM/Tooling Apps** | Integrate SOAR with workflow tools like JIRA and Slack | --- # Analyst Queue (Additional Content) ### 1. **Event Lifecycle and Status Transitions** Understanding how a **container (event)** progresses through different states is crucial for queue visibility, assignment logic, and automation triggers. #### a. Common Status Flow An event typically moves through the following states: - **New**: - Default status when the container is first ingested. - Appears in the **Analyst Queue** under “Unassigned” or “All Open.” - **In Progress**: - Set either manually (by analyst) or automatically (by playbook or assignment logic). - Indicates the event is being actively worked on. - Still appears in most filtered queues. - **Closed** or **Resolved**: - Indicates that investigation and remediation are complete. - Automatically or manually set: - **Manual**: Analyst chooses to close after investigation. - **Automatic**: Playbook reaches an end state with “close_container” logic. #### b. Queue Behavior by Status - **Only New / In Progress events** appear in the **active queue views**. - **Closed containers** are hidden by default but can be found using filters or reports. #### c. Exam Relevance "Which event status is required for an analyst to begin work on an incident?" Correct answer: Both **New** and **In Progress** allow interaction, but assignment usually starts at **New**. ### 2. **Assignment and Role-Based Access Control (RBAC)** SOAR uses **role-based permissions** to determine which users can view or claim incidents. #### a. Assignment Capabilities by Role - **Administrator**: - Full visibility over all containers. - Can assign events to anyone. - Can override or reassign as needed. - **Automation / Limited Roles**: - May lack **assign** privileges. - May be restricted to viewing only **assigned containers** or containers **tagged to their team**. - **Analyst Role** (common operational role): - Can assign events to self **if permissions allow**. - Typically cannot assign to other users unless explicitly granted. #### b. Visibility Rules - Analysts **see containers** that are: - Assigned to them - Public or assigned to their team/group - Tagged for their role - Events not assigned or outside scope may not appear in their Analyst Queue view. #### c. Exam Relevance "Which of the following users can assign a container to another analyst?" Correct answer: **Admin** (or roles with explicit assign permissions) ### 3. **Default and Custom Views in the Analyst Queue** SOAR supports **custom queue views** that can be saved and reused. This helps analysts focus on relevant incidents quickly. #### a. Default Views - Predefined by the system, such as: - **All Open** - **Unassigned** - **High Severity** - **My Assigned Cases** #### b. Custom Views Analysts can define and save their own filters: - By: - Tags - Source - Severity - Status - Owner - Saved as: - Personal workspace views - **Pinned** for quick access on login - Custom views help improve **workflow efficiency** and reduce context switching. #### c. Exam Relevance "What feature allows an analyst to create a persistent filtered view of only phishing-related, high severity, unassigned events?" Correct answer: **Custom Saved View (within Analyst Queue)** ### Summary | Feature | Description | | --- | --- | | **Event Status Flow** | New → In Progress → Closed, with both manual and automated transitions | | **Queue Visibility** | Only non-closed containers appear by default; others require filters | | **Assignment & RBAC** | Not all roles can assign; Admin has full access, Analysts may have scoped views | | **Default Views** | System-defined filters such as High Severity or Unassigned | | **Custom Views** | Analysts can save personalized views to filter by tags, severity, etc. | --- # The Investigation Page (Additional Content) ### 1. **Artifact Pinning and Criticality Flags** Analysts often need to highlight key data points (artifacts) within a case to draw attention for triage or collaboration. Splunk SOAR supports **artifact annotation features** to support this. #### a. Pinning Artifacts - Analysts can **"pin" artifacts** to the top of the page or to a summary panel. - Pinned artifacts become more visible in the **Investigation Overview**, making it easier for other team members to quickly identify what matters. #### b. Marking as Critical - Certain artifacts (e.g., IPs, file hashes, or email addresses) can be flagged as **critical**. - This helps in: - Prioritizing actions - Triggering additional playbooks or alerts - Auditing post-incident reviews #### c. Exam Relevance *"How can an analyst highlight a suspicious IP address so it stands out in the investigation view?"* Correct answer: **By pinning it or marking it as critical** ### 2. **Real-Time Playbook Monitoring and Debugging** The Investigation Page includes features to **observe and control playbook execution live**, which is essential for advanced incident handling. #### a. Live Block Status Monitoring - Each block (action, decision, prompt) of a running playbook is shown in real-time. - Analysts can see: - Which blocks are currently executing - Success/failure states - Output values of actions #### b. Debug Logs Access - If an action fails or behaves unexpectedly, analysts can: - Click into the block to see execution logs - View variable values and errors - This is essential for **troubleshooting failed automation** #### c. Intervention Options - Playbook execution can be: - **Paused** - **Aborted** - **Manually redirected**, especially if a user prompt or decision is required #### d. Exam Relevance *"Where can an analyst check the outcome of each action in a playbook while it’s running?"* Correct answer: **Within the Investigation Page's live playbook view** ### 3. **Evidence Export and Case Reporting** The Investigation Page is also a hub for generating and exporting documentation after an incident is closed — often required in compliance-driven environments. #### a. Generating Case Reports - Analysts can collect: - Timeline history - Analyst notes - Artifact interactions - Playbook execution results - This can be exported as: - **Case Summary Report** - **Audit Trail Document** #### b. Use Cases - Supports: - Incident closure reviews - Internal audits - External compliance reports (e.g., for GDPR, HIPAA, or SOC2) #### c. Exam Relevance *"After closing a case, how can an analyst prepare documentation for audit purposes?"* Correct answer: **Export a case report or timeline from the Investigation Page** ### Summary | Feature | Description | | --- | --- | | Artifact Pinning | Highlights critical data points visually during triage | | Critical Marking | Flags high-risk artifacts for prioritization and collaboration | | Live Playbook Monitoring | View each step’s execution status and outputs in real-time | | Debug Logs | Inspect action logs and values for troubleshooting | | Playbook Control | Analysts can pause, cancel, or intervene manually | | Case Report Export | Generate documentation for audits, compliance, or summaries | --- # Case Management and Workbooks (Additional Content) ### 1. **Case Resolution vs. Case Closure** Understanding the difference between *Resolved* and *Closed* statuses is essential for effective case lifecycle management — and it's a **frequent exam topic**. #### a. Resolved - Indicates that **all technical actions have been completed**: - Threat neutralized - Accounts restored or blocked - Alerts addressed - However, the case is **still open for review or validation**: - May require managerial sign-off - Additional documentation or investigation may still be pending - This status often marks the **transition phase** between operations and administrative closure. #### b. Closed - Means that the case has been **fully reviewed and approved**. - No further action is needed. - It’s officially **archived in the system** as a completed record. - Closed cases are typically used for: - Reporting - Metrics analysis - Compliance audits #### c. Exam Tip **Question Example**: “Which status indicates that the incident is fully reviewed and no further actions are required?” Correct answer: **Closed** ### 2. **Binding Workbooks to Cases** Workbooks provide structured guidance in case handling. Understanding **how they are assigned to cases** is key to workflow control. #### a. When Can You Attach a Workbook? - **At Case Creation**: - When an analyst creates a new case, they can **manually select a workbook template**. - **Via Case Templates**: - Case templates can have **default workbooks pre-configured**, so that each new case using the template automatically has a workbook attached. - **On Existing Cases**: - If a case was created without a workbook, users with sufficient permissions can **manually attach** or replace a workbook later. #### b. Permissions May Affect This - Only users with **edit or case management permissions** can change the workbook binding. - Limited-role users may not see the workbook reassignment option. #### c. Exam Tip **Question Example**: “How can a workbook be assigned to a case after it’s been created?” Correct answer: **Manually by users with proper permissions, or through a template at creation** ### 3. **Relationship Between Workbooks and Playbooks** It’s important to distinguish the **function of workbooks (human-driven)** from **playbooks (automation-driven)** — especially in exam scenarios. #### a. Workbooks Define Workflow, Not Automation - A **workbook** is a **checklist** of tasks that guides an analyst through stages of investigation (e.g., Triage, Containment, Recovery). - Tasks in a workbook can be: - **Manual**: Requires the analyst to add notes or review findings. - **Automated**: Can be configured to **trigger a playbook**. #### b. Playbooks Are Not Run Directly by the Workbook - Playbooks are **linked to tasks** inside a workbook, but not embedded inside it. - The task may say: *“Run IP Reputation Lookup”* - The workbook will **trigger the linked playbook** when this task is started. - This separation of logic allows reusability and modularity. #### c. Why This Matters - In exams, some questions might imply that **workbooks execute playbooks directly** — which is incorrect. - The correct model is: **Workbooks → Tasks → (may trigger) Playbooks** #### d. Exam Tip **Question Example**: “Does a workbook directly run playbooks as part of its execution?” Correct answer: **No — tasks within the workbook can be configured to trigger playbooks.** ### Summary | Topic | Detail | | --- | --- | | Resolved vs. Closed | *Resolved* = handled, *Closed* = verified and finalized | | Workbook Binding | Can be added via case template, at creation, or manually later | | Workbook–Playbook Link | Tasks within workbooks can trigger playbooks, but don’t run them directly | --- # 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 | --- # System Maintenance (Additional Content) ### 1. Service Dependency Hierarchy Splunk SOAR relies on multiple services running in the background. Among them, `phantomd` is the main SOAR service that powers automation logic and the web interface. However, `phantomd` depends on other services to function properly. **Key Services:** - `phantomd` – Main daemon handling UI and automation logic - `postgresql` – Manages SOAR's internal database (containers, artifacts, users) - `nginx` – Handles HTTP/S traffic for the web interface **Dependency Chain:** If `postgresql` or `nginx` fails, even if `phantomd` is running, SOAR may become unresponsive or partially functional. **Exam Relevance:** A common exam question may ask: - *If the web UI is unavailable but `phantomd` is active, which service should you check next?* - Correct answer: `nginx` ### 2. Support Package Generation and Storage When contacting Splunk Support, administrators are often asked to generate a **Support Bundle**, which contains logs, configuration files, health reports, and other diagnostic information. **Generation Methods:** - **Via Web UI:** Navigate to `Administration > System Health > Generate Support Package` - **Via Command Line:** Execute: ``` /opt/phantom/bin/generate_support_bundle.sh ``` **Default Storage Location:** Unless specified otherwise, the support bundle is stored in the following directory: ``` /opt/phantom/support/ ``` **Exam Relevance:** Questions may ask: - *Where is the support package stored after generation via CLI?* - Correct answer: `/opt/phantom/support/` ### 3. Automated Health Monitoring and Alerting While SOAR has a built-in System Health dashboard, it does not send alerts by default. Organizations must configure external tools to actively monitor SOAR’s status. **Monitoring Options:** - Polling the system health endpoint: ``` /rest/system_health ``` - Parsing logs in `/var/log/phantom/` - Setting alerts on metrics such as: - CPU load - Memory usage - Disk consumption - Service failures **Recommended Tools:** - Splunk (via Universal Forwarder or HEC) - Prometheus and Grafana - Nagios - ELK Stack **Best Practice:** Use external tools to continuously poll SOAR’s health API or monitor logs for critical keywords such as “service failed”, “out of memory”, or “disk full”. **Exam Relevance:** A typical question might ask: - *Which method is most suitable to alert administrators if disk usage exceeds 90 percent?* - Correct answer: Configure an external monitoring tool to query the health API or monitor log output. ### Summary | Area | Detail | | --- | --- | | Service Dependencies | `phantomd` depends on both `postgresql` and `nginx` | | Support Bundle Location | Stored at `/opt/phantom/support/` by default | | Health Monitoring | Best done with external tools using API polling or log analysis | --- # 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` | --- # Visual Playbook Editor (Additional Content) ### 1. Saving and Publishing a Visual Playbook After building or editing a playbook in the **Visual Playbook Editor**, it is **not immediately usable** until it is **saved and published**. This is a critical step, particularly for playbooks intended to run automatically or be reused by other users or playbooks. - **Save**: Stores the current edits. - **Publish**: Marks the version as active and available for automation or manual execution. If a playbook is **not published**, it **will not appear** in: - Playbook selectors - Automation trigger options - Manual execution menus **Clarifying Sentence:** “Once a playbook is built in the visual editor, you must save and then publish it to make it available for use or automation.” **Common Exam Question Style:** - *True or False: An unpublished playbook will automatically run when a matching event is ingested.* - Correct answer: False ### 2. Where to Define Automatic vs. Manual Execution Playbooks can be configured to run under specific conditions such as: - **Automatically** (e.g., when an event is ingested) - **Manually** (triggered by an analyst) - **On a schedule** The configuration for this is located in the **Start Block** of the Visual Playbook Editor. Inside the **Start Block** settings, you can define: - **Trigger type** (event ingestion, manual trigger, scheduled run) - Optional **filter conditions** (e.g., container type, severity, label) **Clarifying Sentence:** “Trigger settings are configured in the Start Block where you define whether the playbook runs on ingestion, manually, or on schedule.” **Common Exam Question Style:** - *Where do you specify whether a playbook should run automatically when a new event is received?* - Correct answer: In the Start Block ### 3. Decision Block Branching Capabilities The **Decision Block** in the Visual Playbook Editor supports logical branching, allowing your automation to handle different scenarios. - Each branch represents the result of a condition (e.g., `True`, `False`, or custom expression) - While most commonly used for binary logic (`Yes/No`, `match/no match`), you can define **multiple condition branches** - This is useful for multi-path decisioning, such as: - `severity == high` - `severity == medium` - `severity == low` **Clarifying Sentence:** “Decision blocks can support multiple branches, each representing a condition outcome, such as True/False or multi-condition scenarios.” **Common Exam Question Style:** - *How many conditional branches can a decision block support in the Visual Playbook Editor?* - Correct answer: Multiple (based on condition outcomes) ### Summary | Concept | Clarification | | --- | --- | | Save and Publish | Only published playbooks are executable or selectable | | Trigger Definition | Configured inside the Start Block of the playbook | | Decision Logic | Decision blocks can handle multi-branch conditional flows | --- # Logic, Filters, and User Interaction (Additional Content) ### 1. Default Paths in Decision Blocks In Splunk SOAR, **Decision Blocks** are used to route playbook logic based on conditions. If **none of the specified conditions are met**, the playbook can follow a **default path** to ensure it doesn’t get stuck or fail unexpectedly. **Key Point:** “If no conditions in a Decision Block are met, the playbook can continue through a default path (if configured). This prevents the playbook from stalling unexpectedly.” **Example Use Case:** - Decision block checks for: - Severity == High - Severity == Medium - If neither condition matches (e.g., severity is Low), the default path can be used to: - End the playbook - Log a message - Trigger a minimal workflow **Exam Tip:** This concept often appears in **True/False or behavior-based questions**, such as: - *If no conditions are matched in a Decision Block, the playbook will always stop execution.* → False ### 2. Prompt Timeout Handling By default, **Prompt Blocks** pause the playbook until a human user responds. However, to prevent indefinite delays, analysts can configure **timeout settings** and **fallback behaviors**. **Key Features:** - **Prompt Timeout**: Sets a maximum wait time (e.g., 10 minutes, 2 hours). - **Timeout Action**: Defines what to do if no response is received. **Use Case:** - Escalate the case if no analyst responds within 30 minutes. - Use a default value (e.g., auto-isolate the host). - Send a Slack message notifying the shift lead. **Clarifying Sentence:** “Analysts can configure a prompt timeout to avoid indefinite pauses. A timeout action can be defined, such as escalating the case or continuing with default input.” ### 3. Error Branching in Decision Blocks Sometimes a Decision Block may evaluate a variable or field that’s missing, malformed, or throws an error (e.g., trying to compare an empty string or null value). To handle this safely, Decision Blocks support **error branches**. **Benefits:** - Prevent playbook crashes - Route errors to specific handling paths - Trigger alerts or fallback logic **Clarifying Sentence:** “Decision blocks can be configured to handle errors gracefully, by using an ‘error’ branch that ensures the playbook doesn't crash if unexpected data is encountered.” ### 4. Filters in Code Blocks In addition to visual filters on artifacts or actions, many developers use **custom Python filtering** in **Code Blocks** for complex logic. **Why It Matters:** - Visual filters are limited to basic comparisons. - Python allows: - Regex filtering - Nested list/dictionary processing - Advanced data parsing **Clarifying Sentence:** “In code-based playbooks, developers often apply additional filtering using Python for complex logic not covered by visual filters.” **Example:** ```python filtered = [i for i in ip_list if not i.startswith("192.168")] ``` ### 5. Using Tags in Logic Triggers Tags applied to containers, artifacts, or events are often used in logic conditions to trigger specific playbook flows. **Example Logic:** ```python if "VIP" in container.get("tags", []): # Take extra precautions ``` **Use Cases:** - Apply extra validation for **VIP users** - Route phishing emails with **"external"** tag to Tier 2 team **Clarifying Sentence:** “Tags added to events or containers can be used in decision logic, e.g., if ‘VIP’ in container.tags to trigger special handling.” ### 6. Multi-language Support for User Interaction In global or MSSP environments, SOAR supports **multi-language customization** in user interaction blocks (e.g., Prompts, Choices). **Features:** - Prompt text, dropdowns, tooltips can be localized per team - Ensures clarity and consistency for analysts in different regions **Clarifying Sentence:** “User interaction elements like Prompts and Choices can be customized in multiple languages, supporting international teams and regional workflows.” **Exam Implication:** - Scenario questions may ask: - *How would a multinational MSSP ensure prompt clarity across teams?* - Correct answer: Customize prompt text per language region. ### Summary | Topic | Key Clarification | | --- | --- | | Default Path in Decision Block | Ensures execution continues if no condition is met | | Prompt Timeout | Avoids indefinite waits; enables fallback behavior | | Error Handling in Decisions | Adds resilience when data is missing or broken | | Code Block Filters | Allows fine-grained data filtering with Python | | Tags in Logic | Used to trigger condition-based playbook routing | | Multi-language Prompts | Supports global analyst teams with localized inputs | --- # Formatted Output and Data Access (Additional Content) ### 1. Variable Scope and Accessibility Understanding **where and how variables can be used** is crucial for successful playbook design and troubleshooting. **Key Clarification:** Variables in Splunk SOAR playbooks have different scopes depending on how and where they were created: - **Local Variables in Code Blocks:** These are only usable within the same block where they are defined. Example: ```python ip_list = ["1.2.3.4"] # Only available in this code block ``` - **Action Results:** These are accessible in later blocks **only if you use datapaths** or collect them explicitly. - **Global Context via `phantom.save_run_data()` and `phantom.collect2()`:** Variables stored using `save_run_data()` can be accessed in Format Blocks and other code blocks using `phantom.collect2()`. **Sample Usage:** ```python phantom.save_run_data(key="filtered_ips", value=filtered_ips) ``` Then in Format Block: ``` "IPs in scope: {run_data.filtered_ips}" ``` **Exam Tip:** "Which method allows passing a filtered variable list between blocks?" Correct answer: `phantom.save_run_data()` + `run_data.variable_name` in Format Block. ### 2. Content Types Supported by Format Blocks Format Blocks in SOAR are powerful but **not all content types are equally supported**, and this is a common point in technical exam questions. | Content Type | Supported | Notes | | --- | --- | --- | | Plain Text | Yes | Default output method | | HTML | Yes | Used especially for email formatting or dashboards | | Markdown | Partially | Some outputs (e.g., Slack, Teams) render markdown formatting | | Raw JSON | No | JSON must be preprocessed in a Code Block and rendered as string | **Clarifying Sentence:** "Format Blocks support plain text, HTML, and limited Markdown rendering; they do not directly output structured JSON unless first converted to string format via code." **Example for HTML Formatting:** ```html "Malicious IP Detected: {artifact:*.cef.destinationAddress}" ``` **Example for Markdown (limited):** ``` **Source IP:** {artifact:*.cef.sourceAddress} ``` ### 3. Combining Code Blocks and Format Blocks In advanced use cases, raw data must be **filtered, cleaned, or calculated in a Code Block** before it is used in a Format Block. **Use Case:** 1. In a **Code Block**, filter only internal IPs: ```python internal_ips = [ip for ip in all_ips if ip.startswith("192.")] phantom.save_run_data(key="internal_ips", value=internal_ips) ``` 2. In a **Format Block**, use the result: ``` "Internal IPs detected: {run_data.internal_ips}" ``` This technique allows: - More control over output content - Reuse of complex logic without cluttering the Format Block - Cleaner separation of logic (processing vs. presentation) **Exam Tip:** "Which sequence allows dynamic message building from filtered IPs?" Correct answer: *Code Block to filter > `phantom.save_run_data()` > Format Block using `{run_data.key}`* ### Summary | Topic | Key Point | | --- | --- | | Variable Scope | Only explicitly saved variables (`run_data`) persist across blocks | | Format Block Types | Text, HTML, Markdown supported; JSON needs preprocessing | | Format + Code Combo | Use `phantom.save_run_data()` to pass logic output into Format Blocks | --- # Modular Playbook Development (Additional Content) ### 1. Defining Input Parameters in Child Playbooks **Purpose:** To make child playbooks reusable and dynamic, they should be designed to accept **input parameters** from the parent playbook. **How to Define Inputs:** - In the child playbook: - Go to the **"Playbook Settings"** panel. - Navigate to the **"Input" tab**. - Click **"Add Parameter"** to define: - Name (e.g., `username`) - Data type (string, list, integer, etc.) - Whether it's required or optional - Default values (optional) **Passing Values from Parent:** - In the **parent playbook**, add a **Playbook Block**. - Choose the target child playbook. - Under the **"Input Mapping"** section: - Select source variables (from artifacts, previous actions, code blocks, etc.). - Map them to the corresponding input parameters defined in the child. **Example Scenario:** - **Child Playbook Input:** `target_ip` - **Parent Playbook Mapping:** `{artifact:*.cef.destinationAddress}` **Exam-Relevant Detail:** You must explicitly define input parameters for a child playbook to receive values. Otherwise, the playbook will not function as intended. ### 2. Sharing Child Playbooks Across Tenants or Teams **Context:** In **multi-team** or **multi-tenant** SOAR environments (e.g., MSSPs), playbook sharing strategy becomes critical for governance and consistency. **Best Practice:** - **Global Playbook Publishing:** - Mark reusable child playbooks as **Global**. - This makes them available across all containers and teams, regardless of the event type or asset source. - Ideal for utility playbooks like “IP enrichment” or “User disable.” - **Access Control:** - Set appropriate permissions: - Mark as **read-only** if you want to restrict modification. - Assign visibility based on **role-based access control (RBAC)**. **Governance Note:** Avoid duplicating playbooks across teams unless customization is needed. Maintain one global version to reduce maintenance overhead. **Exam Tip:** When asked, “How should a utility playbook be made reusable by all teams?”, the answer should be: “Set the playbook as global and assign read-only access where applicable.” ### 3. Version Control Strategy for Child Playbooks Unlike source code in a Git repository, SOAR playbooks don't inherently support **automatic version control**, so you must manage versions manually. **Recommended Practices:** - **Naming Conventions:** - Use clear, versioned naming such as: - `enrich_ip_v1` - `block_user_v2` - `notify_user_beta` - **Description Field:** - Use the playbook’s **description** to document: - Version history - Change log - Author and date - Intended use case or constraints - **Cloning for Iteration:** - When updating logic: - Clone the playbook. - Update the name and description. - Test thoroughly before retiring the previous version. - **Review Cadence:** - Periodically review all published child playbooks. - Retire or merge obsolete versions. **Why This Matters for Exams:** A common scenario in questions: "You need to introduce a change to a widely used child playbook without disrupting current operations. What is the best approach?" Correct answer: "Clone the playbook, version it, and test before deployment." ### Summary | Topic | Key Practice | | --- | --- | | Input Parameters | Define in child, map in parent via Playbook Block | | Sharing Across Teams | Use Global + Read-Only for multi-tenant reuse | | Version Control | Use naming conventions (`_v1`, `_v2`), document changes, clone for updates | --- # 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: ```python 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: ```python 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 | --- # Configuring External Splunk Search (Additional Content) ### 1. Saved Search Invocation via Splunk App **Purpose:** Instead of writing full SPL queries directly inside the playbook, analysts can use **saved searches** created and maintained within the Splunk platform. This improves consistency, simplifies complex queries, and enhances maintainability. **How to Use in SOAR:** - The **Splunk App for SOAR** supports an action called: - **`run saved search`** (or similar, depending on the app version) - Required Input Parameters: - **Saved Search Name**: The exact name of the saved search in Splunk. - **Search Parameters (if any)**: Some saved searches are configured to accept tokens or arguments, which must be passed in from SOAR. **Example Workflow:** - In Splunk: - Saved search named `get_recent_logins` with SPL: ```spl search index=auth sourcetype=linux_secure user=$user$ ``` - In SOAR: - Use `run saved search` action with: - Saved search name: `get_recent_logins` - Parameter `user`: extracted from an artifact or playbook variable **Advantages:** - Reduces complexity in playbooks. - Allows central management of search logic. - Enables version control of core detection logic on Splunk side. ### 2. Result Handling Techniques for Search Output **Purpose:** After running a search (saved or raw SPL), SOAR playbooks must parse and utilize the returned data. Understanding how to access the correct fields is critical for building reliable logic and formatted outputs. **Common Access Pattern:** - The response from a Splunk search action is typically found in: ```python results[0].get("data", [])[0].get("field_name") ``` - **`results[0]`**: The first result block from the action. - **`.get("data", [])`**: Retrieves the list of events (rows). - **`[0]`**: Selects the first event row. - **`.get("field_name")`**: Gets the desired field value. **Example Use in Format Block:** ```python phantom.format(container=container, template="Last login was from {0}", parameters=[("action_result.data.*.src_ip",)]) ``` **Best Practice:** - Use **phantom.debug()** during testing to log and inspect the actual keys returned from the search. - Always use `.get()` with a default to avoid KeyErrors if the field is missing. ### 3. Permissions Error vs. Network Error – Troubleshooting Scenario **Purpose:** When an external Splunk search fails, it's important to distinguish **access issues** from **connectivity problems**. Understanding the typical error signatures helps in rapid diagnosis and resolution. **Case Study Example:** - **Scenario 1 – Permission Denied:** - The Splunk asset is reachable, but the user account does **not** have permission to search the requested index. - **Typical error in action result:** ```json { "status": "fail", "message": "You do not have permission to access index=wineventlog" } ``` - **Resolution:** - Check Splunk user role. - Confirm index permissions in Splunk roles. - **Scenario 2 – Network or Asset Misconfiguration:** - The Splunk server is **not reachable** (firewall, DNS, or misconfigured URL/port). - **Typical error message:** ```json { "status": "fail", "message": "Connection refused" or "Unable to connect to Splunk server" } ``` - **Resolution:** - Validate asset configuration (URL, port, auth). - Ping the server or use `curl` to verify access. - Check if Splunk REST API port (usually 8089) is open. **Best Practice Tip:** Always run **“Test Connectivity”** in the asset configuration panel after any changes, and check the **phantomd.log** or **action_result.summary** for error root cause clues. ### Summary | Topic | Expanded Insight | | --- | --- | | Saved Search Use | Reuse named searches from Splunk to simplify playbooks | | Result Parsing | Use `.get("data", [])[0].get("field")` to extract and use search results safely | | Error Diagnosis | Distinguish permission denial from connectivity issues via error message content | --- # Integrating SOAR into Splunk (Additional Content) ### 1. **Custom Alert Actions in Splunk (Forwarding Data to SOAR)** **What is a Custom Alert Action?** In Splunk, a **Custom Alert Action** is a mechanism that allows search results to be sent to external systems — in this case, to **Splunk SOAR** — for further automated processing. **Configuration Steps:** - Go to **Splunk Enterprise Security**. - Under **Content Management**, select a **Correlation Search**. - Edit the search and add an **Alert Action**. - Choose one of the following (depending on app version): - **Send to Phantom** - **Run Playbook** - Configure the destination SOAR asset, playbook (optional), and parameters if required. **Default Fields Sent to SOAR:** - `event_id` - `host` - `user` - `source_ip` - `dest_ip` - `timestamp` - Other relevant search result fields **How these are used in SOAR:** These values are packaged as **CEF-formatted artifacts** and attached to a container representing the incoming event. ### 2. **Event and Artifact Mapping Logic in SOAR** **How Splunk Data Arrives in SOAR:** - Data is sent from Splunk using: - The **SOAR app on Splunk** (uses REST API) - **Adaptive Response Framework (ARF)** (via manual analyst action) - SOAR receives this as a **container**, with structured data inside **artifacts** **How the Structure Works in SOAR:** - The **event** becomes a **container** (a unit of investigation). - Each **field** from the Splunk result becomes part of an **artifact** in the container. - Example: - `source_ip` → `cef.sourceAddress` - `username` → `cef.destinationUserName` **Field Mapping Recommendation:** - Use Splunk's **Common Information Model (CIM)** fields wherever possible. - Ensures compatibility with existing playbooks and enrichments inside SOAR. ### 3. **Authentication and Permission Considerations** **On the Splunk Side:** - Users must have permissions to run alert actions that send data to SOAR. - API calls must be authenticated: - Best practice: Use **API tokens** - Alternative: **Splunk Secure Gateway** **On the SOAR Side:** - You must configure a **Splunk Asset** that: - Accepts API-based connections - Specifies allowed authentication method (Basic Auth or Token) - Has the correct port open (default for API is 443 or 8443 depending on setup) **Security Recommendations:** - **Restrict API tokens** to least privilege — allow only necessary playbooks or containers. - **Use HTTPS** for encrypted data transmission. - **Log all API interactions** — helpful for audit trails or detecting misuse. ### 4. **Advanced Feedback Mechanism (Closing the Loop)** After SOAR processes the event, it can **send results back to Splunk** to complete the lifecycle. **Examples of Feedback Actions:** - Write back to a **summary index** in Splunk: - This enables dashboards or audit trails of SOAR actions. - Update the **status of a notable event** (e.g., from “New” to “Resolved”). - Add metadata like: - **Tags** - **Risk scores** - **Comments or resolution details** **Example:** ```spl | inputlookup phantom_results.csv | eval status="Resolved" ``` **Purpose:** This integration ensures full visibility and traceability — from detection to response to documentation — all within the analyst’s SIEM dashboard. ### 5. **Troubleshooting Guide – Common Integration Issues** A brief **FAQ-style section** can help tackle real-world issues that also appear in exams: **Issue:** SOAR is not receiving events from Splunk - **Check:** App configuration, API address, authentication settings **Issue:** Playbook did not trigger after ingestion - **Check:** - Is there a **default playbook** assigned to the container label? - Are **event labels** mapped properly? - Is **playbook trigger mode** set to “on ingestion”? **Issue:** Incomplete or missing data in SOAR - **Check:** - Are fields properly mapped in the Splunk alert action? - Is the payload **JSON-formatted and valid**? - Are all required fields present and structured under `cef`? ### Summary | Topic | Details | | --- | --- | | Custom Alert Action | Sends Correlation Search results from Splunk to SOAR as structured events | | Artifact Mapping | Splunk fields are mapped to SOAR artifacts (e.g., `cef.sourceAddress`) | | Authentication | Use API tokens with least privilege; secure communication with HTTPS | | Feedback Mechanism | Send results from SOAR back to Splunk (update notable, write to index) | | Troubleshooting | Validate playbook triggers, data mapping, and Splunk-SOAR connectivity | --- # Custom Coding (Additional Content) ### 1. **Custom Function Input and Output Format Recommendations** Custom Functions in Splunk SOAR are reusable Python components that enable teams to encapsulate logic and share it across multiple playbooks. **Defining Input Parameters:** - Inputs are declared as part of the function metadata. - You can specify: - **Type** (string, list, integer, boolean) - **Required or optional** - **Array support** (e.g., `["ip1", "ip2"]`) - Input validation can be implemented in code if needed. **Returning Output:** - The function must return a **Python dictionary**. - Best practice: return consistent, structured keys so the output can be used in downstream blocks. **Example Output Format:** ```python outputs = { "tlds": [".com", ".net", ".org"], "count": 3 } return outputs ``` **Function Registration Metadata:** - When defining a custom function, you provide: - **Title**: Shown in the playbook interface. - **Category**: Helps organize functions (e.g., “Utilities” or “Parsing”). - **Output schema**: Defines what downstream blocks can access. ### 2. **Exception Handling in Code Blocks and Apps** To ensure playbooks are resilient, custom Python code should gracefully handle errors and exceptions. **Pattern for Exception Handling:** ```python try: response = requests.get(url) response.raise_for_status() phantom.debug("Success: {}".format(response.json())) except Exception as e: phantom.error("Request failed: {}".format(str(e))) ``` **Key Practices:** - **Always use try/except blocks** when calling external APIs or handling untrusted data. - Use `phantom.error()` for logging failures to make debugging easier. - Avoid unhandled exceptions, as they can **break playbook execution**. **In Custom Apps:** - Each action should catch exceptions and return: - `status`: "success" or "failed" - `message`: Diagnostic information ### 3. **Integration with Custom Lists and Saved Variables** Custom code can be enhanced by dynamically pulling context-specific data using SOAR’s internal storage mechanisms. **Accessing a Custom List:** ```python status, values = phantom.get_list("HighRiskCountries") if status: country_list = [entry[0] for entry in values] ``` - This allows you to build context-aware logic, like checking if a geolocation exists in a threat list. **Working with Saved Variables:** You can access saved values from the container or artifacts: ```python source_ip = container.get("source_data_identifier", "") username = artifact.get("cef", {}).get("destinationUserName", "") ``` Or use `phantom.collect2()` for structured access: ```python phantom.collect2(container=container, datapath=["artifact:*.cef.sourceAddress"]) ``` These techniques support **data-driven playbook logic**. ### 4. **Execution Environment and Permissions** When developing custom code, it’s essential to understand the **security and execution boundaries** enforced by Splunk SOAR. **Code Block Environment:** - Runs in a **sandboxed Python 3.x interpreter**. - Cannot: - Execute shell/system commands (e.g., `os.system("rm -rf /")`) - Access arbitrary files outside the permitted scope - Safe for logic, loops, data parsing, and API requests. **Custom App Considerations:** - Apps run under a **restricted SOAR runtime** with limited system-level access. - Must: - Declare required permissions in the app’s YAML file - Avoid writing to protected directories - Use secure handling of credentials and tokens **Tip:** Always validate and sanitize input to avoid code injection or security vulnerabilities. ### Summary | Category | Key Concepts | | --- | --- | | Input Parameters | Define type, array support, required status | | Output Structure | Return structured dictionaries for downstream use | | Exception Handling | Use try/except with phantom.debug() or phantom.error() | | Integration with Lists | Use phantom.get_list() to pull reference data | | Saved Field Access | Use .get(), artifact paths, or collect2() | | Secure Runtime | No OS commands in code blocks; restricted file access | | App Permissions | Declare minimal required permissions and handle creds securely | --- # Using REST (Additional Content) ### 1. Handling Authentication Failures While token-based authentication is recommended, it’s essential to understand how to **recognize and respond to authentication errors**. #### Common HTTP Response Codes and Their Meanings: - **200 OK**: The request was successful. - **401 Unauthorized**: The API token is missing, expired, or invalid. - **403 Forbidden**: The token is valid, but does not have permission to perform the action. - **500 Internal Server Error**: A generic server error, often due to misconfiguration or unexpected input. #### Troubleshooting Authentication Issues: - **Check token scope** and expiration. - **Inspect headers** to confirm the format: `Authorization: Bearer ` - Use `phantom.debug()` or external logging to capture the full response for inspection. ### 2. Pagination for Large Result Sets Most REST endpoints in SOAR use **pagination** to limit the size of responses, especially for endpoints like: - `/rest/container` - `/rest/artifact` - `/rest/playbook_run` #### Example of Paginated API Call: ```http GET /rest/container?page=0&page_size=100 ``` - **`page`**: The offset index (starting from 0). - **`page_size`**: The number of records returned per page (commonly 50–100). #### Retrieving All Records: In integration scripts, loop through pages until the result set is empty: ```python containers = [] page = 0 while True: resp = requests.get(f"{base_url}/rest/container?page={page}&page_size=100", headers=headers) data = resp.json() if not data: break containers.extend(data) page += 1 ``` ### 3. Rate Limiting and API Usage Best Practices Splunk SOAR does not impose strict public rate limits, but **enterprise environments** may configure **network or proxy-layer rate limiting** to protect system performance. #### Recommendations: - Avoid **sending large bursts of requests** (e.g., hundreds per second). - Implement **retry logic** with **backoff delays**. - Monitor for HTTP 429 (Too Many Requests), if applicable. Some environments implement **API quotas**, especially in multi-tenant setups or via reverse proxies. ### 4. Asynchronous Operations and Monitoring Status Some REST API operations, such as triggering a playbook, are **asynchronous**. This means the API call will return a response immediately, but the actual task continues to run in the background. #### Monitoring Playbook Execution: When calling `/rest/playbook_run`, you receive a `run_id`. You can query the status using: ```http GET /rest/playbook_run/ ``` The response will include: - **status**: e.g., “in_progress”, “completed”, “failed” - **summary**: Outputs or errors returned by the playbook Use this endpoint to check the outcome before proceeding in your integration logic. ### 5. Error Handling in Python Scripts (Developer Practice) To build robust integrations with SOAR’s API, use structured error handling to manage connection failures, timeouts, or unexpected API responses. #### Enhanced Python Sample: ```python import requests try: response = requests.get("https://soar.company.com/rest/container", headers=headers) response.raise_for_status() containers = response.json() except requests.exceptions.HTTPError as http_err: print(f"HTTP error occurred: {http_err}") except requests.exceptions.RequestException as err: print(f"Network error occurred: {err}") ``` Benefits: - Prevents script crashes - Enables automated retry, logging, and alerts ### 6. Secure Storage of API Tokens **Never hard-code API tokens** in your source code. #### Recommended Practices: - Store tokens in **environment variables**: ```bash export SOAR_TOKEN="your_token" ``` - In Python, access it with: ```python import os token = os.getenv("SOAR_TOKEN") ``` - For production environments, use **secret management tools** like: - **HashiCorp Vault** - **AWS Secrets Manager** - **Azure Key Vault** Tokens should be **rotated regularly** and **scoped** to the minimal required permissions. ### Summary | Topic | Description | | --- | --- | | Auth Failures | Understand and handle 401/403 errors properly | | Pagination | Use page and page_size to fetch large datasets | | Rate Limiting | Avoid excessive calls; use retry with delay | | Async Monitoring | Use `/rest/playbook_run/` to check status | | Error Handling | Wrap API calls in try/except for stability | | Token Security | Store secrets outside code; use env vars or secret managers | ---

Shopping cart

Subtotal:

Examination Introduction

Learning Method

Study Plan

Exam Center