Introduction to securing the Splunk platform with TLS

For the highest level of security in your Splunk platform deployment, you must secure communications between Splunk platform instances that you manage with Transport Layer Security (TLS) technology.

While Splunk manages certificates on Splunk Cloud Platform, and provides certificates for forwarders to connect to SCP to send data, it isn't possible for Splunk to protect an external deployment.

Whether the external deployment is a Splunk Enterprise instance or cluster, or is a tier of forwarders that sends data to Splunk Cloud Platform, you are responsible for securing connectivity between those Splunk components.

Read this topic to learn what TLS is, how TLS certificates work, and how to set up and configure certificates in the Splunk platform instances that you manage directly.

About transport layer security and how the Splunk platform uses it

TLS is a communications protocol that lets two computers, applications, or computing processes communicate securely and privately over a network. It provides for confidentiality and authentication and data integrity protections for that communication.

Splunk uses TLS to ensure that communications between Splunk platform instances, including Splunk Web, are protected from potential malicious actors. Splunk uses TLS extensively with every Splunk Cloud Platform instance. TLS is also an important part of Splunk platform deployments that you manage.

A large part of how TLS works is the digital certificate. Digital certificates are files that let entities that communicate using TLS to safely establish connections and encrypt data between one another. They let these entities prove to each other that they are who they say they are. Each instance in a Splunk platform deployment has at least one certificate, but can have many depending on the functions that the instance performs.

A certificate authority (CA) issues and signs the certificates, which adds a layer of authenticity to the certificates by proving the identity of the certificate owner. Typically, a CA signs a certificate for a specific domain name or group of domain names.

For increased security, all certificates have a finite time in which they are valid. When the validity of the certificate expires, you must replace it with a new certificate. Typically, certificates last anywhere from 90 days to 1 year, but can be shorter or longer.

When a certificate is valid, communications between the two entities that use the certificate is secure. Invalid certificates prevent entities from communicating with one another securely, and can let outside parties read sensitive data as the entities transmit it.

Why it is important to secure your Splunk Enterprise deployment with TLS certificates

It's important to secure your Splunk Enterprise and forwarding tier infrastructure for the following reasons:

• It's a Splunk best practice. Splunk includes certificates with every installation, and while they are not proprietary to your specific application, they provide a basic level of protection from outside parties. You can increase that level of protection by obtaining and installing your own certificates.
• Firewalls, if you use them, only provide protection from outside actors. If a malicious actor gets inside your network through your firewall, they can easily access machines inside the network, especially if you use the default certificates in your Splunk Enterprise deployment.
• It protects your data. When you secure your Splunk Enterprise infrastructure with certificates, and particularly when you use certificates that a verified third party certificate authority provides, your data is the most secure that it can be, and malicious actors that want access to it have a very hard time getting it.

About the default Splunk platform certificates

The Splunk platform installation package comes with a set of default certificates. Splunk Inc. acts as the certificate authority for the certificates because it created the software that is in the installation package. When you install Splunk Enterprise or the universal forwarder, the installer signs and places these certificates in the installation directory to let the installation communicate with other Splunk platform instances securely.

These certificates discourage casual snoopers, and are technically secure. The problem is, because the root certificate is the same in every Splunk installer, anyone with the same root certificate can authenticate into and communicate with the instance if they are on the same network. The root certificate can't be different from installer to installer, because each installer would have to be different.

The default certificates exist in every Splunk Enterprise installation. There is a certificate for handling connections between Splunk platform instances, also known as inter-Splunk or Splunk-to-Splunk communications, and an additional certificate for communications between your browser and Splunk Web and Splunk Web and other Splunk platform instances, such as search heads.

Methods to secure the Splunk platform

Splunk Cloud Platform configures TLS encryption for inter-Splunk communications and Splunk Web for nearly all instance types that Splunk manages. Splunk Cloud Platform always receives updates to security protocols, best practices, and configurations, and if you use Splunk Cloud Platform, in nearly all cases, you don't have to worry about the administrative work that is necessary to maintain certificates there.

