Managing Tanium keys

Tanium Cloud automatically manages the digital keys and certificates that secure connections among Tanium Core Platform components. The following sections provide an overview of the keys that are used for Transport Layer Security (TLS) communication among the components.

Tanium keys secure only Tanium traffic. Your enterprise public key infrastructure (PKI) governs the security of non-Tanium traffic among the endpoints in your network.

Tanium keys overview

TLS communication

TLS communication

The Tanium™ Protocol uses TLSTransport Layer Security (TLS) 1.2 to encrypt communication between Tanium Clients and Tanium Cloud (1) and between Tanium Clients within a linear chain (2) among the following platform components, as illustrated in Figure  1Figure  1:

1 Tanium Server to Tanium Server in an active-active deployment

For some communications between active-active servers, such as Tanium database traffic and Lightweight Directory Access Protocol (LDAP) synchronization traffic, Tanium Appliances use IPsec instead of the Tanium Protocol.
2 Tanium Servers to Zone Server Hub

Figure  1 shows the Zone Server Hub installed on a host that is separate from the Tanium Server hosts to illustrate that the connection is encrypted. However, in most Windows deployments and all Appliance deployments, you install the hub on the same host(s) as the Tanium Servers.
3 Zone Server Hub to Zone Server
4 Tanium Clients (external) to Zone Server
5 Tanium Clients (internal) to Tanium Servers
6 Tanium Client to Tanium Client (external and internal)

Only Tanium Client 7.4 or later uses TLS to encrypt peer traffic.
Figure  1:  Tanium Protocol communication
Figure  1:  Tanium Protocol communication

When you install or upgrade to Tanium Core Platform 7.4 or later, TLS is enabled by default for communication among platform components. For more details about TLS, and the steps to enable or disable it, see Tanium Core Platform Deployment Reference Guide: Setting up TLS communication.

Tanium keys secure only Tanium traffic. Your enterprise public key infrastructure (PKI) governs the security of non-Tanium traffic among the endpoints in your network.

In addition to Tanium Protocol communication, the Tanium Core Platform uses keys and certificates to secure other connections and operations:

You require the Administrator reserved role to manage Tanium keys.

To troubleshoot issues that relate to Tanium keys and certificates, see Troubleshoot certificate and key issues.

Tanium keys

At the top of the Tanium key infrastructure is a public-private root key pair that is required for all subordinate keys to secure connections among Tanium Core Platform components. Tanium rotates the root keys and subordinate keys at regular intervals.

Root keys

When you install the Tanium Server, it automatically generates a public-private root key pair. These root keys are at the top of the Tanium key infrastructure and are required for all subordinate keys to secure connections among Tanium Core Platform components. You deploy the root public key to the Zone Server, Zone Server Hub, and Tanium Clients during installation or upgrade so that these components can secure communication with the Tanium Server. In an active-active deployment, each Tanium Server has its own root key pair that it uses to secure communication with its peer.

The Tanium Server uses separate root key pairs for TLS communication with Tanium Clients based on their version. Initially after a fresh installation or upgrade, Tanium Client 7.4 or later uses the root public key that has the name <Tanium Server FQDN> Root 0 (see Figure  3). Each new root public key that you create for version 7.4 or later has a unique name in the format <Tanium Server FQDN> Root <#>. The root public key for Tanium Client 7.2 has the name legacy-root. You cannot create new keys for version 7.2.

To view details about the root keys, see View root key information.

Subordinate keys

