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.
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_<ID>, where <ID> is the action identifier. 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 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 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 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 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 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.
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.
|Administrator||All capabilities and all permissions, except Bypass Action Approval.|
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.
|Read Action||Can view the Scheduled Actions 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 Actions 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
Can see and use the Deploy Action button on the Question 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 Actions pages, but the only rows are for the actions that the user has deployed.
Can see and use the Deploy Action button on the Question 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.
|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: 2/6/2019 2:40 PM | Feedback