Tanium 6.x: Windows Patch Management Guide

Introduction

This document serves as a guideline for patch management using the Tanium Console. Although the infinite number of possible patch management workflows preclude the ability to cover them individually, the general functionality and techniques described below will enable you to develop effective strategies to complete your monthly patch cycle.

Distribution of Patch Tools

The Tanium Client assesses a host computer for required Microsoft patches leveraging technology built into Windows along with the Microsoft patch definition file wsusscn2.cab. The Tanium Server checks for the latest definition file on a regular, configurable interval and downloads the file automatically for distribution to the managed computers as needed. The Tanium Clients periodically evaluate the host computer for any missing Microsoft OS and application patches so that they can respond to any questions or dashboards with the patch status of each managed device.

For third party Managed Applications patching, such as patching for Adobe Reader and other commonly used software vulnerable to security issues, there is a similar mechanism in place. However, the primary difference is that Tanium creates and updates a data file which includes what the latest versions of third party software releases are, along with other data about the software. The Tanium Server downloads the Managed Applications .dat file from Tanium on a schedule, it’s distributed to all clients via the Ring Architecture on a schedule, clients scan for the versions of software found in the dat file, and the results are reported in a Tanium Dashboard.

All check and download frequencies are adjustable by Tanium operators with the appropriate permissions.

Client Tools Health

Some older versions of the Windows Update Agent will not work with Tanium’s scanning technology, though Tanium can update the version of the Windows Update Agent for machines running less than version 7.5 if you direct it to. See the Windows Update Agent Dashboard in the Patch Management Dashboard Group:

1500px-PatchManagementWUADashboardResults.png

Issues with Windows Patch Scanning and Managed Applications Patching (Adobe Reader, QuickTime, etc ...) are detected by Tanium Sensors. For details, see the Dashboard titled Client Tools Health. Issues which prevent successful scanning and reporting of results are described in this list:

PatchManagementClientToolsHealthResults.png
 

Scanning for Patches

By default, machines are scanned for their patch compliance every four hours on all machines, though the scan will start at a randomly chosen offset to reduce load on shared infrastructure. If a machine hasn't been scanned, for more than two days, that machine will be scanned shortly after coming back online.

Every hour a machine will check to see if the patch definitions file is out of date (older than 2 days) or if it’s not found at all. If the definitions file is not on the endpoint, the file will be sent to the endpoint and it will immediately scan. If the file was simply out of date, it will update it but not scan until the next interval.

The result is that scan results are a maximum of 2 days old, and a minimum of under an hour old. This process is fully automated.

The scan schedules are the same for Managed Applications and Microsoft Updates, and can be changed to suit the environments the Tanium Server helps manage.

Any machine, or any set of machines, can be scanned in an ad-hoc fashion by deploying the "Run Patch Scan" Package.

Action Groups

An Action is a Package (a command and, sometimes, source files) which is targeted to a set of computers and deployed. Action Groups are lists of Actions that can be targeted wherever they’re needed. Action Groups allow you to create sets of policies which can be reused where needed.

Using Action Groups as part of your patch management process provides a number of benefits:

  1. Most Patch deployments are repeated Scheduled Actions. In these cases, each patch you deploy will have a Scheduled Action and, over time, you may have thousands of Scheduled Actions in your default Action Group that you’d have to work with in a single list. Using Action Groups, these will go into virtual buckets that will only display the listed updates when you click on the right Action Group.
  2. More important, from a policy standpoint, Action Groups allow you to target different machines without recreating Scheduled Actions, and to do it with one mouse click. This winds up being incredibly useful for most organizations that have requirements to test their patches and scale out.

Creating an Action Group

  1. Logged in to the Tanium Console as an Administrator, navigate to ActionsScheduled Actions
  2. Click "Add New Action Group +". The "Create New Action Group" dialog appears:
Windows_Patch_Management_Guide_5_1.jpg
  1. Enter the Action Group Name: “Workstation Microsoft Patches - MM-YYYY”
  2. Do not select any groups under the Targeting list
  3. Press Save
Windows_Patch_Management_Guide_5_2.jpg

Identify Patches Needed

  1. Press the Home tab
  2. Click ‘Return to Dashboards’
  3. Within the Patch Management Dashboard Group, click on the "Windows OS Patch Management" Dashboard.
    Windows_Patch_Management_Guide_5_3.jpg 
  4. The "Required Windows Patches" Answer Grid within the Dashboard lists the missing patches reported by the Tanium agents:
    1500px-Required_Windows_Patches_Answer_GridInitialState.png

