Alerts management

The Alerts management functional includes:

  • filtering
  • normalization
  • prioritization
  • categorization
  • response
  • visualization

These functions are distributed over all components of Alertflex (collector, controller, worker, console).


Filtering policy is a file in JSON format that describer operation such as alert aggregation and modification, whitelist and blacklist for alerts. Alertflex collector (Altprobe) applies the policy for every new event that comes to the system. Below, example part of filtering policy for Wazuh alerts:

    "hids": {
    "log": true,
    "severity": {
        "threshold": 1,
        "level0": 2,
        "level1": 4,
        "level2": 10
    "gray_list": [{
        "event": "5715",
        "agent": "flghost",
        "match": "indef",
        "aggregate": {
            "reproduced": 0,
            "in_period": 0
        "response": {
            "profile": "indef",
            "new_type": "indef",
            "new_source": "indef",
            "new_event": "55715",
            "new_severity": 1,
            "new_category": "new cat",
            "new_description": "new desc"

In the example above, Graylist consists policy for the event with ID 5715 (Wazuh classification), if an event with such ID come to Altprobe, next actions apply for events:

  • ID of the event will be modified to 55715
  • level of severity for the alert will be 1
  • new category new cat will be added to alert
  • description of alert will be modified to new desc

The filtering policy is loaded during the start of the Altprobe from file filter.json, that located in the directory /etc/altprobe. Also, the filtering policy can be dynamically changed and loaded to collectors from the central node via the Alertflex console. On the central node different versions of filtering policies store in dedicated folders for every collector node. For operations with filtering policy via Alertflex console open web-form FILTER POLICIES



Collected from sources alerts will be parsed and normalized by Altprobe. Below, a standard format of the alert record.

field SQL type description
alert_id bigint(20)  
alert_uuid char(37)  
node_id varchar(255)  
ref_id varchar(255)  
source varchar(32)  
type varchar(32)  
event varchar(512)  
severity int(10)  
score int(10)  
category varchar(1024)  
description varchar(1024)  
srcip varchar(128)  
dstip varchar(128)  
srcagent varchar(128)  
dstagent varchar(128)  
srcport int(10)  
dstport int(10)  
user varchar(512)  
process varchar(512)  
file varchar(512)  
agent varchar(512)  
container varchar(512)  
sensor varchar(512)  
location varchar(1024)  
status varchar(32)  
action varchar(256)  
filter varchar(512)  
info varchar(1024)  
time_event varchar(512)  
time_collr datetime  
time_cntrl datetime  
json_event text  


Alertflex severity format consist four levels for alerts:

level severity
0 Info
1 Minor
2 Major
3 Critical

Alerts from different sources use different types of severity, priorities, and scores. To normalize severity for alerts according to one common format Alertflex uses two ways.

  • For alerts that come to Alertflex collector, a filtering policy includes severity translation.
    "severity": {
    "threshold": 1,
    "level0": 2,
    "level1": 4,
    "level2": 10

For example, the Wazuh/OSSEC rules classify events to multiple levels, from the lowest (00) to the maximum level 16. If Wazuh event-level less then 2, Altprobe translates it to severity level 0. If Wazuh event-level equals or more then 10, Altprobe translates it to severity level 3. Parameter threshold indicates the level severity that use as a threshold to pass alerts to system or drop of alert.

  • For alerts that come directly to Alertflex central node, a severity translation can be defined via Alertflex console.


Categorization is one of the important features of Alertflex. Every alert in Alertflex has one or more categories. According to a category it possible to make visualization of a certain type of alerts, to do correlation or define alerts conditions in response profile. Normally, an alert comes to Alertflex with already define categories, if the system recognizes category as a new, it will automatically be added to the system database. Users can manually create a new category and assign this category to alert via filtering policy or response profile. To create a new category, open in Alertflex console the web-form CREATE CATEGORY


For alerts visualization and response profiles, Alertflex uses a group of categories - Categories profile. For example, if a user wants to show in search web-form only alerts that belong to certain types of categories for HIDS and NIDS. It allows correlating alerts from HIDS/NIDS and avoids noise from other events. To create a new categories profile, open in Alertflex console the web-form CREATE CATEGORIES PROFILE



  • Categories profile can be created only for one selected type of source: Misc, Modsecurity, Suricata, Wazuh, etc.
  • Above, in web-form, symbol * means all categories.


Alertflex implements incident response profiles that automatically apply for all new alerts. In case, parameters of alert matching to the predefined criteria of the profile, Alertflex performs the action indicated in the profile:

  • Sends of E-mail, Slack or Twilio SMS notifications to a group of users
  • Automatically sends alert to external incident management platforms
  • Executes playbooks

Selection of response profile for a certain alert is based on the next 3 main criteria:

  • Field action of alert has a name of response profile (the filter policy can modify this field in the collector).
  • Response profile based on category profile
  • Response profile based on alert ID for the specific source

Also, the response profile can include additional selection criteria, see in Alertflex console web-form CREATE RESPONSE




The dashboard is a first web-form, which an user will see after login to the Alertflex console.


The top of the dashboard shows the total amount of alerts according to the statuses in the datastore of Alertflex. Other charts of the dashboard show statistics within the time window (interval 6h on the example above). User can change time window via web-form CHANGE PROFILE FOR USER



For analysis specific alert, History web-form is used. Through this web-form, the user can see full information about alert (raw event in JSON format, IDS rule for the alert) and create an incident for the alert.


If the alert has a status incident, the user additionally can perform the next actions for the alert:

  • change the state of incident
  • view history of the incident
  • manually send notifications about the selected incident to a group of users via SMS, Slack, email
  • create a new incident in external Security Incident Response platforms (JIRA or TheHive) via REST API.

Common statistics about incidents, the user can see in Incidents web-form.