Module 2 — Lesson 6 of 8

Remote Remediation

Fix problems directly from Tanium Investigate — reboot machines, reset Windows Update, delete files, restart services, deploy packages, and even quarantine endpoints, all without leaving the console or interrupting the end user.
📚 Overview
🔧 Deep Dive
🛠 Hands-On
✅ Check

One of the most powerful aspects of Tanium Investigate is that you can move seamlessly from investigation to remediation without ever leaving the console. In traditional IT workflows, investigation and remediation are separate activities in separate tools -- each tool switch adds time, context loss, and friction. Tanium eliminates this gap with a single-pane investigate-fix-verify workflow.

The Investigate-Remediate-Verify Workflow

Identify Find root cause in SEV 1 Remediate One-click action 2 Verify Confirm fix worked 3 Document Audit trail + notes 4 Process hog? Stuck update? Full disk? Bad service? Kill, reboot, restart, delete, deploy, isolate Check metrics, re-query, monitor for recurrence Auto-logged audit trail + annotations in workspace

Built-In Remediation Actions

🔄
Reboot
Graceful or forced restart -- schedule for after-hours to minimize disruption
🔃
WU Reset
Reset stuck Windows Update components -- stops service, clears cache, restarts
🗑
File Deletion
Remove bloated logs, malicious files, or corrupted caches from the endpoint
⚙
Service Restart
Stop and restart hung or failed Windows services by name
⛔
Process Kill
Terminate runaway processes consuming excessive CPU or memory
🔒
Quarantine
Isolate endpoint from network while keeping Tanium channel open for investigation
Key Concept

This investigate-then-remediate workflow is transformative for MTTR. Instead of a 45-minute cycle of investigating in one tool, documenting, switching to another tool, re-authenticating, and finding the endpoint again -- you can go from identification to resolution in under 5 minutes, all within a single pane of glass.

Simulated: SEV Remediation Panel

SEV -- CAEI782014 (mgarcia, Claims) -- Remediation Actions
Overview
Processes
File System
Actions
Audit Log
31
Health Score
95%
Disk Usage
45 days
Uptime
3 Pending
Updates
ActionDescriptionRBAC LevelStatus
Reboot (Scheduled)Schedule graceful reboot for 6:00 PM todayStandardAvailable
Windows Update ResetReset WU components, clear SoftwareDistributionStandardAvailable
Disk Cleanup PackageClear temp files, browser cache, WU cacheAdvancedAvailable
Endpoint IsolationNetwork quarantine (Tanium channel preserved)SecurityRestricted
LAST ACTION -- S. Cabrera, 3:22 PM
Deployed "Disk Cleanup - Standard" package. Result: Success. Freed 12.4 GB. Disk usage reduced from 95% to 72%. Scheduled reboot for 6:00 PM to apply pending updates and clear memory leaks.

Built-In Actions: Details

Custom Tanium Package Deployment

When built-in actions are not sufficient, deploy custom Tanium packages directly from within Investigate. A package is a pre-built bundle containing scripts, binaries, or config files with execution instructions.

Define

Document what issue the package resolves and what conditions indicate the problem.

Script

Write a PowerShell or Bash script. Keep it idempotent -- running twice should not cause harm. Include error handling.

Package

Create the Tanium package: upload script, define parameters, set timeout, specify exit codes.

Pilot

Deploy to a single test machine first. Verify execution, check for side effects, confirm reporting.

Deploy

Deploy from SEV or Direct Connect during investigation. Monitor execution result in real time.

Pro Tip

Well-designed packages become your team's remediation library -- a growing collection of tested, documented fixes that any authorized team member can deploy consistently. Over time, this library dramatically reduces resolution time for recurring issues.

Containment Actions

ActionWhat It DoesWhen to UseImpact
Endpoint Isolation Blocks all network traffic except Tanium client-to-server communication Suspected malware, data exfiltration, active security incident High -- user loses all network access
Application Control Blocks specific executables from running via AppLocker policies Malicious or unauthorized application identified during investigation Medium -- only targeted app blocked
Firewall Modification Add/modify Windows Firewall rules to block specific ports, IPs, or apps Targeted containment when full isolation is too disruptive Low-Medium -- surgical network control

RBAC Controls: Who Can Do What

RolePermissionsTypical Assignment
Read-Only View all investigation data, no remediation actions Junior analysts, auditors
Standard Remediation Service restarts, process kills, scheduled reboots Experienced help desk engineers
Advanced Remediation Custom packages, file deletion, system config changes Senior engineers, escalation teams
Containment Isolation, quarantine, firewall changes Security operations, incident response

RBAC policies are enforced at the server level. Even if someone finds the URL or API call for a restricted action, the server rejects the request if the user's role does not permit it.

Verifying Remediation

Check Metrics

After killing a runaway process, watch CPU utilization drop in real time within seconds.

Refresh Data

After deploying disk cleanup, refresh the disk utilization view to confirm free space increased.

Re-Query

Re-run the original investigation query to confirm the problem condition no longer matches.

Check Services

After restarting a service, verify it is running and in the expected state.

Monitor