Tanium Cloud The Tanium Server, Zone Server, Zone Server Hub, and Tanium Clients generate subordinate keys locally and request a digital signature for each key pair. Tanium CloudThe responding server uses a private key to generate the signatures and returns the associated public key along with the signatures to enable TLS communication among the requesting servers and clients. The Tanium Core Platform uses the following subordinate keys, as shown in Figure  2:

  • TLS keys: Tanium Cloud uses TLS keys to enable TLS communication among platform components, including between Tanium Clients. Each Tanium Core Platform server and Tanium Client uses TLS keys to enable TLS communication with other servers and clients. The Tanium ServerTanium Cloud uses the root private key to generate a signature for the TLS key pairsignatures for the server TLS keys (A1).
  • Message-signing keys: Tanium CloudThe Tanium Server uses this key pair to sign messages (such as for action packages) that it sends to Tanium Clients. Tanium CloudThe Tanium Server uses the root private key to generate a signature for the message-signing key pair (A1).
  • Intermediate TLS keys: Tanium Cloud uses an intermediate TLS private key to generate signatures for the TLS keys of Tanium Clients (2).Tanium Cloud returns the intermediate TLS public key along with the signatures to enable TLS for client communications.TheTanium Server uses an intermediate TLS private key to generate signatures for the TLS keys of internal Tanium Clients that report to that server (2). Each Zone Server also has an intermediate TLS private key to generate signatures for the TLS keys of external Tanium Clients that report to that server (3). The servers return the intermediate TLS public key along with the signatures to enable TLS for client communications. Using intermediate TLS keys instead of the root keys for generating signatures makes client registration faster and less CPU intensive. For security, you can rotate the intermediate keys independently of the root keys. Tanium CloudThe Tanium Server uses the root private key to generate a signature for the intermediate key pairs on the Tanium Server and Zone Server (A1).

In an active-active deployment, each Tanium Server has its own root key pair.

Figure  2:  Tanium keys (click image to enlarge)
A copy of the root public key resides in the Zone Server Hub installation directory regardless of whether the hub is installed on the same host as the Tanium Server (as shown in Figure  2) or on a dedicated host.

To enable communication among the Tanium Core Platform servers, you must also enable trust. For details, see Managing Tanium Server trust and Managing Zone Servers and hubs.

Key rotation

Although root keys never expire, you can rotate them, which means generating new keys and revoking the old keys. Rotating keys is useful if your organization has a policy for periodic key rotation or the security of the active keys is in doubt. If the security of the active root keys is in doubt, rotate them immediately.

If your organization does not have a key rotation policy, rotate the root keys at least once every year but no more than once every six months.

You cannot rotate the root keys for Tanium Client 7.2. The Tanium Console identifies the 7.2 root keys with the name legacy-root (see Figure  3).

Tanium Clients that are offline when you rotate keys acquire the new keys and resume regular operations upon coming online as long as those clients were initialized with the correct tanium-init.dat file. For details about tanium-init.dat, see Download infrastructure configuration files (keys).

To ensure the security of root private keys, the Tanium Console exposes only root public keys. However, when you generate or revoke a public key, the Tanium Server automatically generates and revokes the private key. Furthermore, when you rotate the root keys, the Tanium Core Platform automatically rotates all subordinate keys. Regardless of whether you rotate the root keys, the subordinate keys automatically rotate at configurable intervals.

The following steps summarize the workflow for rotating keys:

  1. (Optional best practice) On each Tanium Server, encrypt the pki.db file that contains the root keys, Tanium Server TLS keys, and message-signing keys. This is a one-time only task that you perform to prevent unauthorized access to the keys. See Encrypt the root keys database.
  2. If your organization has a key rotation policy, configure automatic rotation for subordinate keys to match the policy. This is a one-time only task, unless your policy changes. See Configure subordinate keys rotation.
  3. Generate a new root public key. The Tanium Server automatically generates a new corresponding private key and triggers the creation of new subordinate keys. See Generate root keys.

    As a best practice, wait one week before revoking the old root keys to ensure that the process of generating new keys finishes for all Tanium Core Platform components. When you revoke, any components that did not finish this process expend more processing resources and network traffic to generate new keys. However, if the security of the root keys is in doubt, revoke the old keys immediately after generating the new keys.

  4. Revoke the old root public key. The Tanium Server automatically revokes the associated private key and propagates the revocation directive for the old root keys and subordinate keys to all Tanium Core Platform components. For details, see Revoke root keys.
  5. (Best Practice) Back up the Tanium deployment immediately before and after revoking the root keys. If recovery becomes necessary, you must restore the deployment from the post-revocation backup. However, the pre-revocation backup might contain information that is useful for recovery planning. The backup steps depend on your Tanium infrastructure:

HSM integration

If you configure the Tanium Server to integrate with a hardware security module (HSM) for storing and managing keys, all key operations occur on the HSM even when you use the Tanium Console to initiate those operations. See Tanium Core Platform Deployment Reference Guide: Securing keys with an HSM.

View root key information

