SPLK-2003 Deployment, Installation, and Initial Configuration

Deployment, Installation, and Initial Configuration Detailed Explanation

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.

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:

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_<appname>.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:

  /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