2.2 Parameterized Sensors and Question Parameter Syntax

2.2 Parameterized Sensors and Question Parameter Syntax

Quick overview: A parameterized sensor cannot run until you supply input. Rather than dumping every file on a disk or every key in the registry, it inspects exactly the path, key, service or count you name. When you use one in a dynamic question, Interact prompts you for the values, and the Tanium Server builds a temporary sensor containing the substituted values and sends that to the clients. In written Tanium question syntax the supplied values appear in square brackets immediately after the sensor name: High CPU Processes[5].

---

1. Why parameterized sensors exist

An enterprise endpoint holds millions of files, registry values and event records. A static sensor that enumerated all of them would be unusable: the script would run for minutes, the payload would be enormous, and the results grid would be unreadable.

+---------------------------------------------------------------------------------------+
|                     STATIC SENSOR             vs.     PARAMETERIZED SENSOR            |
+---------------------------------------------------------------------------------------+
|  Enumerates a whole namespace          |  Inspects only the item you name             |
|  Heavy disk I/O and CPU on endpoint    |  Cheap, targeted execution                   |
|  Large result payload across the chain |  Small, single-line payload                  |
|  "list every installed application"    |  "does C:\Windows\System32\cmd.exe exist"    |
+---------------------------------------------------------------------------------------+

The operational payoff is scale. Checking one indicator-of-compromise file path across 500,000 endpoints is a small question; enumerating every file on 500,000 endpoints is not a question you would ever ask.

---

2. How the platform handles a parameterized sensor

This mechanism is worth understanding because it explains several behaviours you will meet in the console.

1. You select a parameterized sensor in the Ask a Question field or the Question Builder.
2. Interact prompts you for the parameter values. What the prompt looks like — a text input, a text area, a drop-down list, a checkbox, a numeric field — is defined by the Parameter Inputs configured on the sensor, and those inputs can carry validation expressions and help text.
3. The Tanium Server URL-encodes the values you entered and creates an object called a temporary sensor that contains the substituted values.
4. That temporary sensor is what goes out in the question to the Tanium Clients. The sensor script decodes the encoded parameters at runtime — PowerShell sensor scripts, for example, use [System.Uri]::UnescapeDataString().

[!IMPORTANT] You do not need to hand-escape values for the transport layer. The Server encodes what you type. This is why a Windows path with backslashes and spaces, typed exactly as it appears in Explorer, works correctly through the parameter prompt.

---

3. Written question syntax: square brackets

When a question containing a parameterized sensor is written out — in documentation, in question history, in a saved question definition, or when you type a question you already know — the parameter values follow the sensor name in square brackets:

                     PARAMETERIZED SENSOR IN QUESTION TEXT

              sensor name              value in square brackets
          +--------------------+      +-----+
   Get    | High CPU Processes |      | [5] |      from all machines
          +--------------------+      +-----+
                                 ^
                                 |
                    no space between the sensor name
                    and the opening bracket

Tanium's own reference on question syntax is explicit about this: the Tanium parser treats [ and ] as reserved characters, and "uses the bracket characters [ and ] to enclose the values of parameterized sensors". That is also why brackets used as literal text in a question must be quoted — the parser would otherwise read them as a parameter.

Official Tanium examples of the form:

Notice the third example: a parameterized sensor is legal in the filter as well as in the get clause. What is not legal is calling a parameterized sensor with no parameters at all — the sensor has nothing to inspect and cannot run.

Multiple parameters

A sensor may define several Parameter Inputs. In the console you complete one prompt per input, in the order the sensor defines them. In written form the values appear in the same defined order inside the brackets, separated by the delimiter the sensor's schema specifies. Order matters: transposing a registry key path and a value name will simply fail to find the key.

Where curly braces really appear in Tanium

Curly braces are not the parameter syntax for questions, and conflating the two is a common study error. Braces you may legitimately encounter belong to other layers — for example a Windows CLSID such as {00021401-0000-0000-C000-000000000046} inside a registry path you are passing as a value, or brace syntax in a script that a sensor or package happens to run. Package command lines are a different mechanism again and use positional tokens such as $1 and $2, covered in section 4.1.

---

4. Common mistakes

+---------------------------------------------------------------------------------------+
|                       PARAMETERIZED SENSOR MISTAKES                                   |
+---------------------------------------------------------------------------------------+
|  1. CALLING THE SENSOR BARE                                                           |
|     WRONG : Get Registry Value Data from all machines                                 |
|             with Registry Value Data equals 7.6.1                                     |
|     WHY   : the sensor needs its inputs to run at all; a filter clause does not        |
|             supply them                                                                |
|     RIGHT : supply the key path and value name through the parameter prompt            |
|                                                                                       |
|  2. TRANSPOSING POSITIONAL VALUES                                                     |
|     WRONG : value name first, key path second                                          |
|     RESULT: the script looks in the wrong place and returns nothing found              |
|                                                                                       |
|  3. ASSUMING A SAVED QUESTION IS STILL PARAMETERIZABLE                                |
|     A saved question stores the values that were supplied when it was saved.           |
|     A different value needs a different saved question.                                |
|                                                                                       |
|  4. FORGETTING THAT ERRORS FILTER AS ZERO                                             |
|     installed application version[chrome] <= 12 also matches endpoints whose           |
|     sensor returned an error, because Interact reads the error string as 0.            |
+---------------------------------------------------------------------------------------+

---

5. Parameterized sensors downstream

In saved questions

When you save a question containing a parameterized sensor, the values you supplied are stored in the saved question definition. The saved question will reissue with those values forever. To monitor a second service, a second file path or a second registry value, create a second saved question — this is why mature environments accumulate families of near-identical saved questions with different bracketed values.

In drill-down

Drill-down is parameter-aware. If the results you select include the value of a parameterized sensor and your drill-down question uses a sensor with a matching parameter, the Select Drill-down Question dialog automatically populates that parameter with the value from the selected results. This is a genuine time-saver during triage: select the suspicious row, drill down, and the path or process name is already filled in.

In Tanium Data Service

Each distinct parameter combination is registered and stored separately. Running Service[Spooler] and Running Service[WinDefend] are two registrations, not one, so registering parameterized sensors broadly in TDS multiplies storage rather than adding to a single dataset.

---

6. Sensors an operator meets constantly

[!TIP] Before an incident, know which of these your environment actually has and what their prompts look like. In a practical exam item, hunting for the right sensor name costs more time than answering the question does.