The Administration > Configuration > Key & Trust Management > Current Server page displays a tile for each root public key that is active. In an active-active deployment, the page displays the keys for both Tanium Servers, but only after you approve trust between them (see Managing Tanium Server trust). You can identify keys by their Fingerprint, which is the hash digest of the key, and by the server Name. The root public key that the Tanium Server uses for TLS communication with Tanium Client 7.2 has a Name of legacy-root. All the other keys are for TLS communication with Tanium Core Platform servers and with Tanium Client 7.4 or later.

Figure  3:  Tanium root public keys

You can also see details about root key operations, such as who generated or revoked a key and when:

  1. From the Main menu, go to Administration > Configuration > Key & Trust Management > Activity Log.
  2. Review the entries in the All Root Keys grid.
Figure  4:  Keys activity log
Keys actvity log

Encrypt the root keys database

As a best practice to prevent unauthorized access, specify a password to encrypt the root keys that the Tanium Server stores in the pki.db file.

The Tanium Console displays the values of most settings that you configure. However, for security, the Console does not display the encryption password.

Set the encryption password

Encrypt the root keys by adding the PKIDatabasePassword setting.

In an active-active deployment, perform the following steps on each Tanium Server.

  1. From the Main menu, go to Administration > Configuration > Settings > Advanced Settings and click Add Setting.
  2. For the Setting Type, select Local.
  3. For the Platform Setting Name, enter PKIDatabasePassword.
  4. Set the Value Type to Protected.
  5. Enter the password Value and click Save.

Store the password in a safe location.

Change the encryption password

After adding the PKIDatabasePassword setting, you can later change the password.

In an active-active deployment, perform the following steps on each Tanium Server.

  1. From the Main menu, go to Administration > Configuration > Settings > Advanced Settings.
  2. In the Name column, click PKIDatabasePassword.

    The Value field displays (protected) instead of the actual value.

  3. Enter a new Value and click Save.

Generate root keys

You can generate additional active public-private root key pairs for each Tanium Server. Perform this task on each Tanium Server in an active-active deployment.

  1. From the Main menu, go to Administration > Configuration > Key & Trust Management > Current Server.
  2. Click Create New Key. The page shows the root public key details in a new tile.

Revoke root keys

To prevent communication disruptions among Tanium Core Platform components, you cannot revoke a root key pair until you first generate a new key pair to replace it. Review the Key rotation workflow before revoking the old root key pair. You must revoke keys on both Tanium Servers in an active-active deployment.

Back up the Tanium deployment immediately before and after revoking the root keys. If recovery becomes necessary, you must restore the deployment from the post-revocation backup. However, the pre-revocation backup might contain information that is useful for recovery planning. The backup steps depend on your Tanium infrastructure:

If you configure the Tanium Server to integrate with an HSM, note that you cannot use a backup of the pki.db file containing the root keys to install a cryptographically identical duplicate of the server.

Revoke keys as follows:

  1. From the Main menu, go to Administration > Configuration > Key & Trust Management > Current Server.
  2. Click Revoke Key in the tile of the public key.

Download infrastructure configuration files (keys)

The Zone Server, Zone Server Hub, and Tanium Clients must authenticate the Tanium Server to enable communication with it. Version 7.4 of the servers and clients use keys (including the root public key) that are inside the initialization bundle (tanium-init.dat) to authenticate. Tanium Client 7.2 uses only the root public key (tanium.pub) to authenticate. Downloading the initialization file or public key file from the Tanium Server enables you to then deploy the file to the Tanium Clients, Zone Server, and Zone Server Hub.

Be careful not to allow the tanium-init.dat or tanium.pub file to be distributed or stored outside of your organization, such as in a publicly accessible source code repository or any other location accessible from the public internet. Limit the distribution to specific use in the deployment of Tanium Clients.

Though these files do this file does not contain private keys and cannot be used to provide control over a Tanium environment, a user with malicious intent could use them it to connect an unapproved client and use this unauthorized access to learn how your organization is using Tanium.

For version 7.4 or later of the servers and clients, tanium-init.dat is required for fresh installations. If you upgraded and plan to deploy more 7.2 clients, use tanium.pub. If you upgraded and plan to deploy new 7.4 clients, using tanium-init.dat is the best practice.