Deploying Patches to an Action Group

By default, the Answer Grid sorts the results first by the Count of applicable computers and then by the Names of the missing patches. As part of this example, it makes more sense to sort by Date and then Severity:

  1. Click the Date column header twice
  2. Press Ctrl+click on the Severity column header once
  3. Select patches from the list that you’d like to deploy. Be careful to select and deploy only updates that you are sure you want to deploy—for example, major browser revisions, service packs, or updates in which you’ve encountered problems during testing.
    1500px-Required_Windows_Patches_Answer_GridResortedState.png
  4. Press Deploy Package at the bottom of the dialog—the Deploy Action Wizard appears:
    BasicPatchAction-SelectPackage.png
     

Deploy Action: Target and Schedule

Use the following screenshots as a reference to complete the patch deployment process.

  1. To hit machines which are offline at the time of the patch deployment, the Action is typically scheduled and reissued to those machines that need them. Choose a reissuance time that you’re comfortable with.
  2. Target the selected patches to an Action group by selecting the group name from the drop down list.
  3. Press the Continue arrow of the Deploy Action Wizard.
    BasicPatchAction-TargetSchedule.png
     

 

Deploy Action: Finish

  1. Enter a useful Description to document the purpose of this action.
  2. Press Confirm to complete the Action Deployment configuration. A dialog appears for you to re-enter your console password. 
    BasicPatchAction-Finish.png
     

     

    Windows_Patch_Management_Guide_5_7.jpg
     
    Note: Feel free to close this popup box. It doesn’t need to stay open for processing to complete. You can open it later from the Action History tab.

If you have a lot of patches to deploy, simply keep selecting them (where you left off) and create new Scheduled Actions in the Action Group. For performance reasons, there is a limit of 1,000 items selected and deployed. If Deploy Package is grayed out, you’ve hit the limit. If you have more than 1,000 patches listed, you cannot choose ‘select all’.

If you do have catch-up to do, it might be easier to assign patches to Action Groups such as Workstations 2012, Workstations YYYY-1 and YYYY-2 to indicate first and second half of a year, and so on and so forth backwards through time. You will develop a system that works best for your organization.

After the selected relevant patches have been associated with an Action Group, you can designated which computer groups should apply the patches.

Send Updates in Action Groups to Targets

  1. Within the Tanium Console Navigate to Actions⇒Scheduled Actions
  2. Edit the respective Action Group
  3. Choose the Computer Group(s) that should receive them. Typically, you'll choose a pilot group first.
  4. Navigate to Actions⇒Scheduled Actions again and locate the previously created Action Group which we put all the patches in. It’s going to be a folder in the list of Action Groups at the top.
Windows_Patch_Management_Guide_5_8.jpg


In this example, in the next hour (which was our chosen reissue interval), when the Scheduled Action is reissued, those machines in the Patch Pilot group will get the patches. When you’re satisfied with how that went, send them to a wider group by visiting the Action Group again and selecting another list. Groups listed here are additive.

Patch Installation

When you deploy patches using Tanium, the patch files a machine requires will be copied into the C:\Program Files\Tanium\Tanium Client\Tools\Patch directory. These files wait in the directory until they are installed.

There’s another Scheduled Action which checks if there are any files in that directory and, if so, installs them. This job runs every 5 minutes on every endpoint. If there are no files, the check takes milliseconds. If there are patch files, installation time can vary wildly—small patches execute quickly while Service Packs may take hours to complete.

If you want to test things quickly by watching it work, find a machine that has patches in that directory. There’s a Sensor for this called ‘Queued Patches’ and another Sensor called ‘Number of Queued Patches’ that can help find these machines. Within a few minutes, the patches should start to install in the background. After the install is done, the patches are deleted out of the directory and the machine is scanned again for needed patches.

As patches are applied, you should be able to view each installing patch in the Patches Currently Installing via Tanium Action saved Question in the Windows OS Patch Management dashboard.

Conclusion

It’s worth noting again that this is the same process to use for 3rd party patch updates (in the Managed Application Upgrades dashboard in the same Dashboard Group). So you can go back and follow this guide to push updates for Adobe products, Firefox, Java, and others.

Have more questions? Submit a request