One of Tanium’s most powerful features is the ability to change the state of endpoints across your enterprise. In Tanium, changes are made using Packages, for example, there is a Package to reboot Windows endpoints called “Reboot Windows Machine.” The “Reboot Windows Machine” Package becomes an Action once it is Deployed to Windows endpoints. Here the change is made by Tanium executing the Action on selected Windows endpoints and they are rebooted.
Since Packages contain scripts and content that are specific to each operating system (e.g. Windows, Mac OSX, Linux, etc.), proper targeting of a Package for Deployment is critical to achieve the desired result. Actions can be deployed ad hoc or on a schedule. When Actions are scheduled, they are optimized in Tanium when they are created using a Policy. This article will describe the steps required to create Tanium Policy Actions.
Tanium Policy Actions are a cleaner way to manage scheduled actions over Ad Hoc Actions where the reissue action checkbox is set. A simple example of using a Policy Action over an Ad Hoc Action is upgrading the Windows Tanium Clients across an enterprise. In this scenario, we need to identify the existing Tanium Clients version 6.0 and upgrade them to version 7.2. We will cover both methods and explain why the Policy Action method is preferred.
Ad Hoc Reissue Action Method (not preferred): We could certainly ask a question, “Get Tanium Client Version contains 6.0 from all machines with (Tanium Client Version contains 6.0 and Is Windows equals true)” (see Figure 1) and get all the currently online Windows endpoints running the 6.0.314.1540 client version. Since we’re only targeting Windows endpoints, we add the “Is Windows” sensor to the right side of the question. If we were targeting Mac OSX endpoints for a Tanium Client Upgrade we would add “Is Mac = true” or for Linux, “Is Linux = true”, etc.
Once the list of Windows endpoints running Tanium Client version 6.0 are enumerated, we can Deploy an Action to Update the Tanium clients to the latest version 7.2 and select the Reissue option setting it to every 4 hours for example. We want to reissue this Action since other Windows endpoints may be offline and have the Tanium Client 6.0 installed. The problem with this “Ad Hoc Reissue Action Method” is every four hours the Action will run again whether there are any endpoints with Tanium Client version 6.0 online or not. Depending on the size of the original Package which is now a reoccurring Action, this could cause unnecessary network traffic as well. Moreover, the running of this Action will also fill up the Action History Log each time it runs whether it executes or not on any endpoints.
Figure 1 – Asking the initial question
Figure 2 – Saving the targeted question
Figure 3 – Results of Saved Question and Deploying an Action
Figure 4 – Setting up the Update Tanium Client Action for every 4 hours and targeting the Windows Action Group
On the Deploy Action page, input the “Update Tanium Client 7.2.314.3211” package, click on the Reissue every checkbox and enter 4 hours. Select the All Windows Computer Action Group where the Action will reside. Preview and deploy the action (see Figure 4). The Policy Action to upgrade 6.0 clients to 7.2 is complete.
To verify the Policy Action is set up properly, go to Actions, Scheduled Actions, Action Group (All Windows Computers) in this case and add the column for Policy (see Figure 5).
Figure 5 – Add the Policy column to the Action Group
Summary: Once the Policy Action is set up (see Figure 6), it will asked the saved question every four hours, if no legacy Tanium Clients version 6.0 are online, the action will not run nor will it make a log entry in Action History. This is a best practice and can be used for any type of action in Tanium.