Other resources

Release Notes

Support Knowledge Base
(login required)

Overview

This guide describes how to deploy the TaniumĀ® Client to enterprise endpoints.

What is the Tanium Client?

The Tanium Client is a service installed on endpoint computers. In response to your Questions, it discovers and reports within seconds both static and dynamic real-time data pertaining to the endpoint, including:

  • Hardware and software inventory
  • Software configuration
  • Local or domain user details
  • Installed application or services, startup programs, and running processes
  • Existence of registry keys and their values
  • WMI data elements
  • File system details, including identification of files by hash or contents
  • Event Log results
  • Network configuration settings and state

With similar speed, the Tanium Client can be used to execute commands, actions, scripts, or other executable programs just as if an authorized administrator were taking actions from the command line on the target device. For example, you can send the Tanium Client an instruction to take the following actions:

  • Install or uninstall applications or services
  • Update or patch installed applications, services, hardware drivers, or firmware
  • Manage installed applications or services
  • Add, remove, or modify the Windows Registry settings or other configuration stores
  • Add, remove, or modify files or the contents of files
  • Start or stop services

These powerful features enable large, geographically distributed organizations to identify and respond to a zero-day exploit, security breach, or application outage in a matter of seconds or minutes rather than days and weeks.

Registration

When the Tanium Client software is first deployed to an endpoint, it initiates a direct connection to the Tanium Server assigned to it in the initial configuration. During initial registration, the Tanium Client establishes a unique ID and receives from the Tanium Server the latest client settings, a list of nearby peers, and the latest Sensor, Question, and Scheduled Action definitions. By default, the initial registration status is configured to reset approximately every four hours, forcing the Tanium Client to re-initialize registration. This ensures the latest settings are applied and that optimal peers are selected.

The Tanium Client also re-registers with the Tanium Server via a normal registration that happens at a defined registration interval. The default registration interval is a randomized time between 30 and 90 seconds. During a normal registration, the Tanium Client informs the Tanium Server of its current state of Questions, Actions, and settings; and, in response, the Tanium Server sends new Questions, Actions, or settings to apply. In large environments, normal registrations are the primary way that new Questions, Actions, and settings get communicated to Tanium Clients.

Client peering

In an enterprise network, the Tanium Clients establish peering relationships. Peer connections are continual, long-lived connections used to exchange Tanium messages and files. Information and data are forwarded along linear chains of peers. During registration, the Tanium Client receives a "peer list" of other Tanium Clients to which it may attempt to establish a peer connection. The Tanium Client uses the list to determine which neighbors are the most optimal network peers.

Figure  1:  Types of peers

By default, the linear chains form into groups of 100. These groups are known as neighborhoods. By design, each neighborhood has one forward leader and one backward leader at the ends of the chain. Other than at registration, only leaders establish direct connections with the Tanium Server. The Tanium Server passes Sensors, Questions, and Scheduled Actions to the backward leader, who passes them to its forward peer, who in turn passes them to its forward peer, and so on, until it reaches the forward leader. The forward leader sends the answer to the Question or status of the Scheduled Action to the Tanium Server.

Figure  2:  Tanium Client neighborhood

Tanium peer communication is designed to accommodate new clients that come online, to route around clients that are removed or are unable to communicate effectively, and to "reflect" around network-level blockages, such as firewall blocking. If a Tanium Client cannot establish an outgoing connection to a forward peer in its list, it establishes its forward connection to the Tanium Server and becomes a forward leader. This is called forward reflection. Likewise, if a Tanium Client cannot establish an outgoing connection to a backward peer, it establishes a backward connection to the Tanium Server and becomes a backward leader. This is called backward reflection.

Client peering results in a profound reduction in connections and bandwidth over WAN links. The following figure illustrates the proportions of the savings. A large enterprise network includes subnets in headquarters and branch offices, as well as VPN connections from remote workers. Other than during registration, only the remote VPN clients and leaders, depicted in sharp red, connect to the Tanium Server over WAN links. The remaining clients, depicted in faded red, share data over peer connections on the LAN.

Figure  3:  An enterprise network

File distribution

There are two key optimizations that Tanium utilizes to distribute files efficiently:

  • Tanium Client peering

    Reduces the number of files that must be distributed over WAN links. Instead of sending files to all managed endpoints, the Tanium Server sends files only to a small fraction of them (that is, only to endpoints designated as forward leaders). The leader then distributes the file over a high-speed LAN connection to its forward peer and so on throughout the linear chain.

  • Tanium Client caching

    Enables files to be distributed in small chunks known as shards. Each client maintains an intelligent local cache of the shard files that have been distributed. The result is that when the same files are requested later, they can be reassembled from their peers over the LAN, rather than requesting that the server redistribute the file again. By default, each client maintains a cache of 100 MB of shards of files that have been distributed to the peer group. Each client keeps particular shards based on an algorithm to ensure that a valuable distribution is maintained. These caches are also self-cleaning based on an algorithm that prioritizes recently used shards.

When you want to distribute a file, such as a Windows patch or application, the file is first downloaded to the Tanium Server. The Tanium Server then breaks the file into many shard files. Each of these shards is associated with a hash value. The Tanium Server then creates a manifest that maps all of the component shards to the entire file. When you use the Tanium Server to distribute a Package that includes a file, the manifest for that file is contained in the Package.

Figure  4:  Tanium shard files

When a Tanium Client receives the Package and associated manifest file, it first checks its own cache to see if it already has any of the shards listed in the manifest. The Tanium Client then generates a new request message for all of the shards that it was unable to find locally. This request message first flows forward along the linear chain to the end of its local neighborhood. As the request message traverses the chain, each peer checks its local cache for the shards listed. If the peer has one of the requested shards, it sends the shard to the requesting peer. To avoid duplication, it also removes that particular entry from the request message before propagating the message to the next peer in the chain. If all of the shards are not found after the forward flow along the chain, the Tanium Client sends a request for shards that traverses the chain in the reverse direction. If there are still missing shards after each peer has investigated its cache, the first Tanium Client requests the missing shards directly from the Tanium Server and distributes them appropriately.

Last updated: 8/15/2017 12:41 PM | Feedback