Reference: Authoring signals

Signals implement a specific language to be used for the continuous, real-time evaluation of process, network, registry, and file events on the endpoint through an integration with Tanium Trace. The Detect service ingests and validates this intel for both proper language syntax and the currently supported terms and conditions. They are available as a feed from Tanium or they can be written manually.

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.

For more information about the signals provided by Tanium, see Connect to the Tanium Signals feed.

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 sample expressions below show how to handle combined expressions, precedence, and escaped special characters.

  • process.command_line contains 'evil' AND process.path starts with 'c:\\windows'
  • (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’

Signals can be used 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 the 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.

Signals can be used 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.

As with all signals, be sure that your signal has a narrow scope, specific targets, and that the intended use is clear.

Testing signals

When you have created your signal, test it in a lab setting before rolling it out to production. Verify that it is applied to the correct endpoints and returns the results that you expect.

  1. Create your signal.

    See Add signals for more information.

  2. Apply the signal to a group configuration for your test computer group that has Detect tools already installed.
  3. If you cannot wait for the intel deployment interval, click Deploy Intel Now.
  4. On one or more endpoints within the configured computer group, trigger the conditions of the signal.
  5. Confirm that the alert has been received by the Detect workbench.

Iterate on this process until you are satisfied with the results.

Last updated: 2/20/2018 1:21 PM | Feedback