5.4 Interpreting Module-Specific Historical Results and Tanium Data Service
Key Takeaways
- Live question results, Recent results retained by the server for seven days, and module historical results measure different populations at different times and must not be compared casually.
- Module data is collected on each solution's own schedule, and Tanium Reporting runs a 24-hour collection cycle for report data while module source push intervals vary by solution.
- An endpoint that was offline throughout a collection window is absent from historical data rather than compliant, so failed and never assessed must be distinguished.
- Tanium Data Service stores results for registered sensors so questions can represent endpoints that are offline at the moment the question is issued.
- A sudden step change in a historical chart is far more often a scope or measurement change than a real-world event, so the denominator should be checked first.
5.4 Interpreting Module-Specific Historical Results and Tanium Data Service
Quick overview: Blueprint objective NAV-2 asks you to interpret module-specific historical results. The skill being tested is not chart-reading — it is knowing what a historical number actually means, which depends entirely on where the data came from, when it was collected, and which endpoints could have contributed to it. Get that wrong and you will confidently report a compliance percentage that is measuring something other than what you think.
1. Three different kinds of "result" in Tanium
| Kind | Where it comes from | What it represents |
|---|---|---|
| Live question result | Sensors executed now, on endpoints online now | Ground truth for the endpoints that answered |
| Recent result | A previous issue of a reissuing saved question, retained by the server for seven days by default | The last known answer from an endpoint that is offline now |
| Module historical result | A module's own stored data, collected on the module's own cadence | What that module observed, at its collection times |
An operator who treats all three as interchangeable produces confidently wrong reports. The most common error: comparing a live question count against a module's historical count and concluding something changed, when in fact the two numbers were never measuring the same population at the same moment.
2. The three questions to ask of any historical number
Before you quote a module figure to anyone, answer these:
- When was it collected? Module data is collected on the module's schedule, not when you opened the page. Tanium Reporting, for example, runs a 24-hour collection cycle for report data, and the intervals at which solutions push module source data vary by solution.
- Which endpoints could have contributed? Historical data reflects endpoints that were reachable and in scope at collection time. An endpoint that was offline for the whole window is absent, not compliant.
- What is the denominator? "94% compliant" is meaningless without knowing whether the missing 6% failed, or were simply never assessed.
[!IMPORTANT] The distinction between failed and never assessed is the single most consequential misreading in this domain. Both show up as "not green". Only one of them is a security finding; the other is a coverage gap, and it is usually the more serious of the two.
3. Reading a trend rather than a number
A single historical figure is nearly always less useful than its direction.
| What you see | What it usually means |
|---|---|
| Count falling steadily after a deployment | Remediation is working; endpoints are picking up the change as they come online |
| Count falling then flattening above zero | A residual population is failing for a different reason — investigate the remainder specifically |
| Count rising between cycles | Drift is outpacing remediation; consider a policy approach (Enforce) rather than repeated remediation |
| A sudden step change | Almost always a scope change — a group definition edited, a module source added, endpoints onboarded — not a real-world event |
| Total population changing | Your denominator moved; the percentage is not comparable across the step |
That fourth row is worth internalising. When a chart jumps overnight, suspect the measurement before you suspect the world.
Core Architectural Principle: Tanium Interact provides unrivaled agility by executing sensors dynamically in endpoint RAM to return live, zero-second ground truth across online endpoints. However, if a traveling executive's laptop is closed, a field workstation is powered off, or a remote branch office loses network connectivity, a live Interact query cannot retrieve its state. Tanium Data Service (TDS) overcomes this physical limitation by continuously harvesting sensor data in the background, indexing the telemetry in a centralized high-performance database on the Tanium Module Server, and delivering instantaneous historical visibility across 100% of the enterprise fleet.
TDS functions as the unified telemetry engine underpinning modern Tanium solutions, including Tanium Reporting, Tanium Asset, and Tanium Trends. For the TCO certification, operators must understand the structural differences between live and harvested data, master the sensor registration lifecycle, and apply rigorous database hygiene rules.
The Dual-Engine Architecture: Live Interact vs. Tanium Data Service
The Tanium platform operates a dual-engine telemetry architecture designed to satisfy two fundamentally distinct enterprise operational requirements:
┌─────────────────────────────────────────────────────────────────────────────┐
│ TANIUM DUAL-ENGINE TELEMETRY MODEL │
├──────────────────────────────────────┬──────────────────────────────────────┤
│ ENGINE 1: LIVE INTERACT (RAM) │ ENGINE 2: DATA SERVICE / TDS (DISK) │
├──────────────────────────────────────┼──────────────────────────────────────┤
│ • Executes dynamically in client RAM │ • Pre-harvested & centrally indexed │
│ • Returns live ground truth in ~15s │ • Sub-second response from database │
│ • Targets ONLY online endpoints │ • Visibility into ONLINE + OFFLINE │
│ • Zero database storage footprint │ • Continuous Module Server indexing │
│ • Use Case: Live Incident Response, │ • Use Case: Executive Compliance, │
│ Zero-Day Hunting, Package Checks │ Hardware/Software Audits, CMDB │
└──────────────────────────────────────┴──────────────────────────────────────┘
Technical Comparison Matrix
| Architectural Attribute | Live Interact Questioning | Tanium Data Service (TDS) Telemetry |
|---|---|---|
| Execution Location | Dynamic execution in endpoint RAM across linear chains | Pre-computed and stored in Module Server database |
| Data Freshness | Zero-second live ground truth ($t = 0$) | Last harvested snapshot ($t = \text{last harvest timestamp}$) |
| Offline Asset Visibility | None (Offline systems do not respond) | Complete (Retains last-known-good state + Harvest Date) |
| Query Response Time | 15 to 45 seconds (network linear chain transit) | Milliseconds / Sub-second (database index lookup) |
| Network Overhead | Generates lightweight linear chain query packets | Zero query traffic; endpoints only polled during background harvests |
| Primary Solutions | Interact Workspace, Live Action Targeting | Tanium Reporting, Trends, Tanium Asset |
| Operator Persona | SOC Incident Responder, Live Threat Hunter | IT Asset Manager, Compliance Auditor, CISO Analyst |
Architectural Mechanics of TDS on the Module Server
TDS is deployed as a core microservice hosted on the dedicated Tanium Module Server. By decoupling background data harvesting and heavy database indexing from the primary Tanium Server, the platform ensures that core live query processing and cryptographic action signing remain completely unburdened.
[Tanium Endpoint Fleet: 100,000 Systems]
│
│ (1. Background Harvest Polling based on Sensor Schedule)
▼
[TDS Harvesting Engine (Module Server)]
│
│ (2. Ingests, Deduplicates, Interns Strings & Normalizes Rows)
▼
[TDS Centralized Telemetry Database / Index]
│ (Contains: Endpoint ID + Sensor Column Values + Harvest Timestamp)
│
├───► [Tanium Reporting] (Instant Custom Multi-Sensor Reports)
├───► [Tanium Asset] (Hardware / Software CMDB Feeds)
└───► [Tanium Trends] (Longitudinal Posture Tracking)
Ingestion, Deduplication & Indexing Mechanics
- Background Polling: TDS maintains an internal harvest scheduler. At configured intervals, TDS issues background requests across endpoint linear chains targeting specific registered sensors.
- Deduplication & String Interning: When endpoints return strings (e.g.,
Microsoft Windows 11 Enterprise), TDS performs string interning, storing the string once in a master dictionary table and mapping thousands of unique Endpoint IDs to that single string index pointer. This provides massive storage compression. - Temporal Tracking: Every indexed record is tagged with an
Endpoint IDand aHarvest Datetimestamp. When an endpoint goes offline, its existing records remain in the database, tagged with the timestamp of its last successful harvest.
Registered vs. Unregistered Sensors
A critical concept tested on the TCO exam is the distinction between registered and unregistered sensors:
- Unregistered Sensors (Default State): By default, the vast majority of sensors in Tanium content sets are unregistered. Unregistered sensors can be queried on demand at any time in the Interact workspace, but their results are never saved to the TDS database. If an endpoint is offline when an unregistered sensor is queried, it will not appear in the results.
- Registered Sensors: When an administrator or authorized Content Author explicitly registers a sensor in TDS, the harvesting engine begins background collection. The sensor becomes immediately available for sub-second querying within Tanium Reporting, Tanium Asset, and Tanium Trends, providing continuous visibility across both online and offline endpoints.
Step-by-Step Sensor Registration Workflow
Registering a sensor in TDS requires deliberate operational planning to balance visibility against platform resource consumption. The registration interface requires five configuration parameters:
SENSOR REGISTRATION CONFIGURATION WORKFLOW
[1. Select Sensor] ──────► [2. Filter Columns] ──────► [3. Harvest Interval]
Installed Apps Name, Version, Vendor Every 12 Hours
│
▼
[6. TDS Index Active] ◄─── [5. Normalization] ◄────── [4. Target Group]
Sub-Second Querying Ignore Case Enabled All Windows Workstations
Detailed Configuration Parameters
| Setting | Technical Purpose | Recommended Operational Configuration |
|---|---|---|
| Sensor Name | Specifies which platform sensor to register in TDS. | Select standardized, vetted sensors (e.g., Installed Applications, BIOS Details, Network IP Details). |
| Columns to Harvest | For multi-column sensors, allows operators to harvest only specific columns rather than the entire schema. | Column Filtering: Harvest only operational columns (e.g., index Name and Version, but omit raw unparsed registry keys) to save storage. |
| Harvest Interval | Defines the background polling frequency for the sensor. | Match Data Volatility: Static data (e.g., CPU Details, Total Physical Memory) = 24 Hours. Semi-dynamic data (e.g., Installed Applications) = 12 Hours. Dynamic data (e.g., Logged in Users) = 1–2 Hours. |
| Target Computer Group | Restricts background harvesting to a specific subset of the fleet. | OS Scoping: Scope Windows-specific sensors to All Windows Endpoints and Linux sensors to All Linux Endpoints to avoid execution errors and wasted cycles. |
| Ignore Case / Normalization | Merges case variations into a unified indexed entity (e.g., treating chrome.exe and CHROME.EXE as identical). | Enable for Strings: Enable on software names, file paths, and usernames to prevent duplicate database rows and fragmented reporting grids. |
Sensor Cardinality & Module Server Storage Hygiene
The most critical administrative trap evaluated on the TCO exam is High Cardinality Telemetry.
Understanding Low vs. High Cardinality
LOW CARDINALITY (Optimal for TDS)
Sensor: "Operating System"
50,000 Endpoints ───► [ 3 Unique Strings: Win 11, Win 10, RHEL 9 ] ───► ~3 Database Rows (Tiny Storage Footprint)
HIGH CARDINALITY (Disastrous for TDS)
Sensor: "Ephemeral Process GUID & Timestamp"
50,000 Endpoints ───► [ 50,000 Unique Strings per Harvest Cycle ] ───► Millions of Rows (Database Bloat / Crash!)
Telemetry Classification Matrix
| Cardinality Level | Definition & Behavior | Sensor Examples | TDS Registration Recommendation |
|---|---|---|---|
| Low Cardinality | Small, predictable set of values shared across thousands of endpoints. Highly compressible. | Operating System, Tanium Client Version, Chassis Type, Domain Role, CPU Architecture | Recommended: Excellent candidate for TDS; minimal storage footprint, instantaneous indexing. |
| Moderate Cardinality | Moderate set of values with predictable distribution across machines. | Installed Applications, Network Subnet Mask, Primary User Department, Service Pack | Recommended with Care: Set harvest intervals to 12–24 hours; filter unnecessary columns. |
| High Cardinality | Near-infinite entropy; generates unique strings for every endpoint on every harvest execution. | Current Timestamp, Ephemeral TCP Source Ports, Free Memory (Exact Bytes), Dynamic Session Tokens | STRICTLY PROHIBITED: Never register in TDS. Causes database table explosion, disk exhaustion, and UI latency. |
Exam Warning & Golden Rule: If a sensor returns a value that is guaranteed to be unique per machine or changes continuously every second (such as high-entropy GUIDs or timestamps), query it exclusively in Live Interact. Never register high-cardinality sensors in TDS.
Monitoring TDS Health & Operational Status Indicators
Tanium provides dedicated health indicators in the Administration workspace to monitor background harvesting operations:
| Status Indicator | Operational Meaning | Recommended Operator Action |
|---|---|---|
| Collecting / Harvesting | TDS is actively dispatching query packets and ingesting endpoint response batches. | Normal operation; background harvesting is executing as scheduled. |
| Idle | Harvesting cycle is complete; database is up to date; waiting for next scheduled interval. | Normal operation; reports reflect fresh telemetry. |
| Paused / Suspended | Background harvesting has been manually halted by an administrator. | Verify maintenance windows; re-enable harvesting once maintenance concludes. |
| Error / Harvest Failure | Harvesting encountered a timeout, sensor execution crash, or database write failure. | Check Module Server disk capacity, verify sensor script syntax, and inspect system log files. |
| Overdue / Backlog | A batch of endpoints failed to report within their expected harvest window. | Investigate endpoint network reachability, linear chain peer health, or high client CPU utilization. |
Fleet Harvest Coverage Metrics
The TDS interface provides a real-time Harvest Percentage metric. If TDS reports 96% Coverage for Installed Applications, an operator immediately knows that 4% of the fleet is currently powered off, in transit, or experiencing communication delays. When querying TDS in Tanium Reporting, the operator can sort by Harvest Date to inspect precisely when each machine last reported its telemetry.
What primary operational capability does the Tanium Data Service (TDS) provide that distinguishes it from live Interact questioning?
Why is registering high-cardinality sensors—such as dynamic process GUIDs, ephemeral network ports, or millisecond timestamps—strongly discouraged in Tanium Data Service (TDS)?
In which of the following operational scenarios MUST an operator execute a live Interact question rather than relying on Tanium Data Service (TDS) or Tanium Reporting?
Which administrative action is mandatory before an existing platform sensor's telemetry can be continuously harvested and queried in Tanium Reporting?