====== SIEM monitoring ======

{{indexmenu_n>10}}

<wrap #ks1 />
===== Introduction =====

The acronym **SIEM** stands for <wrap :en>Security Information and Event Management</wrap>. [[https://pandorafms.com/en/it-topics/siem/|SIEM]] describes [[:en:documentation:pandorafms:cybersecurity:40_security_monitoring|security monitoring]] features by collecting, filtering, normalizing, correlating and visualizing security events. It combines security information management (**SIM**) with security event management (**SEM**).

SIEM manages security events, which may come from an ordinary log (e.g. Apache logs), from the log of a specific security tool (logs of a firewall, IDS, honeypot, EDR, et cetera) or enriched events from another tool (another SIEM).

<WRAP center round info 90%>

To take full advantage of all SIEM PFMS features, it is **recommended** to have at least version 783 installed in the [[:en:documentation:pandorafms:monitoring:02_operations|EndPoints]].

</WRAP>

<wrap #ks2 />
===== How it works =====

<WRAP center round info 90%>

**Pandora FMS SIEM** is responsible for processing log entries obtained through [[:en:documentation:pandorafms:monitoring:09_log_monitoring|your collection]], normalizing the data and generating security events based on these entries.

</WRAP>

As with log collection, the **generated SIEM** events are stored in OpenSearch®, so the first requirement to make this monitoring work is to have an [[:en:documentation:pandorafms:technical_annexes:38_opensearch_installation|OpenSearch installation]].

Pandora FMS SIEM generates security events using two components in the server, so events are also generated in two steps:

  * **Data standardization**: All log collection entries are decoded, generating new normalized log entries that are stored temporarily.
  * **Event generation**: Normalized logs are checked for compliance with a set of rules, in which case a SIEM event is generated with all the rule information and the normalized log that generated the event.
Thus the complete flow for SIEM monitoring is:

  * Agents, plugins and other sources of information monitor or generate logs that are sent to the ''dataserver''  or ''syslogserver''.
  * ''dataserver''  and ''syslogserver''  take care of processing these log entries and store them on the OpenSearch server configured for log collection.
  * ''siemserver''  decodes all logs obtained through log collection to generate normalized logs on the OpenSearch server configured for SIEM monitoring. These normalized logs are stored temporarily.
  * ''siemevents''  processes each of the normalized logs and if they meet a set of predefined rules, SIEM events are generated and stored on the OpenSearch server configured for SIEM monitoring.
With the events generated, it is possible to check them for their operation from Pandora FMS Console.

<wrap #ks3 />
===== Console configuration =====

<WRAP center round info 90%>

A specific SIEM license must be installed on the PFMS Server. If [[:en:documentation:pandorafms:command_center:01_introduction|Command Center]] is enabled, Pandora SIEM will only be available in the nodes.

</WRAP>

To use SIEM event monitoring, it must first be activated from the main configuration.

Go to menu <wrap :en>**Management → Settings → System Settings → SIEM → Activate SIEM**</wrap>, fill in the form completely and click <wrap :en>**Update**</wrap> to save the changes.

This will create the necessary templates on the OpenSearch server specified for log normalization and SIEM event generation.

It will also activate this type of monitoring in Pandora FMS servers where ''siemserver''  and ''siemevents''  were started.

<wrap #ks4 />
===== Server configuration =====

To perform SIEM event monitoring, activate ''siemserver''  and ''siemevents''  servers in [[:en:documentation:pandorafms:installation:04_configuration#siemserver|server configuration]].

In order to decode and normalize log collection entries, it will be necessary to have decoding XML files that establish the way to obtain the necessary information in each case (hereinafter, <wrap :en>"decoders"</wrap>). These XML files will be located in the path indicated by the ''siem_decoders''  parameter of the server configuration, by default in:
<file>

/usr/share/pandora_server/util/siem/decoders

</file>

In order to generate SIEM events, it will be necessary to have rules XML files that set the conditions to generate an event based on the information obtained in normalized logs (hereinafter, <wrap :en>"rules"</wrap>). These XML files will be located in the path indicated by the ''siem_events_rules''  parameter of the server configuration, by default in:

<file>
/usr/share/pandora_server/util/siem/rules

</file>

<WRAP center round info 90%>

The XML files of Wazuh® <wrap :en>decoders</wrap> and <wrap :en>rules</wrap> are supported by Pandora FMS SIEM monitoring.

</WRAP>

<wrap #ks5 />
===== Agent configuration =====

Most of the log collection is done through Pandora FMS EndPoints. These agents, both in GNU/Linux® and MS Windows® systems, have specific types of modules to perform this task.

<WRAP center round info 90%>

To take full advantage of all SIEM PFMS features, it is **recommended**  to have at least version 783 installed in the [[:en:documentation:pandorafms:monitoring:02_operations|EndPoints]].

</WRAP>

SIEM monitoring relies heavily on the type of log collected, so it will be necessary to specify ''module_source_type''  in log collection modules to indicate that type.

The type is used by <wrap :en>decoders</wrap> and <wrap :en>rules</wrap>, so the active <wrap :en>decoders</wrap> and <wrap :en>rules</wrap> must be checked to know the type to be indicated in each log.

The most commonly used types of logs are:

  * <wrap :en>syslog</wrap>
  * <wrap :en>ids</wrap>
  * <wrap :en>web-log</wrap>
  * <wrap :en>squid</wrap>
  * <wrap :en>windows</wrap>
  * <wrap :en>host-information</wrap>
  * <wrap :en>ossec</wrap>

<wrap #ks5_1 />
==== Linux® agents ====

Log collection on Linux systems is mainly done by reading log files. This can be achieved by using module configurations with this minimal structure:
<code>

module_begin
module_name <program_name>
module_type log
module_regexp <path_to_log_file>
module_pattern <capture_regexp>
module_source_type <log_type>
module_end

</code>

For example, to collect all access log entries from an Apache server:

<code>
module_begin
module_name apache
module_type log
module_regexp /var/log/httpd/access_log
module_pattern .*
module_source_type web-log
module_end

</code>

Entries collected from a log like the above would be normalized by, among others:

  * <wrap :en> decoders</wrap> such as ''web-accesslog'',
  * ''web-accesslog-ip'' or,
  * ''web-accesslog-domain''.

The decoded logs of such a log could generate events such as (among others):

  * ''Common web attack'',
  * ''XSS (Cross Site Scripting) attempt'' or,
  * ''SQL injection attempt''.

<wrap #ks5_2 />
==== MS Windows® agents ====

Log collection in MS Windows® is mainly done by monitoring system events, although it can also be done by reading log files as in Linux systems.

Using the Windows event system, these logs may be collected by using module configurations with one of these two minimum configurations.

If the events are either <wrap :en>**Application**</wrap>, <wrap :en>**System**</wrap> or <wrap :en>**Security**</wrap>:

<code>
module_begin
module_name <module_name>
module_type log
module_logchannel
module_source <Application|System|Security>
module_source_type <log_type>
module_end

</code>

Or if they are events belonging to a different channel:
<code>

module_begin
module_name <module_name>
module_type log
module_logchannel
module_source <log_channel_path>
module_source_type <log_type>
module_end

</code>

For example, to collect all <wrap :en>**Security**</wrap> and <wrap :en>**Windows Defender**</wrap> event entries:

<code>
module_begin
module_name Windows_LogEvents_System
module_type log
module_logchannel
module_source Security
module_source_type ossec
module_end

module_begin
module_name Windows_LogchannelEvents_WindowsDefender
module_type log
module_logchannel
module_source Microsoft-Windows-Windows Defender/Operational
module_source_type ossec
module_end

</code>

Inputs collected from events such as the above would be normalized by <wrap :en>decoders</wrap> as ''windows_eventchannel''.

The decoded logs of events such as the above could generate events such as, among others:

  * ''Windows error event'',
  * ''Short-time multiple Windows Defender warning events'' or,
  * ''Multiple Windows Defender error events''.

Using log file monitoring, the configuration is identical to that of Linux systems. A minimal configuration like this is required:

<code>
module_begin
module_name <program_name>
module_type log
module_regexp <path_to_log_file>
module_pattern <capture_regexp>
module_source_type <log_type>
module_end

</code>

For example, to collect all log entries of an X server:

<code>
module_begin
module_name xserver
module_type log
module_regexp C:\server\logs\xserver.log
module_pattern .*
module_source_type xserver
module_end

</code>

<wrap #ks6 />
===== SIEM events =====

With SIEM monitoring enabled and configured, a preview of the monitoring status may be accessed in the <wrap :en>**Operation → SIEM → Dashboard**</wrap> menu.

{{  :wiki:siem_dashboard.png  }}

Generated SIEM events can be fuly displayed in menu <wrap :en>**Operation → SIEM → Events**</wrap>.

{{  :wiki:siem_events.png  }}

Each SIEM event will have a window with the event details, showing information of the normalized log and the rule that generated the event.

{{  :wiki:siem_event_details.png  }}

Depending on the <wrap :en>decoders</wrap> that normalized the log, the event will have <wrap :en>**Dynamic fields**</wrap> tab with useful log information.

{{  :wiki:siem_event_fields.png  }}

Depending on the rule that generated the event, there will be **MITRE ATT&CKS®**  and <wrap :en>**SIEM groups**</wrap> tabs with useful information on the impact of the event.

{{  :wiki:siem_mitre_event.png  }}

{{  :wiki:siem_event_groups.png  }}

<WRAP center round info 90%>

The information shown both in the general Dashboard and in the events table may be included in [[:en:documentation:pandorafms:management_and_operation:09_dashboard|Pandora FMS Dashboards]] by means of the included SIEM widgets.

</WRAP>

<wrap #ks7 />
===== Decoders =====

Pandora FMS includes a series of <wrap :en>decoders</wrap> by default for SIEM monitoring, but any administrator may include their own.

<wrap #ks7_1 />
==== Management ====

To include new <wrap :en>decoders</wrap>, first add or edit an XML file in the path indicated to **Pandora FMS server**  in its configuration parameter ''siem_decoders''.

<wrap :en>Decoders</wrap> are loaded into the environment via XML files that **Pandora FMS master**  server reads at each service startup.

Once <wrap :en>decoders</wrap> are loaded, their configuration is stored in the database, and each ''siemserver''  processes them for entries obtained through log collection.

From Pandora FMS Console, it will be possible to view the loaded <wrap :en>decoders</wrap> with their complete configuration from menu <wrap :en>**Operation → SIEM → Decoders**</wrap>.

It is also possible to disable <wrap :en>decoders</wrap> from this view, so that ''siemserver''  does not take them into account when normalizing log entries.

<WRAP center round info 90%>

All <wrap :en>decoders</wrap> are fully loaded at each restart. This means that <wrap :en>decoders</wrap> that could not be read from XML files will not be available (even if they were at some point), and <wrap :en>decoders</wrap> that were disabled from the Console will be re-enabled again (if they exist).

</WRAP>

<wrap #ks7_2 />
==== Syntax ====

<wrap :en>Decoders</wrap> are configured and loaded in Pandora FMS with XML files. These files may have the following valid syntax:

<code xml>
<var name="VarName">VarValue</var>

<decoder name="DecoderName" discard="yes|no">
    <parent>DecoderName</parent>
    <program_name>REGEXP</program_name>
    <type>EventType</type>
    <prematch type="pcre2">REGEXP</prematch>
    <prematch offset="after_parent">REGEXP</prematch>
    <prematch offset="after_prematch">REGEXP</prematch>
    <regex type="pcre2">REGEXP</regex>
    <regex offset="after_parent">REGEXP</regex>
    <regex offset="after_regex">REGEXP</regex>
    <order>Field1, Field2.Sub1, Field2.Sub2</order>
    <json_null_field>string|discard</json_null_field>
</decoder>

</code>

<wrap #ks7_2_1 />
=== var ===

[[#ks7_2|↑Full syntax]]

Used to indicate variables with their values, and use them later in XML (''$VarName'').

<code xml>
<var name="VarName">VarValue</var>

</code>

<wrap #ks7_2_2 />
=== decoder ===

[[#ks7_2|↑Full syntax]]

It is the <wrap :en>decoder</wrap> information, with its name. The XML file itself may contain several.

  * ''name'': It is the name of the <wrap :en>decoder</wrap>. Several <wrap :en>decoders</wrap> may have the same name, and they are all evaluated.
  * ''discard'': With a ''yes''  or ''no''  value, it allows to discard logs from the <wrap :en>decoder</wrap> evaluation if they match this one. <wrap :en>Decoders</wrap> with ''discard="yes"''  are evaluated before the rest (as long as they do not have a parent <wrap :en>decoder</wrap>).
<code xml>
<decoder name="DecoderName" discard="yes|no">
  …
  …
  …
</decoder>

</code>

<wrap #ks7_2_3 />
=== parent ===

[[#ks7_2|↑Full syntax]]

It specifies the name of the parent <wrap :en>decoder</wrap> to generate a hierarchical structure.

<code xml>
    <parent>DecoderName</parent>

</code>

<wrap #ks7_2_4 />
=== program_name ===

[[#ks7_2|↑Full syntax]]

The name of the program to be found in the log headers or in the ''source_id''  of the log.

  * ''type'': It allows you to specify the type of regular expression. If not specified, [[#ks10_1|OS Regex]] is used.
<code xml>
    <program_name>REGEXP</program_name>

</code>

As the case may be, it is specified for [[#ks10_2|PCRE2]]:

<code xml>
    <program_name type="pcre2">REGEXP</program_name>

</code>

<wrap #ks7_2_5 />
=== type ===

[[#ks7_2|↑Full syntax]]

The type of logs for which the <wrap :en>decoder</wrap> will be compared. It must match the log ''type''.

<code xml>
    <type>EventType</type>

</code>

<wrap #ks7_2_6 />
=== prematch ===

[[#ks7_2|↑Full syntax]]

If the contents of the log match this, it generates a normalized log.

  * ''type'': It allows you to specify the type of regular expression. If not specified, [[#ks10_1|OS Regex]] is used.
  * See [[#ks7_2_10|offset]].

<code xml>
    <prematch type="pcre2">REGEXP</prematch>
    <prematch offset="after_parent">REGEXP</prematch>
    <prematch offset="after_prematch">REGEXP</prematch>

</code>

<wrap #ks7_2_7 />
=== regex ===

[[#ks7_2|↑Full syntax]]

Groups captured with this regular expression are normalized information for the log.

  * ''type'': It alows you to specify the type of regular expression. If not specified, [[#ks10_1|OS Regex]] is used.
  * See [[#ks7_2_10|offset]].

<code xml>
    <regex type="pcre2">REGEXP</regex>
    <regex offset="after_parent">REGEXP</regex>
    <regex offset="after_regex">REGEXP</regex>

</code>

<wrap #ks7_2_8 />
=== order ===

[[#ks7_2|↑Full syntax]]

Values captured by [[#ks7_2_7|regex]] are stored in these field names, sorted by capture groups.

<code xml>
    <order>Field1, Field2.Sub1, Field2.Sub2</order>

</code>

<wrap #ks7_2_9 />
=== json_null_field ===

[[#ks7_2|↑Full syntax]]

Null values of the capture groups will be stored as empty strings or discarded.

<code xml>
    <json_null_field>string|discard</json_null_field>

</code>

<wrap #ks7_2_10 />
=== offset ===

[[#ks7_2|↑Full syntax]]

It is used to indicate the order in which checks are performed and to discard from the log content for the following checks the text that matches the regular expression: ''after_parent'', ''after_regex'', ''after_prematch''. For example:

<code xml>
<decoder name="my_decoder">
  <prematch type="pcre2">^\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d </prematch>
  <regex type="pcre2" offset="after_prematch">(\w):(\d+)</regex>
  <order>srcip,srcport</order>
</decoder>

</code>

It will check that the text in the log matches the regular expression ''^\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d '', will discard that content of the text and when evaluating the ''regex'', it will capture accordingly. In the example, it would remove a date from the text when evaluating to simplify the capture groups.

<wrap #ks8 />
===== Rules =====

Pandora FMS includes a set of default <wrap :en>rules</wrap> for SIEM monitoring, but any administrator may include their own.

<wrap #ks8_1 />
==== Rule management ====

To include new <wrap :en>rules</wrap>, first add or edit an XML file in the path indicated to Pandora FMS server in its configuration parameter ''siem_rules''.

<wrap :en>Rules</wrap> are loaded into the environment by means of XML files that **Pandora FMS master**  server reads at each service start.

Once <wrap :en>rules</wrap> are loaded, their configuration is stored in the database, and each ''siemevents''  server processes them for normalized entries in SIEM monitoring.

From Pandora FMS console, it will be possible to see loaded <wrap :en>rules</wrap> with their full configuration from menu <wrap :en>**Operation → SIEM → Rules**</wrap>.

It is also possible to disable <wrap :en>rules</wrap> from this view, so that ''siemevents''  does not take them into account when processing normalized logs.

<WRAP center round info 90%>

All <wrap :en>rules</wrap> are fully loaded at each restart. This means that the <wrap :en>rules</wrap> that could not be read from the XML files will not be available (even if they were at some point). Unlike <wrap :en>decoders</wrap>, <wrap :en>rules</wrap> have an ID that allows to keep them disabled at each reload.

</WRAP>

<wrap :en>Rules</wrap> that could not be read from XML files will be marked in the Console as "not active" and will not be taken into account when generating SIEM events. <wrap :en>Rules</wrap> that were manually disabled by an administrator will not be taken into account either. Therefore, for <wrap :en>rules</wrap> to be evaluated, they must be active and enabled.

<WRAP center round info 90%>

Once rules are active and enabled, if one rule needs to depend on the evaluation and result of another, **the first rule must have a lower numerical identifier than the second**  (i.e., they are executed in ascending numerical order, see [[#ks9_1|corresponding case study]]).

</WRAP>

<wrap #ks8_2 />
==== Sorting ====

<wrap :en>//Rules//</wrap> are classified in several levels, ranging from the lowest (''0'') to the highest (''15''). The following table describes each level, providing information on the severity of each event generated by SIEM monitoring.

^Level  ^Title  ^Description|
|0  |Ignored.  |No action was taken. Used to avoid false positives. These rules are scanned before all other rules, including events with no security relevance, and do not appear in the security events panel.|
|2  |Notification of low system priority.  |System notifications or status messages. They have no security relevance and do not appear in the security event panel.|
|3  |Successful/authorized events.  |These include successful login attempts, events allowed by the firewall, and so on.|
|4  |Low system priority error.  |Errors related to bad configurations or unused devices/applications. These have no security relevance and are usually caused by default installations or software testing.|
|5  |User-generated error.  |These include forgotten passwords, denied actions, and so on. By themselves, they have no security relevance.|
|6  |Low relevance attack.  |These indicate a worm or virus that has no effect on the system (such as code red for Apache servers, etc.). This also includes frequent <wrap :en>Intrusion Detection System</wrap> (**IDS**) events and frequent errors.|
|7  |Coincidence of "bad words".  |These include words such as "bad", "error", etc. Most of these events are not classified and may have some relevance from a security point of view.|
|8  |First time seen.  |Include events seen for the first time. The first time an **IDS** event is triggered or the first time a user logs in. It also includes security-relevant actions, such as the activation of a sniffer or similar activities.|
|9  |Invalid source error.  |It includes attempts to log in as an unknown user or from an invalid source. It may have security relevance (especially if repeated). This also includes errors related to the "admin" account (root).|
|10  |Multiple user-generated errors.  |These include multiple incorrect passwords, multiple failed logins, etc. These may indicate an attack or just signal that a user forgot their credentials.|
|11  |Integrity check warning.  |These include messages about binary modification or the presence of rootkits (by Rootcheck). These may indicate a successful attack. They also include **IDS** events that will be ignored (large number of repetitions).|
|12  |Event of high importance.  |These include error or warning messages from the system, kernel, and so on. These may indicate an attack against a specific application.|
|13  |Unusual error (high importance).  |It matches a common attack pattern most of the time.|
|14  |Security event of high importance.  |It is most often triggered by correlation and indicates an attack.|
|15  |Severe attack.  |There is no possibility of false positives. Immediate attention is necessary.|

Based on these levels, events will have a specific severity that will be displayed on the console:

  * <wrap :en>**Informational**</wrap>: Levels from 0 to 6.
  * <wrap :en>**Normal**</wrap>: Levels from 7 to 8.
  * <wrap :en>**Warning**</wrap>: Levels from 9 to 11.
  * <wrap :en>**Critical**</wrap>: Levels from 12 to 15.

<wrap #ks8_3 />
==== Syntax ====

[[#ks8_3_1|Detailed syntax elements]]

<code xml>
<var name="VarName">VarValue</var>

<group name="GROUP1,GROUP2,">
    <rule id="N" level="N" frequency="N" timeframe="N" ignore="N" overwrite="yes|no">
        <if_matched_sid>N</if_matched_sid>
        <if_matched_group>GROUP</if_matched_group>
        <same_id />
        <different_id />
        <same_field>Field1</same_field>
        <same_field>Field2.Sub1</same_field>
        <different_field>Field1</different_field>
        <different_field>Field2.Sub1</different_field>
        <description>TEXT</description>
        <match type="pcre2">RREGEXP</match>
        <match negate="yes|no">RREGEXP</match>
        <regex type="pcre2">RREGEXP</regex>
        <regex negate="yes|no">RREGEXP</regex>
        <decoded_as>DecoderName</decoded_as>
        <category>EventType</category>
        <field name="Field1">REGEXP</field>
        <field name="Field2.Sub1" negate="yes|no">REGEXP</field>
        <program_name negate="yes|no">REGEXP</program_name>
        <time>TIME-RANGE</time>
        <weekday>DAYS</weekday>
        <if_sid>PARENT1, PARENT2</if_sid>
        <if_group>GROUP</if_group>
        <if_level>N</if_level>
        <info type="text|link|cve">TEXT|LINK|CVE</info>
        <group>GROUP1,GROUP2,</group>
        <mitre>
            <id>MITRE_ID</id>
            <id>MITRE_ID</id>
        </mitre>
    </rule>
</group>


</code>

See also [[#ks9|Case study]].

<wrap #ks8_3_1 />
=== var ===

[[#ks8_3|↑Complete syntax]].

<code xml>
<var name="VarName">VarValue</var>

</code>

Used to indicate variables with their values, and use them later in XML (''$VarName'').

<wrap #ks8_3_2 />
=== group ===

[[#ks8_3|↑Complete syntax]].

<code xml>
<group name="GROUP1,GROUP2,">
…
</group>

</code>

It allows [[#rule|rule]] grouping. It is also used for conditions of the same rules.

<wrap #ks8_3_3 />
=== rule ===

[[#ks8_3|↑Complete syntax]].

<code xml>
    <rule id="N" level="N" frequency="N" timeframe="N" ignore="N" overwrite="yes|no">
    …
    </rule>

</code>

It is the information in the rule:

  - ''id'': Rule identifier. It must be unique (unless another rule is overwritten).
  - ''level'': Level of the event when generated (''0''  to ''15''). Rules with level ''0''  do not generate an event.
  - ''frequency'': Times that a concurrence must take place to generate an event. Rule frequency is checked for logs of the agent itself, not for any log.
  - ''timeframe'': Time window in which concurrences must be given (seconds).
  - ''ignore'': This rule restarts your ''frequency''  counters after these seconds.
  - ''overwrite'': With ''yes''  or ''no''  values, it allows to overwrite the configuration of a rule with the same ID. If together with ''overwrite="yes"''  the rule has ''level="0"'', it is evaluated before any other and in case of a log match, it discards the evaluation of the rest of the rules for that log.
<wrap #ks8_3_4 />
=== if_matched_sid ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <if_matched_sid>N</if_matched_sid>

</code>

The rule is satisfied if another [[#rule|rule]] with the indicated ID triggered an alert the times indicated by ''frequency''  within the ''timeframe''  time.

<wrap #ks8_3_5 />
=== if_matched_group ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <if_matched_group>GROUP</if_matched_group>

</code>

Like ''[[#if_matched_sid|if_matched_sid]]'' but for groups.

<wrap #ks8_3_6 />
=== same_id ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <same_id />
</code>

Concurrences with the same ID must be given.

<wrap #ks8_3_7 />
=== different_id ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <different_id />
</code>

Concurrences with different IDs must be given.

<wrap #ks8_3_8 />
=== same_field ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <same_field>Field1</same_field>
        <same_field>Field2.Sub1</same_field>

</code>

Concurrences with the same values in the field must take place.

<wrap #ks8_3_9 />
=== different_field ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <different_field>Field1</different_field>
        <different_field>Field2.Sub1</different_field>

</code>

Concurrences with different values in the field must take place.

<wrap #ks8_3_10 />
=== description ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <description>TEXT</description>

</code>

The text for the event to be generated.((Variables can be used in the description and in ''info'' with the values of the custom fields, e.g.: ''$(Field1)'', ''$(Field2.Sub1)'', ''$(Field2.Sub2)''.))

<wrap #ks8_3_11 />
=== match ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <match type="pcre2">RREGEXP</match>
        <match negate="yes|no">RREGEXP</match>

</code>

If the contents of the log match this, it generates a SIEM event.

  - ''type'': It allows you to specify the type of regular expression. If not specified, [[#ks10_1|OS Regex]] is used.
  - ''negate'': With a ''yes''  value you may deny the match.

<wrap #ks8_3_12 />
=== regex ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <regex type="pcre2">RREGEXP</regex>
        <regex negate="yes|no">RREGEXP</regex>

</code>

Same as "[[#match|match]]".

  - ''type'': It allows you to specify the type of regular expression. If not specified, [[#ks10_1|OS Regex]] is used.
  - ''negate'': With a ''yes''  value you may deny the regular expression.
<wrap #ks8_3_13 />
=== decoded_as ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <decoded_as>DecoderName</decoded_as>

</code>

The rule is satisfied if the log was decoded by the indicated <wrap :en>decoder</wrap>.

<wrap #ks8_3_14 />
=== category ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <category>EventType</category>

</code>

The rule is satisfied if the type of the <wrap :en>decoder</wrap> matches.

<wrap #ks8_3_15 />
=== field ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <field name="Field1">REGEXP</field>
        <field name="Field2.Sub1" negate="yes|no">REGEXP</field>

</code>

If the indicated field matches the value, it complies with the rule.

  - ''negate'': With a ''yes''  value, it allows to deny the match with the field.
<wrap #ks8_3_16 />
=== program_name ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <program_name negate="yes|no">REGEXP</program_name>

</code>

If the source of the log matches, the rule is met.

  - ''negate'': With a ''yes''  value, it allows to deny matches with the source log.
<wrap #ks8_3_17 />
=== time ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <time>TIME-RANGE</time>

</code>

If the event is generated in the indicated time range, the rule matches.

<wrap #ks8_3_18 />
=== weekday ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <weekday>DAYS</weekday>

</code>

If the event is generated the days the rule complies with (''monday - sunday'', ''weekdays'', ''weekends'').

<wrap #ks8_3_19 />
=== if_sid ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <if_sid>PARENT1, PARENT2</if_sid>

</code>

The rule is met if any of the parent rules are met.

<wrap #ks8_3_20 />
=== if_group ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <if_group>GROUP</if_group>

</code>

The rule is met if the log meets any other rule in the specified group.

<wrap #ks8_3_21 />
=== if_level ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <if_level>N</if_level>

</code>

The rule is met if another rule with the same level has been met.

<wrap #ks8_3_22 />
=== info ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <info type="text|link|cve">TEXT|LINK|CVE</info>

</code>

Additional information for the generated event.((Variables can be used in the description and in ''info'' with the values of the custom fields, e.g.: ''$(Field1)'', ''$(Field2.Sub1)'', ''$(Field2.Sub2)''.))

<wrap #ks8_3_23 />
=== group ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <group>GROUP1,GROUP2,</group>

</code>

List of rule groups.

<wrap #ks8_3_24 />
=== mitre ===

[[#ks8_3|↑Complete syntax]].

<code xml>
        <mitre>
            <id>MITRE_ID</id>
            <id>MITRE_ID</id>
        </mitre>

</code>

List of the MITRE IDs of the rule.

<wrap #ks9 />
===== Case study =====

The following code describes a rule for PHP-related [[:en:documentation:pandorafms:cybersecurity:09_selinux_configuration|SELinux]] logs. This rule creates events for any attempt to connect to ports other than the usual ones on a web server.

<code xml>
<rule id="100201" level="6">
        <decoded_as>setroubleshoot_program</decoded_as>
        <match>/usr/sbin/php-fpm</match>
        <field name="object_target" type="pcre2">^(?!.*\b(9200|3306|80|443)$).*$</field>
        <field name="object_target" type="pcre2">^(?!.*(directory|file) (conf|data_in|cron.lock)).*$</field>
        <description>SELinux prevented /usr/sbin/php-fpm execution on: $(action) access on the $(object_target)</description>
        <mitre>
            <id>T1071.002</id>
        </mitre>
        <group>exec,threat,PHP</group>
</rule>

</code>

Thus, connections to ports ''9200'', ''3306'', ''80''  and ''443''  will not create events. **Neither will events of type //directory//  or //file//** .

General [[#ks7|decoder]] decoder used for SELinux:

<code xml>
<decoder name="setroubleshoot">
    <program_name>^setroubleshoot$</program_name>
</decoder>

<decoder name="setroubleshoot_program">
    <parent>setroubleshoot</parent>
    <prematch type="pcre2">(SELinux is preventing|SELinux está negando a)</prematch>
    <regex type="pcre2">(\S+) (?:from|de) (\S+) (?:access on the|el acceso a) (.+?)\. (?:For complete SELinux messages run: sealert -l|Si quiere los mensajes de SELinux completos, ejecute sealert -l) (\S+)$</regex>
    <order>binary,action,object_target,sealert_id</order>
</decoder>

<decoder name="setroubleshoot_program">
    <parent>setroubleshoot</parent>
    <prematch type="pcre2">failed to retrieve rpm info for path</prematch>
    <regex type="pcre2">failed to retrieve rpm info for path (\S+)</regex>
    <order>path</order>
</decoder>

</code>

<wrap #ks9_1 />
==== Rule evaluation order ====

The following case study **with a negative result**  illustrates when a rule "queries" other rules to check whether they found a match and then evaluates the match itself to generate an event.

There is a series of rules used to detect failed logins on a hardware firewall, in order to then create the corresponding alerts:

<code xml>
<rule id="81641" level="1">
    <decoded_as>fortigate-firewall-v6</decoded_as>
    <description>Fortigate v6 messages grouped.</description>
</rule>

</code>

  * ⍐ Rule 81641 matches decoded log to start retrieving data.

----

<code xml>
<rule id="81603" level="0">
    <if_sid>81600,81601,81602,81641</if_sid>
    <description>Fortigate messages grouped.</description>
</rule>

</code>

  * ⍐ Rule ID 81603 in turn depends on several rules, including the previous 81641. Since the latter 81641 is higher than 81603, **81603 is not executed**.

----

<code xml>
<rule id="81614" level="4">
    <if_sid>81603</if_sid>
    <match>ssl-login-fail</match>
    <description>Fortigate: SSL VPN user failed login attempt.</description>
    <group>authentication_failed,
gdpr_IV_32.2,
gdpr_IV_35.7.d,
gpg13_7.1,
hipaa_164.312.b,
invalid_login,
nist_800_53_AC.7,
nist_800_53_AU.14,
pci_dss_10.2.4,
pci_dss_10.2.5,
tsc_CC6.1,
tsc_CC6.8,
tsc_CC7.2,
tsc_CC7.3,</group>
</rule>

</code>

  * ⍐ A rule with ID 100700 checks for a match in a rule with ID 81641, which in turn depends on rule ID 81603 (81614 is higher than 81603, so it is executed).

<WRAP center round info 90%>

The problem in this case study is that 81614 does not return a result to 100700 **because 81603 was not executed due to the numerical order by ID**.

</WRAP>

<wrap #ks10 />
===== Regular expressions =====

Regular expressions are sequences of characters that define a pattern.

There are two types of regular expressions valid for <wrap :en>decoders</wrap> and <wrap :en>rules</wrap>: [[#ks10_1|OS Regex]] and [[#ks10_2|PCRE2]].

<wrap #ks10_1 />
==== OS Regex ====

They are simple regular expressions based on a library made in C language. It is designed to be simple and at the same time support the most common regular expressions.

<wrap #ks10_1_1 />
=== Acceptable expressions ===

^Expression^Valid characters|
|''\w''   |A-Z, a-z, 0-9, '-', '@', '_'|
|''\d''   |0-9|
|''\s''   |Spaces " "|
|''\t''   |Tabulation|
|''\p''   |<nowiki>()*+,-.:;<=>?[]!"'#$%&|{}</nowiki>|
|''\W''   |Anything other than \w|
|''\D''   |Anything other than \d|
|''\S''   |Anything other than \s|
|''\.''   |Anything other|

<wrap #ks10_1_2 />
=== Modifiers ===

^Expression^Behavior|
|''+''   |To match one or more times|
|''*''   |To match zero or more times|

<wrap #ks10_1_3 />
=== Special characters ===

^Expression^Behavior|
|''<nowiki>^</nowiki>''   |To specify the beginning of the text|
|''<nowiki>$</nowiki>''   |To specify the end of the text|
|''<nowiki>|</nowiki>''   |To create a logical pattern "or" among multiple patterns|

<wrap #ks10_1_4 />
=== Escaping characters ===

To use the following characters you must escape them with ''\'':

^  $  ^  (  ^  )  ^  <nowiki>\</nowiki>  ^  <nowiki>|</nowiki>  ^  <  |
|\$  |\(  |\)  |  <nowiki>\</nowiki>|  <nowiki>\|</nowiki>  |\<  |

<wrap #ks10_1_5 />
=== Limitations ===

  * The ''*''  and ''+''  modifiers may only be applied to backslash expressions, not to single characters (e.g. ''\d+''  is supported, ''0+''  is not supported).
  * Alternation cannot be used in a group, e.g. ''(foo|bar)''  is not allowed.
  * Complex backtracking is not supported, e.g., ''\p*\d*\s*\w*:'', it does not match only colon because ''\p*''  consumes the colon.
  * ''.''  matches a literal period, while ''\.''  matches any character.
  * ''\s''  matches only an ASCII space (32), not other blanks such as tabs.
  * There is no syntax to match a caret, asterisk or more literal (although ''\p''  will match an asterisk or more, along with some other characters).

<wrap #ks10_2 />
==== PCRE2 ====

<wrap :en>Perl Compatible Regular Expression</wrap> (**PCRE2**) provides features such as recursive patterns, look-ahead and look-back assertions, non-capture groups, non-voracious quantifiers, extended syntax for characters and character classes, among others.

For more details, see the [[https://www.pcre.org/current/doc/html/pcre2syntax.html|PCRE2 syntax documentation]].

<wrap #ks10_2_1 />
=== Acceptable expressions ===

^Expression^Valid characters|
|''.''   |Any character except new line|
|''\d''   |Any decimal digit, equal to ''[0-9]'' |
|''\D''   |Any character other than a decimal digit, equal to ''[^0-9]'' |
|''\h''   |Any horizontal white space character|
|''\H''   |Any character that is not a horizontal blank space|
|''\s''   |Any white space character, equal to ''[\t\r\n\f]'' |
|''\S''   |Any character that is not a blank space, equal to ''[^\t\r\n\f]'' |
|''\w''   |Any "word" character|
|''\W''   |Any "non-word" character|

<wrap #ks10_2_2 />
=== Modifiers ===

^Expression  ^Behavior|
|''?''   |0 or 1, greedy|
|''?+''   |0 or 1, possessive|
|''??''   |0 or 1, lazy|
|''*''   |0 or more, greedy|
|''*+''   |0 or more, possessive|
|''*?''   |0 or more, lazy|
|''+''   |1 or more, greedy|
|''++''   |1 or more, possessive|
|''+?''   |1 or more, lazy|
|''{n}''   |Exactly n|
|''{n,m}''   |At least n, no more than m, greedy|
|''{n,m}+''   |At least n, no more than m, possessive|
|''{n,m}?''   |At least n, no more than m, lazy|
|''{n,}''   |n or more, greedy|
|''{n,}+''   |n or more, possessive|
|''{n,}?''   |n or more, lazy|

<wrap #ks10_2_3 />
=== Escape characters ===

^Expression  ^Behavior|
|''\f''   |Next page (hexadecimal ''0C'')|
|''\n''   |New line (hexadecimal ''0A'')|
|''\r''   |Carriage return (hexadecimal ''0D'')|
|''\t''   |Tabulation (hexadecimal ''09'')|
|''\0dd''   |Character with octal code ''0dd'' |
|''\o{ddd..}''   |Character with octal code ''ddd..'' |
|''\xhh''   |Character with hexadecimal code ''hh'' |
|''v\x{hhh…}''   |Character with hexadecimal code ''hh..'' |

<wrap #ks11 />
===== SIEM alerts =====

See the topic [[:en:documentation:pandorafms:management_and_operation:01_alerts#ks13|SIEM alert system]].

<wrap #ks12 />
===== SIEM reports =====

See the topic [[:en:documentation:pandorafms:technical_annexes:22_pfms_report_types#ks18|SIEM events reports]].

[[:en:documentation:pandorafms:start|Back to Pandora FMS documentation index]]