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 Parameters
values of theTask Scheduler
component. 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.