Reference: Authoring signals

You can use signals through an integration with Tanium™ Trace for the continuous, real-time evaluation of process, network, registry, and file events on the endpoint. Signals implement a specific language that the Detect service ingests and validates for both language syntax and the currently supported terms and conditions. Signals are available as a feed from Tanium, or you can author your own signals.

In addition to using the Tanium Signal feed of tested and validated signals, you might want to create your own custom signals, specific to your environment. Signals provide a mechanism for you to detect suspicious or interesting process behavior, by combining multiple search expressions. A narrow search scope helps you minimize false-positive alerts.

How signals work

Signals use a specific language syntax to build search expressions for process-related events on the endpoint.

Like other intel, signals get validated when they are added to the Detect service to ensure proper structure. The signals are compiled, then sent and applied to the appropriate computer groups.

Unlike other types of intel, the Trace event recorder continuously inspects each process creation event in real time and starts up the Detect evaluation engine when a match occurs, rather than doing periodic scans. Each event gets evaluated against any signal definitions. Whenever a signal condition is matched, an alert is generated. Detect regularly polls the endpoints with a saved question to gather alerts. The alerts appear on the Alerts page in the Detect workbench.

Signal syntax

The syntax of signals are built from the supported objects, properties, conditions, and the search values into search expressions. One or more expressions make up the signal definition. The objects all reference process-related events. For example, a file object would mean an operation on a file by a process. A signal can have multiple expressions in a single definition, connected with AND or OR operands. When needed, you can use parentheses to dictate precedence. Writing a signal expression should follow one of these formats:

object.propertyconditionvalue

object.propertycondition'value with spaces'

Each object is a type of process event and has one or more properties that further narrow the scope of the event. The condition specifies how the object and property relate to the value provided. Not all conditions are supported with all object properties.

For full details about the supported objects, properties, and conditions, go to the Detect home page help , where you can access the Evaluation Engine documentation.

The following sample expressions demonstrate combined expressions, precedence, and escaped special characters:

(file.path starts with 'c:\\temp' OR file.path ends with '.evil.tmp') AND process.path contains cmd.exe

Signals are case-insensitive.

Signal use cases

Signals are designed to identify suspicious or malicious process activity in real time, and therefore are not intended to alert on large lists of file properties, such as hashes or filenames. These use cases are better solved with background intel scanning or reputation alerting. For example, alerting on excel.exe is not very useful and creates a lot of unnecessary activity with little value. However, if excel.exe launches Powershell.exe, that would be something a security operations center would want to know. The signal condition for that example would be:

process.path ends with ‘powershell.exe’ AND process.parent_path ends with ‘excel.exe’

Use signals to detect activity that, while not malicious, is unwanted within a specific group of computers. For example, the use of dsquery.exe or dsget.exe to administer Active Directory could be an unwanted activity. If your normal process is to use Powershell scripts developed in-house, it could signify that an intruder is trying to make modifications. Or if firewall settings are inherited through GPO settings, the use of netsh.exe on an endpoint might need to be understood.

Use signals to ensure that some activity has happened. For example, receiving alerts from servers when a critical application has launched following a reboot might be a signal to consider. Alerting that the w3wp.exe process has launched after an IIS server has rebooted might be something a Web Content team would want to see.

Signals must have a narrow scope, specific targets, and a clear intended use.

Testing signals

After you create a signal, test the signal in a lab before using it in a production environment. Verify that the signal is applied to the correct endpoints and returns the results that you expect.