3.5 Custom Tags and Tag-Based Grouping

3.5 Custom Tags and Tag-Based Grouping

Quick overview: Blueprint objective RQ-3 names custom tags alongside manual and dynamic groups, and for good reason: tags are how you group endpoints that no sensor can describe. Custom Tags is Tanium content that writes a label onto the endpoint itself — a registry entry on Windows, an entry in a flat file on Unix-like systems — which a Custom Tags sensor then reads back. Once an endpoint is tagged, Custom Tags behaves like any other sensor: you can ask questions about it, filter on it, and build a dynamic computer group from it.

---

1. The problem tags solve

Dynamic computer groups are excellent when a sensor value already describes the population you care about: an operating system, a subnet, an installed application version. They fall down when the population is defined by something the endpoint does not know about itself.

Consider these requirements:

• "The 340 workstations that are in scope for PCI."
• "The servers owned by the Finance application team."
• "The laptops in the executive support tier."
• "The endpoints in wave 3 of the migration."

None of these is discoverable from a sensor. They are not in a naming convention, they do not share an IP range, and they are not all running the same software. Building a manual group of 340 machines is possible but immediately goes stale.

Custom Tags closes that gap. You write the fact onto the endpoint once, and from then on it is queryable data like any other.

---

2. How custom tags actually work

   +---------------------------------------------------------------+
   |  1. DEPLOY A TAGGING ACTION                                   |
   |     A Custom Tagging package writes the tag on the endpoint:  |
   |       Windows      -> a registry entry                        |
   |       Unix / Linux -> an entry in a flat file                 |
   +---------------------------------------------------------------+
                                |
                                v
   +---------------------------------------------------------------+
   |  2. THE CUSTOM TAGS SENSOR READS IT BACK                      |
   |       Get Custom Tags from all machines                       |
   |     -> returns the tags present on each endpoint              |
   +---------------------------------------------------------------+
                                |
                                v
   +---------------------------------------------------------------+
   |  3. THE TAG BECOMES GROUPABLE AND TARGETABLE                  |
   |     - filter questions on it                                  |
   |     - define a DYNAMIC computer group whose membership        |
   |       is 'Custom Tags contains PCI'                           |
   |     - target actions at that group                            |
   +---------------------------------------------------------------+

The important architectural point: the tag lives on the endpoint, not in the Tanium database. That has consequences worth knowing.

---

3. Tagging and untagging

Both operations are packages deployed as actions, which means everything in chapter 4 applies to them: targeting, scheduling, approval where it is required, and action history for the audit trail.

Because tagging is an action, it is also auditable: who tagged which endpoints, when, and with what value is recoverable from Action History. That is a meaningful advantage over a manual computer group, where membership changes leave a much weaker trail.

[!TIP] Tag removal is the step teams forget. A "wave 3" tag that is never removed quietly becomes wrong, and every dynamic group built on it becomes wrong with it. Decide the removal trigger at the same time you decide the tag.

---

4. Using tags in questions and groups

Asking about tags

Get Custom Tags from all machines

A counting question here gives you an immediate picture of how the fleet is labelled — and, just as usefully, how many endpoints carry no tag.

Filtering on tags

Get Computer Name and Operating System from all machines with Custom Tags contains PCI

Grouping on tags

The high-value pattern: define a dynamic computer group whose membership condition is a custom tag. You now have a self-maintaining group for a population that no sensor could describe.

   Computer group:  "PCI In-Scope Endpoints"
   Type:            dynamic (filter-based)
   Membership:      Custom Tags contains PCI

Every endpoint that carries the tag joins automatically. Untag an endpoint and it leaves. The group is as accurate as your tagging discipline, which is exactly the right place for the accuracy to live.

---

5. Choosing between manual groups, dynamic groups and tags

The decisive question is: does anything on the endpoint already tell me this? If yes, use a dynamic group. If no, and the population matters for more than a moment, tag it.

---

6. Practical cautions

• Tags are only as good as their governance. An untracked tag vocabulary becomes a mess of PCI, pci, PCI-scope and PCIScope. Agree the values before you deploy the first tagging action.
• Tagging is a change to the endpoint. It writes to the registry or to a file, so it goes through the same action workflow — and the same approval requirements — as any other change.
• Reimaging clears tags. If a tag matters for compliance scope, tagging must be part of the build or provisioning process rather than a one-off campaign.
• Membership still evaluates through a sensor. A tag-based dynamic group is a dynamic group, so the caution from section 3.4 applies: do not lower the default age limits for the sensor that defines membership.
• Tags do not grant visibility. A tag-based group is only useful to an operator whose computer management groups already include those endpoints.