This topic explains the fundamentals of the system design and base security measures, as well as the parameters and limitations for that design.
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.
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.
Privileged vs unprivileged deployments
is always deployed as an unprivileged installation.
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:
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.
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.
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.
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.
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.
Take a tour of and perform product onboarding when you log in for the first time
Configure your company settings in
This documentation applies to the following versions of Splunk® SOAR (Cloud): current