Alerting System

Overview

Alerting in Energy Logserver SIEM is your early warning system, automatically monitoring log data and generating notifications when security events occur. Developed by EMCA Software sp. z o.o., it acts as a vigilant security guard, ensuring continuous surveillance of your environment.

What is Alerting?

Alerting transforms raw log data into actionable security intelligence by detecting patterns, anomalies, and known threat indicators in real-time, supporting compliance and incident response.

Straightforward explanation:

  • What it is: An automated security event detection system.

  • How it works: Define rules; the system monitors data and alerts when matches occur.

  • What it does: Enables early threat detection, incident response, and compliance monitoring.

Alerting Interface Overview

The Energy Logserver SIEM Alerting interface consists of 4 main tabs within the SIEM section:

How Tabs Work Together

Alert Rules → Incidents → Playbooks → Risk Management

Workflow:

  • Define or enable alert rules.

  • Manage triggered incidents.

  • Execute automated playbooks.

  • Track and calculate risk scores.

Creating Your First Alert

Energy Logserver allows you to create alerts, i.e., monitoring queries. These are constant queries that run in the background, and when the conditions specified in the alert are met, the specified action is taken.

For example, if you want to know when more than 20 “status:500” response codes from your homepage appear within one hour, then create an alert that checks the number of occurrences of the “status:500” query for a specific index every 5 minutes. If the condition is met, an action is sent, such as a message to an email address or launching a script.

Enabling the Alert Module

SMTP Server Configuration

To configure the SMTP server for email notifications, you should:

  • Edit /opt/alert/config.yml and add the following section:

    # email conf
smtp_host: "mail.example.com"
smtp_port: 587
smtp_ssl: false
from_addr: "siem@example.com"
smtp_auth_file: "/opt/alert/smtp_auth_file.yml"

  • Add the new /opt/alert/smtp_auth_file.yml file:

    user: "user"
password: "password"

  • Restart the alert service:

    systemctl restart alert

Alert Creation

Navigation: ELS Console → SIEM → Alerts → Create Alert Rule

The alert creation form is a single-page form with the following fields:

Basic Identity

  • Name — descriptive name for the alert rule

  • Rule Type — type of detection logic. Available options: Any, Blacklist, Blacklist-IOC, Cardinality, Chain, Change, Consecutive Growth, Difference, Difference Multi Pattern, Find Match, Flatline, Logical, Metric Aggregation, New term, Percentage Match, Spike, Unique Long Term, Whitelist. Selecting a Rule Type updates the Description field dynamically with an explanation of the selected type.

  • Group Name — organizes alerts into groups for management (e.g., Linux, Windows Security, Netflow, Correlated)

  • Description — read-only field, auto-populated based on selected Rule Type

Scope

  • Role — user role scope for the alert

  • Index Pattern — index pattern to query (e.g., windows-security-*)

  • Read Fields — button that loads available fields from the selected index pattern

Risk Settings

  • Risk Key — field used as the risk key for scoring

  • Multiple risks aggregation — aggregation method: avg, custom, max, min, sum. Default: avg

  • Risk boost [%] — percentage multiplier for risk scoring. Default: 100

Discovery

  • Generate Discover URL — toggle (off by default). When enabled, generates a Discover link attached to the alert notification

Notification

  • Alert Method — delivery method for alert notifications. Available options: Command, Email, Energy SOAR, ITRS OP5 Monitor, Jira, None, ServiceNow, Slack, Syslog, TheHive Project, User, WebHook Connector

Rule Definition

  • Example — collapsible section with a YAML example for the selected Rule Type

  • Rule Definition — code editor for writing the alert rule in YAML format

Playbooks

  • Playbooks — toggle (off by default). When enabled, allows associating playbooks with this alert rule

Form Actions

  • Test Rule — validates the rule definition without saving

  • Enable alert — toggle to set the alert as active upon creation (on by default)

  • Submit — saves and creates the alert rule

List of Alert Rules

The Alert Rules List tab displays all created alert rules organized in collapsible groups. The toolbar provides a search bar for filtering by rule name, group, type, method, index pattern, or status, as well as buttons for saving rule files, refreshing the list, and creating new groups.

Each group can be expanded to show individual rules. Group-level actions include Add alerts to group, Rename group, and Delete group.

Each alert rule row contains the following columns: Name, Index Pattern(s), Type, Alert Method, Role, and Status. The Status column is a clickable toggle that enables or disables the rule directly.

