Other versions

Tanium actions overview

In a Tanium™ deployment, a package comprises a command, a script, and any related files required to execute an action on a managed endpoint. For example, the package named Clean Stale Tanium Client Data includes a Windows command-line command that executes a Visual Basic Script that removes stale data from the Tanium™ Client directory and safely kills any stale sensor or action processes.

Action deployment

You can deploy a package to Tanium Client host computers from the Interact Question Results grid by initiating the Deploy Action workflow. The Tanium Server then distributes the package files to endpoints through the linear chains of peers. The endpoints store all package files for an action in a folder named Action_XXXX, where XXXX is the action ID. When the action runs, it generates status indicators that you can monitor from the Tanium Console and generates client-side logs that you can use to troubleshoot failures.

Action terms

Action group

Action groups are designed to target actions so that they are issued to only appropriate computer groups. For example, you can create a computer group for Windows computers and then an action group that targets that computer group. When you configure scheduled actions to deploy packages that use Windows commands, you can specify the action to be issued only to the action group for Windows commands.

Action lock

Action locks are designed to suspend actions on the endpoint. You can deploy action locks if you encounter unexpected behavior and want to turn off actions while you debug it.

Action approval

Action approval supports organizations that have policies requiring an approval stage. When action approval is enabled, the logged in user that deploys the scheduled action cannot also approve it. The action is put on hold until it is approved by another user that has been assigned the Approve Action permission. Once approved, the approval remains in force until the schedule ends or the scheduled action configuration is modified.

Scheduled action

Scheduled actions are actions that the Tanium Server reissues periodically. These actions are designed to promote hygiene. For example, after you import the Client Maintenance content pack, the Tanium Server reissues the Clean Stale Tanium Client Data action every four hours.

Policy action

Policy actions are scheduled actions that you use to enforce policies on endpoints. For example, your enterprise policy might require a specific Tanium™ solution module on all endpoints. Each policy action is based on a saved question. At each scheduled action interval, the Tanium Server determines which endpoints match the current results of the question. If any endpoints match, the Tanium Server deploys the action to all endpoints but only the matching endpoints try to perform the action.

For example, say you configure an action that installs Tanium™ Trace only on endpoints that match the question Get Tanium Trace Status equals needs installation from all machines with Tanium Trace Status equals needs installation. When first deploying this action, the Tanium Server installs the module on a potentially large number of endpoints that do not have Tanium Trace installed. However, few if any endpoints will match that condition in subsequent scheduled deployments (perhaps only endpoints added after the first action deployment). If no endpoints match, the action does not deploy, which conserves bandwidth and avoids clutter in the Actions > Action History grid. By contrast, non-policy actions (based on dynamic questions) deploy even when no endpoints match. Furthermore, all the endpoints in the action group will attempt to perform a non-policy action even if, having run previously, the action is unnecessary and therefore never finishes.

Note that the Tanium Server does not deploy policy actions to endpoints that were offline when it sent the saved questions and that then come online while the actions are in progress. The Tanium Server deploys only non-policy actions to endpoints that come online while the actions are in progress. Non-policy actions are also useful in cases where you want all endpoints in an action group to perform the action without filtering the endpoints based on particular conditions (such as whether a particular module is installed).

If you delete a saved question, the Tanium Server continues reissuing it for any policy actions that use the question, and the Administration > Question History grid continues displaying the question for the scheduled action intervals.

Role requirements

You can see the Tanium Actions pages if you have actions-related permissions. Your capabilities on the Tanium Action pages depend on your role-based permissions.

Table 1:   Reserved Roles and Actions

Reserved Role	Capability
Administrator	All capabilities and all permissions, except Bypass Action Approval.
Content Administrator	All capabilities, except cannot create or edit action groups. All permissions, except Bypass Action Approval.

You can create advanced roles with the following permissions. When you configure the roles, specify the content sets that include the associated packages.

Table 2:   Permissions for Actions (Action Approval disabled)

Permission	Capability
Read Action	Can view the Scheduled Action pages. Visibility of rows in the grid depends on the Read Action permission on the content set for the underlying package. Can re-download package files and copy grid rows to the clipboard.
Write Action	Can view the Scheduled Action pages. Users can see rows for actions they issued. Users can see rows for actions issued by others if they have Read Action permission on the content set for the underlying package. Can see and use the Deploy Action button on the results grid for dynamic questions and saved questions. Implies the Read Own Action, Read Package, and Show Preview permissions. To deploy an action, edit an action, or check action status, a user also needs Read Sensor and Read Saved Question on the Reserved content set. The Reserved content set includes content used to ask preview and polling questions.
Write Action for Saved Question	Can see the Scheduled Action pages, but the only rows are for the actions that the user has deployed. Can see and use the Deploy Action button on the results grid but only for saved questions that are configured with an associated package. The Read Package permission is not required for the associated package. If the saved question is not configured with an associated package, the Deploy Action button is not displayed. Tip: Use this permission instead of the Write Action permission to limit use by "action users" who use Tanium to execute standard operating procedures created by someone else.

The following advanced role permissions are relevant only when action approval is enabled.

Table 3:   Permissions for actions (action approval enabled)

Permission	Capability
Approve Action	View the All Pending Approval page. Visibility of rows in the grids depends on the Read Action permission on the content set for the underlying package. Must have Approve Action for the content set for the underlying package. Can approve actions created by another user but not their own.
Read Own Action	Determines whether the logged in user's actions appear in the All Pending Approval grid.
Bypass Action Approval	Actions created by a user with this permission are not subject to approval requirements. Does not apply retroactively.

Last updated: 10/22/2018 2:37 PM | Feedback