For intermittent issues, check back in 30-60 minutes to confirm the problem has not returned.

Audit Logging

Every remediation action -- built-in or custom -- is automatically logged. The log captures: the operator, target endpoint(s), specific action taken, parameters used, result (success/failure/timeout), and timestamp. This logging is non-optional and non-configurable.

Common Mistake

Never deploy remediation actions to your full production fleet without testing on a pilot group first. Even a well-intentioned script can have unintended consequences: a disk cleanup that deletes application data, a registry fix that breaks another app, or a service restart that causes a cascade failure. Always test on 5-10 representative endpoints, verify results, then expand. The 15 minutes you spend on a pilot test can save hours of recovery work.

Match the Remediation Action to Its Use Case

For each scenario below, select the most appropriate remediation action:

A. A user's laptop has 98% disk usage due to a massive CBS.log file in the Windows temp directory.

Correct! A massive CBS.log filling the disk is a cleanup issue. Use file deletion to remove the bloated log file or deploy a disk cleanup package to clear temp files and free space immediately.
Not quite. A massive log file consuming disk space is best resolved with targeted file deletion or a disk cleanup package -- not a reboot, network isolation, or update reset.

B. Windows Update has been stuck at "Checking for updates" for 3 hours and is consuming 40% CPU via svchost.exe (wuauserv).

Correct! A stuck Windows Update process is best resolved by resetting the Windows Update components: stopping the service, clearing the SoftwareDistribution folder, and restarting. This is exactly what the Windows Update Reset action does.
Not quite. A stuck Windows Update is specifically addressed by the WU Reset action -- it stops the service, clears the cache, and restarts cleanly.

C. Security flags an endpoint running a suspicious executable that is making outbound connections to an unknown IP address.

Correct! A suspicious process making outbound connections to an unknown IP is a potential security incident. The immediate priority is containment: isolate the endpoint from the network to prevent data exfiltration or lateral movement, while keeping the Tanium channel open for continued investigation.
Not quite. When a suspicious process is actively communicating with an unknown IP, containment (network isolation) is the priority -- stop the communication while preserving your ability to investigate remotely.

D. An endpoint has been running for 45 days without a reboot and has accumulated memory leaks, pending updates, and a degraded health score of 35.

Correct! An endpoint with 45 days of uptime, memory leaks, and pending updates needs a reboot. Schedule it for after business hours so the user is not interrupted, and the reboot will clear memory leaks, apply pending updates, and restore the machine to a healthy state.
Not quite. With 45 days uptime, accumulated memory leaks, and pending updates, a scheduled reboot (after-hours to avoid disruption) is the right fix -- it clears everything and restores health.

Scenario: What Would You Do?

Escalation from Help Desk

Ticket: INC0093182
Reported by: Help desk L1, escalated to your team
Subject: "Endpoint CAEI782014 -- user says Outlook freezes every 10 minutes. L1 tried reboot, didn't help."
Your investigation: You open the SEV and see that SearchIndexer.exe is consuming 100% of one CPU core and doing heavy disk I/O. The C: drive is at 94% capacity. The endpoint has been up for 38 days.

What is your recommended remediation plan?

Correct! This is a multi-step remediation: (1) Kill the immediate resource hog (SearchIndexer), (2) free disk space with a cleanup package so SearchIndexer does not choke again, (3) schedule a reboot to clear 38 days of accumulated issues. Each step addresses a different aspect of the problem, and you can do all of it from the Investigate console without involving the user.
Not quite. The best approach addresses all three issues: kill the immediate resource hog, free disk space so it does not recur, and schedule a reboot for the accumulated 38-day uptime issues. All from within Investigate.

✍ Knowledge Check

1. What is the primary advantage of remediating directly from within Tanium Investigate instead of switching to a separate tool?

Correct! The seamless investigate-to-remediate workflow eliminates tool switching, preserves investigation context, and dramatically reduces the time from problem identification to resolution. RBAC controls are still fully enforced within Investigate.
Not quite. The key advantage is eliminating context switching and reducing MTTR -- you go from finding a problem to fixing it in the same console, without re-authenticating or losing context. RBAC is still fully enforced.

2. When an endpoint is isolated/quarantined via Tanium, what happens to the Tanium client connection?

Correct! Tanium's quarantine feature blocks all network traffic except the Tanium client-to-server communication. This is essential for incident response: you can contain the threat while still collecting evidence and applying fixes remotely.
Not quite. Tanium quarantine blocks all network traffic EXCEPT the Tanium client-to-server connection. This lets you contain the threat while still investigating and remediating remotely.

3. Why should you always test remediation packages on a pilot group before deploying to the full fleet?

Correct! Even well-tested scripts can have unexpected side effects in production. A pilot test on 5-10 representative endpoints catches problems before they cascade across the fleet. The 15 minutes spent on pilot testing can prevent hours of recovery work.
Not quite. Pilot testing is a safety net -- it catches unintended consequences (data deletion, app breakage, cascade failures) before they affect your entire fleet. Always test on a small group first.
← Previous: Direct Connect Next: ServiceNow Integration →
Mercury Insurance — Digital Workplace Team
DEX Specialization Training © 2026