Skip to content

Triggers

Triggers define output of correlators, baselines etc. They live in the trigger section of the correlator. Each rule in the library can define many triggers (it is a list).

The trigger can access the original event by !EVENT statement, it is the last event that passed evaluation test.

The value from the aggregator function is availabe at !ARG.

event trigger

This trigger inserts a new event into the complex event lane.

Example of the event trigger:

trigger:
  - event:
      threat.indicator.confidence: "Medium"
      threat.indicator.ip: !ITEM EVENT source.ip
      threat.indicator.port: !ITEM EVENT source.port
      threat.indicator.type: "ipv4-addr"

There may be up to 5 results, like in mean spike aggregator:

trigger:
  - event:
      events: !ARG EVENTS
      MeanSpike:
        !GET
        from: !ARG RESULTS
        what: 0
      MeanSpikeLastCount:
        !GET
        from: !ARG RESULTS
        what: 1
      MeanSpikeMean:
        !GET
        from: !ARG RESULTS
        what: 2

signal trigger

This trigger emits a signal for LogMan.io Alert Management. The payload is published for consumption by LogMan.io Alerts, which creates or updates tickets according to grouping rules.

The YAML under - signal: maps fields into the signal’s attributes, in the same spirit as the event trigger maps fields into a complex event. Expressions such as !ITEM EVENT … refer to the event that passed the rule’s test (see the introduction above).

This is an explicit entry in the trigger list. It complements the default correlator signal controlled from the rule declaration’s signal: block (default, grouping, title, etc.); see Default signals and Signal. Use - signal: when you need a dedicated, field-by-field mapping, for example in a lookup watch that should open or update tickets with specific dimensions.

Example of the signal trigger:

trigger:
  - signal:
      host.id: !ITEM EVENT host.id
      we.task_name: !ITEM EVENT task.name
Optional keys in the trigger mapping are interpreted specially before the rest are stored as attributes: title, description, severity, and additional_attributes (a list of field names for the alert UI). If omitted, title and description can fall back to the rule’s signal: or define section in the library declaration.

Under define → signal, you can set options that apply to the signal produced by this trigger, for example:

  • direction default up (may be overridden from processing context).
  • period optional signal period (duration); stored on the signal when set.
  • grouping list of field names used to build the group id for ticket grouping (see Grouping attributes).
  • additional_attributes default list of attribute names to highlight in Alert Management when not set in the trigger mapping.

At runtime, the correlator (via SignalPipeline in the processing library) sends serialized signals toward the configured Kafka topic for signals (default topic name in the reference implementation is lmio-signals).

lookup trigger

Lookup trigger manipulates with the content of the lookup. It means that it can add (set), increment (add), decrement (sub) and remove (delete) an entry in the lookup.

The entry is identified by a key, which is a unique primary key.

Example of the trigger that adds an entry to the lookup user_list:

 trigger:
  - lookup: user_list
    key: !ITEM EVENT user.name
    set:
      score: 1

Example of the trigger that removes an entry from the lookup user_list:

 trigger:
  - lookup: user_list
    delete: !ITEM EVENT user.name

Example of the trigger that increments a counter (field my_counter) in the entry of the lookup user_list:

 trigger:
  - lookup: user_list
    key: !ITEM EVENT user.name
    add: my_counter

Example of the trigger that decrements a counter (field my_counter) in the entry of the lookup user_list:

 trigger:
  - lookup: user_list
    key: !ITEM EVENT user.name
    sub: my_counter

If the counter field does not exist, it is created with the default value of 0.

notification trigger

This trigger inserts a new notification into the primary data path, that is read by asab-iris.

Example of the notification trigger:

  - notification:
      type: email
      template: "/Templates/Email/notification_4728.md"
      to: eliska.novotna@teskalabs.com
      variables:
        name: "brute-force"
        events: !ARG