If you download tanium-init.dat through Tanium Client Management, certain settings (such as ServerNameList) are preconfigured in the file. See Tanium Client Management User Guide: Download the installation bundle or tanium-init.dat file for alternative deployment.

  1. (Active-active deployment only) Enable trust between the Tanium Servers in an active-active deployment if you haven't already. Upon establishing trust, the servers exchange the necessary keys so that the tanium-init.dat file on each server contains the public key of both servers. For details, see Managing Tanium Server trust.
  2. (Tanium Client 7.2 only) Enable the Tanium protocol that Tanium Client 7.2 uses to authenticate:
    1. From the Main menu, go to Administration > Configuration > Settings > Advanced Settings.
    2. In the Name columns, click enable_protocol_314_flag.
    3. Set the Value to 1 and click Save.
  3. From the Main menu, go to Administration > Configuration > Infrastructure.
  4. Click Download Download in the Clients v7.4+ and Zone Server or Clients v7.2 section, depending on which file you need.Infrastructure Configuration Files

    The file appears in the Downloads folder on the system that you use to access the Tanium Console.

To deploy tanium-init.dat or tanium.pub, see the relevant user guide:

Configure subordinate keys rotation

Tanium Core Platform components automatically generate new subordinate key pairs when it is time to rotate them. For example, Tanium Clients renew their TLS keys four hours (the renewal window) before the end of each seven-day validity period (expiration interval) by default. The renewal windows ensure components have enough time to re-establish trust in the Tanium environment before the current keys expire.

Configure the validity periods and renewal windows to match the policy of your organization. If your organization does not have a policy, use the default windows and validity periods.

You must configure the validity period of a key to exceed its renewal window by at least an hour. Otherwise, the Tanium Server automatically increases the validity period to one hour longer than the renewal window to ensure that the key does not rotate more than once per hour.

Perform the following steps for each type of subordinate key pair:

  1. From the Main menu, go to Administration > Configuration > Settings > Advanced Settings.
  2. Click the setting Name in the grid. See Table 1 for the list of names.
  3. Enter the appropriate validity period or renewal window Value and click Save.
 Table 1: Settings for key rotation
Setting Guidelines
pki_server_tls_key_duration_days The validity period for the key pair that the Tanium Server uses for TLS communication with another Tanium Server (in an active-active deployment), the Zone Server Hub, or Tanium Clients. The default is 60 days.
pki_server_tls_key_renewal_window_hours The renewal window for the key pair that the Tanium Server uses for TLS communication with another Tanium Server (in an active-active deployment), the Zone Server Hub, or Tanium Clients. The default is 4 hours.
pki_message_signing_key_duration_days The validity period for the key pair that the Tanium Server uses to sign messages (such as for action packages) that it sends to Tanium Clients. The default is 180 days.
pki_message_signing_key_renewal_window_hours The renewal window for the key pair that the Tanium Server uses to sign messages (such as for action packages) that it sends to Tanium Clients. The default is 4 hours.
pki_hub_tls_key_duration_days The validity period for the key pair that the Zone Server Hub uses for TLS communication with the Tanium Server and Zone Server. The default is 60 days.
pki_hub_tls_key_renewal_window_hours The renewal window for the key pair that the Zone Server Hub uses for TLS communication with the Tanium Server and Zone Server. The default is 4 hours.
pki_zoneserver_tls_key_duration_days The validity period for the key pair that the Zone Server uses for TLS communication with the Zone Server Hub and Tanium Clients. The default is 60 days.
pki_zoneserver_tls_key_renewal_window_hours The renewal window for the key pair that the Zone Server uses for TLS communication with the Zone Server Hub and Tanium Clients. The default is 4 hours.
pki_client_tls_ca_key_duration_days The validity period for the key pair that the Zone Server or Tanium Server uses to provide digital signatures for Tanium Clients when they generate new TLS key pairs. The default is 180 days.
pki_client_tls_ca_key_renewal_window_hours The renewal window for the key pair that the Zone Server or Tanium Server uses to provide digital signatures for Tanium Clients when they generate new TLS key pairs. The default is 168 hours (7 days).
pki_client_tls_key_duration_days The validity period for the key pairs that Tanium Clients use for TLS communication with each other and with the Zone Server or Tanium Server. The default is 7 days.
PKIClientTLSKeyRenewalWindowHours The renewal window for the key pairs that Tanium Clients use for TLS communication with each other and with the Zone Server or Tanium Server. The default is 4 hours.