security information

This topic explains the fundamentals of the system design and base security measures, as well as the parameters and limitations for that design.

Operating System

runs on top of one of the supported operating systems:

1. Red Hat Enterprise Linux 7.6 through 7.9
2. CentOS 7.6 through 7.9

If you deployed using the Amazon Marketplace Image (AMI), the base operating system is CentOS 7.9.

does not monitor or control the operating system on which it is deployed.

Basic OS privilege separation is utilized, partitions are mounted with limited capabilities, and SELinux is on.

Processes and daemons

runs multiple processes and daemons:

• The web-based user interface runs in the http process as the nginx user. uses a custom httpd configuration. Use caution if you update http.
• In a privileged deployment the watchdogd daemon runs as root and is responsible for starting or stopping other processes, collecting system and process information, and installing RPMs.
• In an unprivileged deployment the watchdogd daemon runs as the phantom user and some of its abilities that require root permissions are removed.
• All other daemons run as the phantom user.

Start up

This section provides a brief overview of what happens when starts.

• In privileged deployments, the daemon phantom_watchdogd is configured as a systemd service via systemctl to start when the system boots. When phantom_watchdogd starts up, it brings up all the other processes.
• In cloud and unprivileged deployments, because does not have root level access to configure systemd items, the user account that runs has its crontab modified to run <$PHANTOM_HOME>/bin/start_phantom.sh at system boot time.

Access to the operating system

users do not have access to the operating system of their deployment.

Access to the operating system is separate from access to the web-based user interface. It is managed by a systems administrator. Accounts added or removed using the operating system shell do not affect the ability to log in to the web-based user interface. utilizes local database accounts or remote identity providers for authentication to the web-based user interface.

If you deployed from a virtual machine image, remote SSH access as the root user is disabled by default.

Ultimately, it is impossible for to be secure against an attacker who has access to or control of the local operating system or virtualization platform where it is deployed. can have assets with configured credentials, such as firewalls, mail servers, for Active Directory, or other critical infrastructure. Because an attacker with root access can access everything they need to reverse engineer or bypass access controls, it is vitally important that the operating system and any virtualization platform be made secure.

Ports and endpoints

requires access to several ports and endpoints in order to function. Lists of the needed ports and endpoints are available at ports and endpoints.

System maintenance and updates

System maintenance tasks, such as system software patching, maintaining disk space, and managing operating system access are the responsibility of customer's systems administrators.

System backups or virtual machine snapshots should be made before performing any system changes. If you have concerns about whether an update or change is likely to affect the operation of open a Support case.

Privileged vs unprivileged deployments

can be deployed as either privileged or unprivileged.

Unprivileged deployment differences from a privileged deployment

• RPM dependencies are replaced with unprivileged versions.
  • pgbouncer
  • nginx
  • postgresql
  • git
• The ownership of everything under <$PHANTOM_HOME> is set to phantom:phantom.
• Remove rsyslog configuration.
• logs are moved from /var/log/phantom to <$PHANTOM_HOME>/var/log/phantom
• Replaces the root shell with bash. Privileged installs normally use a setup shell provided by Splunk Phantom.
• Configure a firewall port forward from the custom unprivileged HTTPS port to 443 (requires firewalld).

Authentication

uses its own authentication database, independent of the linux operating system.

There are several options for web UI authentication. The local user database uses the default Django PBKDF2 hash. See the Wikipedia article https://en.wikipedia.org/wiki/PBKDF2 for more information. Other options include:

• LDAP/LDAPS
• OAUTH
• SAML

supports using Duo for two-factor authentication.

supports password complexity for its local accounts. Users that require the most advanced account security features are encouraged to use an external identity provider.

does use a certificate store for authenticating the LDAPS authentication server.

For more on information configuring users, two-factor authentication, and passwords, see the section Manage your users and accounts in Administer .

Clustering

can be deployed as a cluster, using multiple nodes which can share a PostgreSQL database, filesystem, Splunk Enterprise instance, and distribute running apps, playbooks, and action runs between them.

Because any node may introduce new Python code into the system as an app or playbook, an attacker compromising any one single node has the ability to compromise all the other nodes and services in the same way.

If one cluster node is determined to be compromised at the OS level, all the other cluster nodes and services should be assumed to be compromised as well.

SSL and TLS

has a certificate store used to validate certificates when opening connections to other servers.

The certificates in the store are trusted certificate authority (CA) certificates from mkcert.org. In almost all cases, can use its certificate store to validate any certificate issued by a commercial certificate authority (CA).

If an asset uses TLS and has a self-signed certificate, or if you have an in-house certificate authority, then those certificates must be imported into the store for verification to work.

