2.1 Sensors: Execution Model, Output Structure and Data Types

2.1 Sensors: Execution Model, Output Structure and Data Types

Quick Summary: A Sensor is a lightweight, read-only script executed on-demand in local endpoint RAM by the Tanium Client. Sensors collect real-time endpoint state (such as running processes, registry values, or network connections) without writing persistent data to disk. All sensors must be cryptographically signed by the Tanium Server and verified by the Tanium Client before executing under privileged local accounts (LocalSystem on Windows, root on macOS/Linux). Understanding sensor execution mechanics, output column schemas, data types, and the two caching controls (Max Sensor Age and Maximum Data Age) is essential for blueprint objectives AQ-1 and AQ-2, which ask you to query endpoints for real-time information and use basic Tanium features to gather relevant information.

---

1. What is a Tanium Sensor?

In the Tanium architecture, a Sensor is the fundamental telemetry gathering unit. When an operator asks a question in the Tanium Console, the Tanium Server broadcasts the request down through the linear peer-to-peer chains. Upon receiving the question, each Tanium Client determines whether it needs to execute the underlying sensor code to answer the query.

+-----------------------------------------------------------------------------------+
|                             TANIUM SENSOR PARADIGM                                |
+-----------------------------------------------------------------------------------+
|  * Execution Location : Local Endpoint RAM (Volatile Memory)                      |
|  * Security Context   : LocalSystem (Windows) / root (macOS/Linux/Unix)           |
|  * Modification State : Strictly Read-Only (State Inspection Only)                |
|  * Delivery Mechanism : Cryptographically Signed Code Distributed via Linear Chain|
|  * Output Model       : Standard Output (stdout) Captured and Parsed into RAM     |
+-----------------------------------------------------------------------------------+

Key Architectural Characteristics

1. Local RAM Execution: Sensors execute entirely on the target endpoint. The Tanium Client invokes the appropriate scripting interpreter (such as PowerShell, VBScript, POSIX Shell, or Python), captures the script's standard output (stdout), and buffers the result in memory. No temporary files or database writes are persisted to the endpoint storage during standard sensor execution.
2. Read-Only Philosophy: By strict design and security governance, sensors are strictly read-only. A sensor inspects, reads, queries, and reports system state—it does never modify system configurations, alter registry entries, delete files, or start/stop services. Modifying endpoint state is exclusively reserved for Packages and Actions.
3. Interpreter Support Across Platforms: Tanium provides cross-platform sensor support using native or embedded scripting engines:
   • Windows: PowerShell (.ps1), VBScript (.vbs), Command Shell (.bat/.cmd), and Tanium-native C/C++ engine primitives.
   • Linux / UNIX (RHEL, Ubuntu, AIX, Solaris, SUSE): POSIX Shell (sh/bash), Python, and compiled binary utilities.
   • macOS: POSIX Shell (zsh/bash), Python, and AppleScript/native binaries.

---

2. Sensor Execution Security & Cryptographic Signature Verification

Because sensors execute with the highest local privileges on an endpoint—LocalSystem (NT AUTHORITY\SYSTEM) on Windows and root (UID 0) on POSIX platforms—rigorous execution security controls are enforced at every layer of the Tanium platform.

The Cryptographic Trust Chain

Every sensor script authored or imported into the Tanium Console is digitally signed by the Tanium Server using an internal private key. The Tanium Client installation includes a corresponding public key file (tanium.pub) placed in the client directory during deployment.

[Tanium Server / Console]
       │
       │  1. Sensor Script Authored / Imported
       ▼
[Cryptographic Signing Engine] ──── Uses Private Key to generate digital signature
       │
       │  2. Signed Sensor Payload Broadcast over Linear Chain (Port 17472)
       ▼
[Tanium Client on Endpoint]
       │
       ├─► 3. Verifies Signature against local 'tanium.pub' public key
       │      ├── Signature Invalid / Tampered ──► REJECT Execution & Log Security Alert
       │      └── Signature Valid ───────────────► Proceed to Execution Step
       ▼
[Privileged Execution in RAM]
       │  (Runs as LocalSystem / root)
       ▼
[Standard Output Parsing & Response Token Generation]

Security Guardrails

• Signature Verification: When a client receives a sensor execution instruction, it validates the cryptographic signature against its local tanium.pub key before spawning any subprocess. If the signature is missing, invalid, or corrupted by in-flight tampering, execution is immediately halted, and an error is logged.
• Tamper-Resistant Content: Sensor scripts stored on the Tanium Server cannot be modified in transit by intermediary network devices or malicious proxy nodes. Every peer in the linear chain inspects the payload signature independently.
• Restricted Execution Context: The Tanium Client ensures sensor processes cannot be hijacked by lower-privileged interactive users logged into the operating system.

---

3. Core Built-In Sensors

Tanium ships with hundreds of pre-built, out-of-the-box sensors maintained in standard content sets (such as Default Content, Core Content, and Initial Content). The table below outlines the core built-in sensors tested on the TCO exam:

---

4. Single-Column vs. Multi-Column Sensor Outputs

Sensors are categorized by the structural format of the data they return to the Tanium Client and Server.

