Alerting System

Overview

Alerting in Energy Logserver is the early warning system, automatically monitoring log data and generating notifications when security events occur. It provides 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 Alerting interface consists of the following 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

Energy Logserver ships with a library of pre-built alert rule groups organized by vendor, platform, and use case. These groups can be enabled selectively based on your environment.

Available Groups

Vendor-specific:

Group	Rules	Description
AWS	33	Amazon Web Services security events
Checkpoint	25	Check Point firewall events
Cisco ASA	11	Cisco ASA firewall events
Cisco ESA	8	Cisco Email Security Appliance events
Cisco VPN	5	Cisco VPN connection events
F5	3	F5 load balancer events
FireEye	16	FireEye threat detection events
Forcepoint	6	Forcepoint web/email security events
Fudo	5	Fudo PAM privileged access events
Infoblox	14	Infoblox DNS/DHCP/IPAM events
Juniper	5	Juniper network device events
McAfee	6	McAfee endpoint security events
Mikrotik	5	MikroTik router events
QualysGuard	6	Qualys vulnerability scanner events

Infrastructure:

Group	Rules	Description
Cluster-Health	25	ELS Data Node cluster health monitoring
HTTP	9	HTTP traffic anomaly detection
Switch	10	Network switch events

Operating systems and services:

Group	Rules	Description
Linux	25	Linux system security events
Microsoft Windows	1	General Windows security events
Microsoft Windows DHCP	11	Windows DHCP server events
Microsoft Windows DNS	12	Windows DNS server events
Exchange	6	Microsoft Exchange mail server events
Microsoft MsSQL	6	Microsoft SQL Server events
MySQL	10	MySQL database events
PostgreSQL	11	PostgreSQL database events
Postfix	6	Postfix mail server events
Squid	7	Squid proxy events

Security and correlation:

Group	Rules	Description
Correlated	30	Cross-source correlated security events
Empowered AI	31	AI-driven anomaly detection rules
Ransomware	8	Ransomware activity detection

Using Pre-built Groups

Browse the available groups in the Alert Rules List.
Expand a group to review included rules.
Enable or disable individual rules as needed.
Customize rule thresholds and parameters if required.
Save changes and monitor alert activity.

Escalation and Recovery

Escalate

The escalate_users parameter assigns alert notifications to a specific user or group of users. The escalate_after parameter escalates the notification recipient after a defined period of time.

Example:

escalate_users: ["user1", "user2"]
escalate_after:
  days: 2

In this example, user1 and user2 receive an escalation notification two days after the initial alert.

Recovery

The recovery parameter defines an additional action to perform after the conditions that triggered the initial alert are no longer met.

recovery: true
recovery_command: "command"

Field values can be referenced in the recovery command using two syntaxes:

%{field_name} — pulls the value from the alert match (e.g. %{@timestamp_recovery})
${field_name} — pulls the value from the rule definition (e.g. ${name})

The @timestamp_recovery variable contains the time at which the recovery was executed.