Using tokens
Tokens are data generated after a job is executed. They work as variables and store field values and can be used when creating a job in Job Scheduler.
Types of tokens:
- local - created from the search result. Identified as
{{token_name}} - global - Created from the
Global Parametersvalues of theTask Schedulercomponent. Identified as<global_token_name>
The local token syntax is {{_source.field_name }}, where field_name is the name of the field from the event in the search query. For example, if the field name in the search query is host.ip, then the token for this field is {{_source.host.ip}}.
The global token has the syntax <global_token_name>, where global_token_name is the name of the global token. For example, the token <guid>.
Another type of token is <job-meta-field:field_name>. It allows you to use a field from a query result or a _meta field.
Example. Using Search Query Fields:
| Parameter | Syntax | Description |
|---|---|---|
title | <job-meta-field:title> | Job name |
description | <job-meta-field:description> | Job description |
List of available _meta fields:
| Parameter | Syntax | Description |
|---|---|---|
id | <job-meta-field:_meta.id> | Job ID |
type | <job-meta-field:_meta.type> | Values from the Object Type field in the Job Scheduler module interface |
version | <job-meta-field:_meta.version> | Job Scheduler module version. |
module | <job-meta-field:_meta.module> | Undefined - when creating your own task, SAF Cyber Security - when importing from a module SAF Cyber Security. |
created | <job-meta-field:_meta.created> | Job creation date |
update | <job-meta-field:_meta.update> | Job update date |
tag_ids | <job-meta-field:_meta.tag_ids> | List of job tags. Multiple tags are allowed. |
An example of using tokens.
Create a new job in Job Scheduler:
- Name -
RULE-CS-Sysmon-DetectedTaskList - Description - An attempt was detected to view the list of tasks on the host
{{_source.host.name}}with GUID(<guid>)Search task name:<job-meta-field.title>
Fill in search and other fields:
source sysmon_operational-*
| search event.code=1 AND command_line="C:\\Windows\\system32\\tasklist.exe"
| aggs count, values(winlog.process.pid) as winlog.process.pid, latest(rule_name_technique_id) as rule_name_technique_id, latest(rule_name_technique_name) as rule_name_technique_name, values(event.action) as event.action, values(host.ip) as host.ip by host.name
| eval title=<job-meta-field:title>
| where count > 1
| table host.name, count, winlog.process.pid, rule_name_technique_id, rule_name_technique_name, event.action, host.ip
- Time interval - Last 60 minutes
- Time field -
@timestamp - Duration of the lock (in seconds) - 60
Frequency of execution:
- Schedule type - Cron Expression
- Cron - 3-59/5 * * * *
- Schedule delay - 0
Suppression of execution:
- Duration - 5 Minutes
Global Params
- Key -
guid - Value -
guid()
The example uses the local token {{_source.host.name}}, the global token <guid> and the token <job-meta-field>:

To use a token <job-meta-field:field name> you need to write the token value in the search query using the command eval field (the field name can be anything).
When local tokens are used, the _source is a system object and stores all fields of the source event. In general, the token usage looks like {{_source.field_name}}, where field_name is the name of the field in the event.
As a result of job being triggered, an incident will be created, tokens are replaced with values.