3.1 Targeting Endpoints: from and with Filters, Operators and Boolean Logic
Key Takeaways
- Tanium Clients apply question filters on the endpoint and return only matching results, answering [no results] when nothing matches, so filtering reduces network traffic rather than adding server load.
- A with filter on the from clause decides which endpoints answer, while a having filter on a get clause sensor decides which rows those endpoints return.
- Sensor column filters use the syntax get <sensor> having <sensor>:<column> contains <value>, the column name is case sensitive, and single-column filtering requires a single-character column delimiter.
- The in operator works only in the from clause with parenthesised comma-separated values, while the get clause uses the matches operator with a regular expression alternation instead.
- Reserved words and the bracket characters used for parameterized sensor values must be enclosed in quotation marks when they are needed as literal text in a question.
3.1 Targeting Endpoints: from and with Filters, Operators and Boolean Logic
Quick overview: Blueprint objective RQ-1 asks you to target endpoints for questions or actions using natural language questions or the Question Builder. Targeting is where most wrong answers in real operations come from — too broad and you act on the wrong machines, too narrow and you miss the ones that matter. Tanium separates which endpoints answer (the
fromclause and its filters) from which rows those endpoints return (filters applied to sensors in thegetclause), and knowing which lever to pull is the core skill of this domain.
1. Where filters are evaluated
Filtering happens on the endpoint, not on the server. The get clause specifies the sensors Tanium Clients run; clients apply any filters to the sensor results and return only the filtered results. If nothing matches, the client answers [no results] — which is itself a result, and will appear in the grid.
This has two practical consequences:
- Filtering reduces network traffic, because non-matching rows never leave the endpoint.
[no results]rows tell you the endpoint answered; a missing endpoint tells you it did not. They are different problems and have different fixes.
2. Filter operators and boolean logic (AND vs. OR)
Tanium provides a rich library of comparison operators tailored to each sensor data type.
Comparison Operators
| Operator | Supported Data Types | Behavior / Example |
|---|---|---|
equals / does not equal | String, Numeric, Version, IP | Exact match (case-insensitive string comparison). |
contains / does not contain | String | Substring match anywhere within the text field. |
starts with / ends with | String | Matches prefix or suffix patterns. |
matches regex | String | Evaluates POSIX/PCRE regular expressions (e.g., ^[a-zA-Z]{3}\d{4}$). |
is greater than / is less than | Numeric, Version, Date | Arithmetic, semantic version, or chronological comparison. |
is in subnet | IP Address | Evaluates CIDR notation (e.g., 192.168.0.0/24). |
Boolean Logic & Precedence Rules
+---------------------------------------------------------------------------------------+
| BOOLEAN PRECEDENCE & PITFALLS |
+---------------------------------------------------------------------------------------+
| RULE 1: `AND` PRECEDES `OR` |
| In Tanium queries, `AND` operations bind more tightly than `OR` operations unless |
| explicitly grouped in the Question Builder. |
| |
| PITFALL 1: Mutually Exclusive `AND` Targeting |
| Query: `with Operating System contains Windows AND Operating System contains Linux` |
| Result: 0 machines respond! (A single machine cannot be both OS types). |
| Fix : Use `OR` -> `with Operating System contains Windows OR OS contains Linux` |
| |
| PITFALL 2: Ungrouped `OR` Broadening Scope |
| Query: `Get Running Service[Spooler] from all machines with OS contains Windows |
| OR Computer Name contains "TEST" AND Domain equals "corp.internal"` |
| Result: Due to precedence, this queries ALL Windows machines regardless of domain! |
| Fix : Group conditions using Question Builder parentheses / condition blocks. |
+---------------------------------------------------------------------------------------+
3. Row-level filtering (having) versus machine-level targeting (with)
[!IMPORTANT] A distinction the exam returns to repeatedly: Distinguishing between Machine-Level Targeting (
with) and Row-Level Filtering (having).
+---------------------------------------------------------------------------------------+
| ROW-LEVEL FILTERING VS. MACHINE-LEVEL TARGETING |
+---------------------------------------------------------------------------------------+
| SCENARIO A: Machine-Level Targeting Filter (`with`) |
| Query: `Get Installed Applications from all machines with Installed Applications |
| contains Chrome` |
| * How it Works: |
| 1. Tanium checks which endpoints have Google Chrome installed. |
| 2. Matching endpoints return ALL installed software (Chrome, Word, Zoom, Slack). |
| * Result: Full application inventory for Chrome-bearing endpoints. |
| |
| SCENARIO B: Row-Level Sensor Filter (`having`) |
| Query: `Get Installed Applications having Installed Applications:Name contains Chrome|
| from all machines` |
| * How it Works: |
| 1. ALL endpoints in the enterprise evaluate their installed applications. |
| 2. Endpoints filter their output rows locally and return ONLY Chrome records. |
| * Result: Clean single-application fleet report; non-matching rows discarded in RAM. |
| |
| SCENARIO C: Combining Both for Maximum Efficiency |
| Query: `Get Installed Applications having Installed Applications:Name contains Chrome|
| from all machines with Operating System contains Windows` |
| * Result: Targets only Windows machines AND returns only Chrome rows. |
+---------------------------------------------------------------------------------------+
5. Reading the live results grid
When a question is asked, Interact displays the Live Results Grid, which updates in real-time as peer-to-peer linear chains aggregate telemetry back to the Tanium Server.
+---------------------------------------------------------------------------------------+
| LIVE RESULTS GRID UI |
+---------------------------------------------------------------------------------------+
| Question: Get Operating System from all machines |
| Status : [████████████████████████████████████████] 100% Complete (48,500/48,500) |
| |
| [ Count ] [ Operating System ] |
| ────────────────────────────────────────────────────── |
| 32,140 Windows 11 Enterprise 23H2 |
| 11,200 Windows Server 2022 Datacenter |
| 4,850 Red Hat Enterprise Linux 9.2 |
| 310 macOS Sonoma 14.4.1 |
+---------------------------------------------------------------------------------------+
Grid Metrics Breakdown
- Percentage Complete Bar: Indicates what percentage of expected online endpoints have returned their answer tokens. Typically reaches 95–100% within 5 to 15 seconds across hundreds of thousands of endpoints.
- Responding Count: The actual number of distinct machines that reported back.
- Aggregated Group Count: Tanium automatically aggregates duplicate responses into a single row with an integer count (e.g., 32,140 machines share the exact same OS build), making enterprise compliance and drift immediately visible.
- Non-Responding Endpoints:
- If the grid reaches 98% and stops, the remaining 2% represent non-responding endpoints.
- Common reasons: endpoints powered off, asleep or hibernating, disconnected, VPN dropped, or a local firewall blocking Tanium port
17472. Non-response is normal; a fleet is never 100% online.
4. Syntax details that decide real questions
Reserved words and characters
The Tanium parser reserves certain words and characters to interpret question text. Notably it uses the bracket characters [ and ] to enclose the values of parameterized sensors, and variations of the word match to support regular expressions. When you need one of these as literal text, quote it:
| Goal | Question |
|---|---|
Computer names containing the letters in | Get Computer Name from all machines with Computer Name contains "in" |
Computer names containing the quoted string "test" | Get Computer Name from all machines with Computer Name contains """test""" |
| Preserve leading and trailing spaces | Get Computer Name from all machines with Computer Name contains " DBserver " |
Reserved words include operator words such as contains and having. Sensors whose names contain reserved words also need quoting in the Ask a Question field, or the suggestion list will match the wrong sensor.
Matching a list of values
| Clause | Operator | Form |
|---|---|---|
| from clause | in | with Chassis Type in (Virtual,Physical) — values in parentheses, comma separated. On issue, the field rewrites it as with (Chassis Type equals Virtual or Chassis Type equals Physical) |
| get clause | matches | `Get Last Logged In User matches "(root |
Sensor column filters on multi-column sensors
A multi-column sensor's result is really one string with column delimiters, so contains can match a value in an unexpected — or hidden — column. Target a specific column instead:
get <sensor> having <sensor>:<column> contains <value>
Two constraints that catch people out:
- The column name is case sensitive.
- Single-column filtering works only if the sensor configuration uses a single-character column delimiter such as
|, not a multi-character delimiter.
To match across all columns deliberately, use get <sensor> contains <value>.
$substring() filters
$substring() matches a pattern at a known position in a result string. It takes the sensor name, the starting position (0 is the first position), and the number of characters. On a multi-column sensor the $substring() filter applies across all the columns — you cannot scope it to one column.
Natural language help
If Tanium Ask is enabled, you can type a free-form question and it will propose a question in valid syntax. That is a fast way to start, but understanding the syntax still matters: you will want to edit the proposal, add filters or options, or reuse the question elsewhere.
6. A targeting checklist before you act
Targeting a question wrong costs you a confusing grid. Targeting an action wrong changes production endpoints. Before deploying anything from a result set:
- Reissue the question. Results expire after 10 minutes (30 for TDS-registered sensors), and your fleet has moved on.
- Check the count against expectation. If you expected roughly 200 endpoints and see 12,000, a filter is not doing what you think.
- Look for error rows. A numeric filter treats an error string as
0, soversion <= 12silently matches endpoints whose sensor failed. - Confirm which endpoints you can even see. Results come only from your assigned computer management groups, so "all machines" is never literally all machines.
- Prefer a filter you can re-read. A saved question or a computer group beats a long ad-hoc boolean expression that nobody, including you next week, can verify at a glance.
An operator needs a grid that lists only Google Chrome rows, and only from Windows endpoints. Which approach is correct?
Why can a plain contains filter on a multi-column sensor produce unexpected matches, and what is the documented fix?
An operator wants to target endpoints whose chassis type is either Virtual or Physical using the in operator. Where is the in operator available, and what happens when the question is issued?
An operator wants to find endpoints whose computer name contains the letter pair 'in'. Why does the unquoted question fail, and what is the fix?