You are responsible for the security of Splunk infrastructure that you manage, even infrastructure that connects to a Splunk Cloud Platform instance. A Splunk best practice is to use certificates that you obtain yourself to perform securement of your infrastructure. You can apply encryption or authentication using your own certificates for:

• Communications between the browser you use and Splunk Web
• Communication between other Splunk instance types, such as between forwarders and indexers, or between Splunk processes that use the Splunk management network port

Table of most common encrypted Splunk platform instance communication scenarios

The following table describes the most common communication scenarios and the default TLS settings. To understand the contents of the table, see the following column descriptions:

• Type of exchange: What kind of communication occurs between the two nodes
• Node A function: The entity that initiates the connection to the other entity; also known as the client
• Node B function: The entity that responds to the client request; also known as the server
• Default encryption: Whether or not there is encrypted communication between the two entities
• Default certificate-based authentication: Whether or not the entities use certificates for encrypted communications by default.
• Default Common Name checking: Whether or not the entities look at the certificates they receive and verify that the Common Name field within the certificate matches a certain host name or range of host names. The Common Name field typically contains the fully-qualified host name of the computer that the certificate was generated to protect
• Type of data exchanged: The kind of data that the entities exchange after they establish communications
• Cloud refers specifically to Splunk Cloud Platform. Enterprise in this table refers specifically to Splunk Enterprise and its components or the universal forwarder.

Type of exchange	Node A function	Node B function	Default encryption	Default certificate-based authentication	Default Common Name checking	Type of data exchanged
Browser to Splunk Web	Browser	Splunk Web	Cloud: enabled Enterprise: disabled	Browser determines this	Browser determines this	configuration and search data
Splunk Web to search head	Splunk Web	splunkd as a search head	enabled	Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	configuration and search data
Forwarding	splunkd as a forwarder	splunkd as an indexer	Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	data to be indexed
Splunk-to-Splunk	splunkd as a client	splunkd as a server	enabled	disabled	disabled	configuration data, user data
Deployment server to deployment clients	splunkd as a deployment client	splunkd as deployment server	enabled	Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	configuration data
Distributed search	splunkd as search peer	splunkd as a search head	enabled	Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	search data
Search head clusters	splunkd as cluster members	splunkd as cluster members	Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	cluster data
Search head cluster deployer	splunkd as cluster members	splunkd as cluster deployer	enabled	Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	configuration data
Indexer cluster peer nodes	splunkd as indexer cluster peer nodes	splunkd as indexer cluster peer nodes	Cloud: enabled Enterprise: disabled. You must use the replication_port-ssl setting in the server.conf configuration file to enable replication of data over TLS	'Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	replication data
Indexer cluster manager (or master)	splunkd as peer and search head nodes	splunkd as a manager (or master) node	enabled	Cloud: enabled Enterprise: disabled	Cloud: enabled Enterprise: disabled	cluster data

For the most secure types of communications, best practice is to use your own certificates. You can either obtain them from a third party or generate them yourself.

Next steps

Now that you understand the basics of TLS and how it can secure your Splunk Enterprise deployment, see the following decision tree for next steps.

If you use a Splunk Cloud Platform instance, do not manage Splunk Enterprise infrastructure, and need only to connect Splunk universal or heavy forwarders to your Splunk Cloud Platform instance, see the following topic to connect your forwarders to Splunk Cloud Platform:

• Install and configure the Splunk Cloud Platform universal forwarder credentials package in the Universal Forwarder Manual.

If you know how TLS works, have already obtained certificates, and just need to know how to configure them to use with the Splunk platform, see the following topic:

• How to prepare TLS certificates for use with the Splunk platform

Otherwise, continue for an overview of how to secure your deployment with TLS and the procedures to obtain TLS certificates:

• Steps to secure the Splunk platform with TLS