+---------------------------------------------------------------------------------------+
|                               SENSOR OUTPUT STRUCTURES                                |
+---------------------------------------------------------------------------------------+
|  SINGLE-COLUMN SENSOR                    |  MULTI-COLUMN SENSOR                       |
|  --------------------                    |  -------------------                       |
|  * Returns 1 data element per record     |  * Returns delimited composite records     |
|  * Direct scalar mapping                 |  * Parsed into discrete named table columns|
|  * Example: `Computer Name`              |  * Example: `Running Processes`            |
|    Output: "WIN-SRV-01"                  |    Output: "explorer.exe | 4120 | C:\..."    |
|                                          |                                            |
|  SINGLE-ROW OUTPUT                       |  MULTI-ROW OUTPUT                          |
|  -----------------                       |  -----------------                         |
|  * Exactly 1 value per endpoint          |  * Multiple records per single endpoint    |
|  * Example: `Tanium Client Version`      |  * Example: `Installed Applications`       |
|    Node 1 -> "7.6.1.1252"                |    Node 1 -> ["Chrome", "Slack", "Excel"] |
+---------------------------------------------------------------------------------------+

Single-Column Sensors

A single-column sensor outputs a discrete scalar value. For example, the Operating System sensor returns a single text line per machine. When viewed in the Tanium Interact results grid, this creates a single column named Operating System.

Multi-Column Sensors

A multi-column sensor returns structured records containing multiple fields separated by an internal delimiter (typically a pipe | or tab character). Tanium's sensor parser automatically unpacks the output string into separate, individual columns in the results grid.

For example, the sensor Network IP Connections returns:

• Column 1: Protocol (TCP/UDP)
• Column 2: Local IP (0.0.0.0)
• Column 3: Local Port (443)
• Column 4: Remote IP (198.51.100.24)
• Column 5: Remote Port (51234)
• Column 6: Process Name (httpd.exe)

Single-Row vs. Multi-Row (Multi-Valued) Outputs

• Single-Row: The sensor returns at most one record per endpoint (e.g., Computer Name, Chassis Type, Primary Owner User).
• Multi-Row: The sensor returns dozens or hundreds of lines from a single endpoint (e.g., Running Processes, Installed Applications, Open Ports). In the Tanium Console results grid, each unique value is counted and aggregated across the fleet, allowing operators to immediately spot outliers or widespread software versions.

---

5. Sensor Data Types and Operator Compatibility

When a sensor is authored, each output column is assigned an explicit Data Type. The assigned data type determines which comparison operators are available in the Question Bar, Question Builder, and Saved Question filters.

[!IMPORTANT] Version vs. String Sorting on the Exam: If a version number is stored as a String, alphabetical sorting fails on multi-digit segments: "10.0.0" would be evaluated as less than "9.0.0" because '1' precedes '9' alphabetically. However, when typed as Version, Tanium evaluates the numerical value of each delimited token (10 > 9), ensuring accurate operational patch and build comparisons.

---

6. Result Caching: Max Sensor Age and Maximum Data Age

Re-running an expensive script on every question would be wasteful, so a Tanium Client may answer from a cached sensor result instead of executing the script again. Two settings control how old that cached result is allowed to be, and the TCO exam expects you to know which is which.

Both control the maximum time for which Tanium Clients can use a cached result for a sensor instead of re-executing it for a fresh result.

                    [Question arrives at the Tanium Client]
                                      |
                                      v
                 [Is there a cached result for this sensor?]
                                /            \
                             [YES]           [NO]
                              |                |
                              v                |
        [Is the cached result younger than the applicable age limit?]
                   /                    \      |
                [YES]                  [NO]    |
                  |                      |     |
                  v                      v     v
        [Return the cached value]      [Run the sensor script,
                                        cache the result, return it]

Tuning guidance

• Static attributes — serial number, BIOS version, chassis type, installed memory — rarely change, so a long age limit costs nothing and saves endpoint CPU.
• Volatile attributes — running processes, CPU consumption, logged-in users — need a short limit or the answer is stale before you read it.
• Do not lower the defaults for sensors used in saved questions that periodically reissue, in questions you use to deploy actions, or in questions that define membership in computer management groups and filter groups. Tanium calls this out explicitly as a best practice: a lower Max Sensor Age or Maximum Data Age increases CPU usage on endpoints, and those three uses re-run constantly.

[!TIP] If you need genuinely fresh data for one investigation without changing platform-wide behaviour, set Maximum Data Age on that question rather than editing the sensor's Max Sensor Age. Editing the sensor changes the behaviour of every saved question, computer group and scheduled action that uses it.

---

7. Runtime Safety Safeguards

Sensors run on production endpoints under privileged accounts, so the Tanium Client constrains them rather than trusting them.

+---------------------------------------------------------------------------------------+
|                             SENSOR EXECUTION SAFEGUARDS                               |
+---------------------------------------------------------------------------------------+
|  1. Execution timeout     : the client terminates a sensor process that overruns      |
|  2. Resource throttling   : background execution at lowered process priority          |
|  3. Interpreter isolation : subprocess spawning with a controlled environment         |
|  4. Error trapping        : failures surface in the grid instead of hanging the client|
+---------------------------------------------------------------------------------------+

Sensor execution timeouts

The Tanium Client enforces an execution timeout on sensor scripts. A script that hangs on a blocked WMI call, waits on an unreachable network resource, or loops indefinitely is terminated rather than allowed to hold endpoint resources. The endpoint then returns an error string for that sensor instead of a value. The timeout is a client configuration setting rather than a fixed constant, so treat the behaviour as the exam-relevant fact: a slow sensor degrades into an error result, it does not stall the fleet.

Reading error results in the grid

Error strings are results too, and Interact will show them:

[!IMPORTANT] The TSE-Error behaviour is a genuine exam trap. A filter such as installed application version[chrome] <= 12 will evaluate to true on an endpoint that returned an error, because the error string is interpreted as 0. Always sanity-check counts that look implausibly high after a numeric filter.