Skip to content


The declarations for baselines are loaded from the library from the folder specified in the configuration, such as /Baseliners.


The Baseliner uses /Schemas/ECS.yaml by default, so it also must be present in the library.


This is the example of the baseline definition, located in /Baseliners folder in the library:

    name: Dataset
    description: Creates baseline for each dataset and trigger alarms if the actual number deviates
    type: baseliner

    region: Czech Republic
    period: day
    learning: 4  # samples (till the baseliner is "learned" for a given "key")
    classes: [workdays, weekends, holidays]

    key: event.dataset
    timestamp: "@timestamp"

        - !LT
            - !ARG VALUE
            - 1
        - !GT
            - !ARG MEAN
            - 10.0

    - event:
            # Threat description
            threat.framework: "MITRE ATT&CK"
            threat.indicator.sightings: !ITEM EVENT value
            threat.indicator.confidence: "High"
   !ITEM EVENT dimension

    - notification:
            type: email
            to: [""]
            template: "/Templates/Email/"

                name: "Logs are not coming to the dataset within the given UTC hour."
                dimension: !ITEM EVENT dimension
                hour: !ITEM EVENT hour



Defines how the given baseline is going to be build.

The region defines in which region the activity is happening (for calculating holidays and so on).

The period says which timespan is relevant for the baseline, it can be either day or week.

The classes include which days in the week we want to monitor, it can be workdays, weekends and holidays.

predicate (optional)

Filters incoming events to be considered an activity in the baseline.

The filter is specified using SP-Lang.


This section specifies which attributes from the event are going to be used in the baseline build.

There are two options.

The attribute key specifies the attribute/entity to monitor.

The timestamp specifies the attribute in which the time dimension of the event activity is stored in.


The test section in analyze specifies, when to run trigger, if the actual activity (!ARG VALUE) deviates from the baseline.

The following attributes are available, used in the SP-Lang notation:

TENANT: "str",
VALUE: "ui64",
STDEV: "fp64",
MEAN: "fp64",
MEDIAN: "fp64",
VARIANCE: "fp64",
MIN: "ui64",
MAX: "ui64",
SUM: "ui64",
HOUR: "ui64",
KEY: "str",
CLASS: "str",


Which trigger to run after a successful analysis. The example of the trigger is:

    - notification:
            type: email
            to: [""]
            template: "/Templates/Email/"

                name: "Logs are not coming to the dataset within the given UTC hour."
                dimension: !ITEM EVENT dimension
                hour: !ITEM EVENT hour

The argument EVENT provided in the !ARG expression contains the following attributes.


The name of the tenant the baseline belogs to.


The dimension the baseline belongs to, as specified in evaluate.


The class the baseline was calculated from.

Options include: workdays, weekends and holidays


The number of the UTC hour the analysis happend in.


The value of the current counter of events for the given UTC hour.

Analysis in UI

By default, UI provides the following display of analysis: user and host

The analysis to use needs to be specified in the schema (default: /Schemas/ECS.yaml) in the following way:
    type: "str"
    analysis: host
    type: "str"
    analysis: user


If then the tenant is configured to use this schema (ECS by default), the and fields in Discover screen will show a link to the given baseline.

Analysis host will utilize the baseline, which has name Host, by default:

  name: Host

Analysis user will utilize the baseline, which has name User, by default:

  name: User

If the analysis cannot find its associated baseline, it will show an empty screen.


Both baselines needed for analysis are distributed as part of Common Library.