Per-rule actions are available on hover: Run once (executes the rule immediately), Show (opens read-only view). The All actions dropdown provides: Run once, Show, Update (edit the rule), and Delete.

Alerts Status

In the “Alert Status” tab, you can check the current alert status: whether it is activated, when it started and ended, how long it lasted, how many events it found, and how many times it worked.

Also, on this tab, you can recover the alert dashboard by clicking the “Recovery Alert Dashboard” button.

Alert Rule Types

Alert rule types define how the system detects events. Available types:

Basic Alerts

  • Any: Triggers on any matching event.

  • Blacklist: The blacklist rule will check a certain field against a blacklist, and match if it is in the blacklist.

  • Blacklist-IOC: The blacklist rule will check a certain field against a blacklist, and match if it is in the blacklist (can be used for large files).

  • Cardinality: This rule matches when the total number of unique values for a certain field within a time frame is higher or lower than a threshold.

  • Change: This rule will monitor a certain field and match if that field changes. The field must change with respect to the last event with the same query_key.

  • Consecutive Growth: Rule matches for value difference between two aggregations calculated for different periods in time.

  • Difference: This rule calculates percentage difference between aggregations for two non-overlapping time windows.

    • Required parameters:

      • type: difference - Enable the rule.

      • compare_key: value - Field for aggregation calculation.

      • threshold_pct: 10 - Alert triggers when percentage difference exceeds this value.

      • delta_min: 3 - Difference in minutes between calculated aggregations.

      • agg_min: 1 - Aggregation bucket in minutes.

    • Optional parameters:

      • query_key: hostname - If present, calculates aggregation for each unique query_key (must be of type keyword).

    • Calculation:

      • For current time x, historical and present time windows are defined as: <x – agg_min – delta_min; x – delta_min> <= <x – agg_min; x>, where x – delta_min <= x – agg_min => delta_min >= agg_min.

      • Percentage difference: d = | avg_now – avg_history | / max(avg_now, avg_history) * 100 (if avg_now – avg_history != 0, avg_now != 0, avg_history != 0); otherwise, d = 0.

      • avg_now is the arithmetic mean of <x – agg_min; x>, and avg_history is the arithmetic mean of <x – agg_min – delta_min; x – delta_min>.

  • Difference Multi Pattern: The rule matches the difference in values between two aggregations from two index patterns calculated in a unit of time.

  • Find Match: Rule matches when, in a defined period of time, two correlated documents match certain strings.

  • Flatline: Triggers when event count drops below threshold.

  • Frequency: This rule matches when there are at least a certain number of events in a given time frame.

  • Metric Aggregation: Aggregates metrics and alerts on thresholds.

  • New Term: Detects new values in a monitored field.

  • Percentage Match: This rule matches when the percentage of documents in the match bucket within a calculation window is higher or lower than a threshold.

  • Spike: Detects sudden increases in event frequency.

  • Unique Long Term: This rule matches when there are values of compare_key in each checked timeframe.

  • Whitelist: Similar to blacklist, this rule will compare a certain field to a whitelist, and match if the list does not contain the term.

Advanced Alerts

  • Chain: Combines multiple rules. Rule matches when a complex, logical criteria is met. Rule can be used for alert data correlation.

    • Example:

      • Alerts that must occur:

        • Linux - Login Failure: Must appear 10 times.

        • AND

        • Linux - Login Success: Must appear 1 time.

      • If the sequence of these alerts occurs within 5 minutes and the values of the “username” field are related, the alert rule is triggered. The order of occurrence is important.

  • Logical: Rule matches when a complex, logical criteria is met. Rule can be used for alert data correlation.

    • Example:

      • Alerts that must occur:

        • Switch - Port is off-line: Must appear 5 times.

        • OR

        • Switch - Port is on-line: Must appear 5 times.

      • If both alerts are met within 5 minutes and the values of the “port_number” field are related, the alert rule is triggered. Logical connectives such as OR, AND, NOR, NAND, XOR can be used.

Working with Pre-built Alert Groups

Navigation: ELS Console → SIEM → Alert Rules

Process

  1. Browse pre-built groups.

  2. Select a group (e.g., “Windows Security”).

  3. Review included rules.

  4. Enable/disable individual rules.

  5. Customize thresholds if needed.

  6. Save and monitor.