![](bg5.png)
event type (e.g., ANY; DS Groups (i.e., Executable
files, Suspicious DNS, Network anomalies); Taxon-
omy (Product Type, Category, Subcategory)), and the
name of the XL-SIEM agent involved.
The following example shows a policy created for
any IP source and destination, any source and desti-
nation port, an event type of DS Groups detected by
any agent:
h
ANY, ANY, ANY, ANY, DSGroups, ANY
i
After this pre-processing and filtering operation,
the normalized events are correlated, using specific
correlation rules. The definition of these latter is a
process that requires (i) the definition of statements
and (ii) the definition of directives. A statement indi-
cates the sources from which the information will be
evaluated. They do not fire an alarm but the gener-
ated output is used by other services. A statement is
composed of a unique name and a value that indicates
the variables and the sources of information. For in-
stance, plugin id=1001 refers to data source SNORT.
Directives contain the pattern used in the evalua-
tion of the rule. They are defined using Event Pro-
cessing Language (EPL). They fire an alarm for every
matching pattern. For every EPL directive, we can
assign a category (e.g., alarm , antivirus, authentica-
tion, application, etc.), a subcategory (e.g., Attacks,
Bruteforce, DoS, Malware, Network, etc.), a reliabil-
ity score (from 1 to 10), and a priority score (from 1
to 5).
A concrete example of a correlation rule, associ-
ated to the attack described in section 4.1, used by the
XL-SIEM engine is shown in Table 1.
Table 1: XL-SIEM Correlation Rule Example.
Name: BruteForce Microsoft SQL Server authen-
tication attack against SRC IP
EPL Statement
Insert into BruteForce Microsoft SQL Server
authentication attempt failed detected select
* from ossimSchema default where (plu-
gin id = 1001) and (plugin sid = 50051 2) and
(dst port=1433)
EPL Directive
Insert into directive sls 1 select * from pattern
[every-distinct(a.src ip, 15 seconds) a = Brute-
Force Microsoft SQL Server authentication
attempt failed detected → ([3] b = BruteForce
Microsoft SQL Server authentication attempt
failed detected ((b.src ip=a.src ip) and
(b.dst ip=a.dst ip)))]
The previous rule is defined to raise an alarm af-
ter 3 failed Microsoft SQL Server authentication at-
tempts. The EPL statement will increase the value of
the related variable from the default OSSIM scheme,
where the plugin id corresponds to Snort (value =
1001), and the plugin sid correspond to a failed Mi-
crosoft SQL Server authentication attempt (value =
50051 2).
The EPL directive shows the correlation rule used
to fire an alarm if there is a match in the pattern de-
fined within the brackets. In this case: every sequence
that considers distinctively the IP source and 15 sec-
onds of timeout will generate an alarm. For this ex-
ample we have defined a failed Microsoft SQL Server
authentication attempt as the event to check, if the de-
fined condition matches (i.e., the IP source and desti-
nation are the same) and the same event occurs more
than 3 times, then we will generate a correlated alarm.
4.3 XL-SIEM Analysis
The XL-SIEM dashboard shows a list of both events
(e.g. Suspicious TCP traffic, Potential SSH Scan at-
tempts) and alarms (e.g., Brute-force attack, Network
Scan). The former should not be considered as real
alarms, they constitute the output produced through
the EPL statements. Then, this output is further an-
alyzed through the EPL directives for raising alarms,
if specific conditions are met, as explained in Section
4.2.
Regarding the alarms, they are triggered from a
correlation rule having Snort and/or Suricata as in-
put devices. Two or more conditions must be met
(e.g., several particular log events in the same time pe-
riod, or an event from a security control that matches
against a particular host’s current condition). We will
focus on an alarm with a high risk level: Brute-force
attack, Microsoft SQL server authentication attack
against 222.186.52.199.
By clicking on the alarm name, we obtained more
information about the events, that triggered such an
alarm. In this case, we identified that four individual
events with the same source and destination IP ad-
dresses within a period of 12 hours have triggered this
alarm. Moreover, by clicking on the tabs ”Source”
and ”Destination”, specific information related to the
source and destination IP addresses, respectively, can
be consulted. For example, the geographic location
of the IP address can be visualized through a map.
For a further analysis, information associated to both
the alarm and each single event, which contributed to
raise the former, can be visualized.
5 CONCLUSION
This paper presents a Cross-Layer Security Informa-
tion and Event Management tool (XL-SIEM) as a se-
Towards an Enhanced Security Data Analytic Platform
457