This includes any necessary intermediate certificates. Note that the requirement for the Common Name to match still applies, so if the certificate is for server.example.com, then the asset must also be configured to connect to it as server.example.com, and not a different form of the name such as "server", or an IP address.

See certificate store overview

TLS versions and ciphers

supports TLS versions TLSv1.2 and TLSv1.3. The ciphers supported by are those supported by FIPS 140-2 level 2.

The following shows a list of the supported ciphers.

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

TLS_AES_128_GCM_SHA256

ECDHE-ECDSA-AES256-GCM-SHA384

ECDHE-RSA-AES256-GCM-SHA384

DHE-DSS-AES256-GCM-SHA384

DHE-RSA-AES256-GCM-SHA384

RSA-PSK-AES256-GCM-SHA384

DHE-PSK-AES256-GCM-SHA384

AES256-GCM-SHA384

PSK-AES256-GCM-SHA384

ECDHE-ECDSA-AES128-GCM-SHA256

ECDHE-RSA-AES128-GCM-SHA256

DHE-DSS-AES128-GCM-SHA256

DHE-RSA-AES128-GCM-SHA256

RSA-PSK-AES128-GCM-SHA256

DHE-PSK-AES128-GCM-SHA256

AES128-GCM-SHA256

PSK-AES128-GCM-SHA256

Embedded git client

The git client uses the OpenSSL certificate store, which includes most commercial CAs. Git repositories can be configured to use an HTTPS URI if that repository uses a signed certificate from a commercial certificate authority.

If you need to connect to a git repo that uses an unrecognized CA, you have to disable git certificate checking system-wide.

Playbooks, apps, and Python code

uses user-supplied Python code in several ways.

• Apps are collections of Python code and JSON configuration files that allow to connect to, use, and control other products or services. Apps provide Actions to , to make controlling your security infrastructure easy.
• Playbooks are specially-crafted Python code that utilize Python libraries run actions, use apps, or run custom code.

Apps and playbooks are available from several sources:

• Splunk provides several apps and playbooks from Splunkbase, the Phantom Portal, and a GitHub repository.
• You can develop apps and playbooks yourself.
• You can get apps or playbooks from third parties, such as other users.

When running, the python code from Apps and Playbooks are running as either the linux user account phantom, or the specified account that runs .

It is critical that any untrusted code you obtain from other sources be examined thoroughly.

Python code runs without restrictions other than that it is running as a user account without any special privileges. There is no sandbox of any kind. Anything that the Python language with common libraries can do can be done from an app's or playbook's code. If apps, or assets have configured credentials, obtaining those credentials is possible from an app or playbook's code.

Malicious apps can also introduce hostile HTML into the web user interface in two places:

• App documentation can include HTML.
• Apps often include widgets which render HTML in the web user interface.

Any sort of attack that one could typically perform with an XSS exploit could also be performed by a malicious app. This can allow complete control of the UI for a logged-in administrator account.

In addition to malicious behavior, it's also possible for app authors to inadvertently introduce security holes.

For example, an app author may make a system call to run a command, and pass user-supplied data to the shell without properly sanitizing the inputs, potentially leading to a command injection vulnerability. Worse, they might pick up input from a security alert that ultimately came from an outside attacker, and do the same.

User accounts, roles, and privileges

supports multiple types of users, has a number of built-in roles which can be assigned to users, and the ability to define custom roles with customized individual privileges.

See also:

• Manage users
• Manage roles and permissions in

Noteworthy user privileges and roles

When auditing your deployment's security, these user accounts and privileges which are especially important. While these roles privileges are expected to be given only to trusted users, it is vitally important to know what capabilities you are trusting them with before doing so.

Administrator role

Administrators can perform any function in the web UI. They can modify users, roles, edit or install apps, manage assets, edit or manage playbooks, change system settings, and more.

Administrators can manipulate users and assets.

• Local user accounts have passwords associated with them. Once the password is set, the UI will not display it to any account. However, an Administrator can simply change passwords.
• Assets can have stored credentials configured. Once credentials are stored, the UI will not display them to any account.

Edit Users and Roles

A user with the "Edit Users and Roles" permission, even if that is the only permission they have, can grant themselves any and all other privileges. Any user or role with this permission is effectively an administrator.

Edit Apps and/or Edit Playbooks

Users with these permissions can edit apps or playbooks, which gives them the ability to execute arbitrary Python code. This means they could leverage Python code to get access to the system shell and attempt other attacks or privilege escalations.

Edit Assets

This permission does not provide a direct path to escalate privileges on itself. With this permission a malicious actor could change an asset to connect to a different IP address or hostname for malicious server to obtain asset credentials.

Edit System Settings

The Edit System Settings privilege allows a user to modify system settings. One set of system settings are the identity providers in use. A malicious user with the Edit System Settings privilege could redirect authentication requests to an authentication server they control to obtain user credentials.