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

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

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 for privileged deployments 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 cloud deployments does not have root level access to configure systemd items. Therefore 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.

Privileged vs unprivileged deployments

is always deployed as an unprivileged installation.

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:

• 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 .

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.

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 to run actions, use apps, or run custom code.

Apps and playbooks are available from several sources:

• Splunk provides several apps and playbooks from Splunkbase 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.

Splunk SOAR (Cloud) FedRAMP Moderate environments have additional restrictions on playbook code:

• Playbooks cannot share information between playbook runs by using the host's file system.
• The directories /tmp and /opt/phantom/tmp cannot be used to share information between playbook runs. These directories can still be used to share information in the context of a single playbook run.
• Playbooks cannot read or modify the directory /opt/phantom/vault by using the file system. Playbooks that interact with the vault must use the Vault automation API.
• Playbooks cannot open direct connections to the PostgreSQL database.

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.