*4.2. Causal Relationship Discovery*

In a causal Bayesian network, each arc is interpreted as a direct causal influence between a parent node and a child node relative to the other nodes in the network [32]. Therefore, after aggregation, the relationships between hyper-alerts are created. A directed edge between hyper-alerts A and B depicts that B occurred after A, and the event in A influences the event in B. This paper assumes that the attacker will not return to earlier stages and, thus, will not repeat certain steps. If the attacker was allowed to go back, it would not be possible to determine the probability deterministically. This would mean that there would be no final number of vertices where the attack could end. Therefore, it is expected that the attacker will end somewhere and, thus, will not perform the same stages over and over. Accordingly, a directed edge between A and B *(A -> B)* is constructed if the following criteria are met:

	- The source and destination IP addresses in A and B are the same, or
	- The destination IP address in A is the same as the source IP address in B.

After discovering all causal relationships between the hyper-alerts, the conditional probabilities need to be determined. The probability of *A -> B* or the probability of B under the condition of A will be denoted with the notation *P*(*B*|*A*). However, before that, a correlation matrix showing the frequency of occurrences of the relationship *A -> B* needs to be created. The given matrix is stored in a pandas DataFrame object—correlated\_alerts.

**Algorithm 2** Causal relationship discovery.

```
Input agr_alerts_all
 Output correlated_alerts
procedure CORRELATION
   for each alert a in agr_alerts_all do
       for each alert b in agr_alerts_all do
          if amessage != bmessage and aphase != bphase then
              if a and b in same time window then
                  if asrcIP, adstIP == bsrcIP, bdstIP then
                     if a before b and aphase < bphase then
                         correlated_alerts[a][b] ← correlated_alerts[a][b] + 1
                     else if b before a and bphase < aphase then
                         correlated_alerts[b][a] ← correlated_alerts[b][a] + 1
                     end if
                  else if adstIP == bsrcIP and a before b and aphase < bphase then
                     correlated_alerts[a][b] ← correlated_alerts[a][b] + 1
                  else if bdstIP == asrcIP and b before a and bphase < aphase then
                     correlated_alerts[b][a] ← correlated_alerts[b][a] + 1
                  end if
              end if
          end if
       end for
   end for
end procedure
```
Subsequently, two variables representing causal relationships are defined: *Cor(A,B)*, which refers to the number of all causal relationships between alerts *A -> B*, hence the value in matrix: correlated\_alerts[A][B], and *Cor(A,\*)*, which represents the number of all causal relationships between A and all of the other hyper-alerts, which is the sum of the row A in the correlated\_alerts matrix. Now, the conditional probabilities *P*(*B*|*A*) can be computed as:

$$P(B|A) = \frac{\operatorname{Cor}(A, B)}{\operatorname{Cor}(A\_\prime \* )} \quad . \tag{1}$$

We work with table causal\_relationships, which shows the results of the causal relationship discovery algorithm (Algorithm 2). It contains the following columns:


All the data that we need for the construction of the network are in this table.

#### *4.3. Bayesian Network*

Bayesian networks form an important part of artificial intelligence by combining areas of probability theory and graph theory to solve uncertainty and complexity problems. They are one of the graphical probabilistic models, allowing a compact representation of the probability distribution of the simultaneous occurrence of monitored events [33]. The advantage of Bayesian networks is their relative intuitiveness for humans, since it is easier to understand the direct relationships between events and local probability distributions than the resulting probability distributions of occurrence of multiple events simultaneously. Their name is based on the Bayesian statistics on which they are based, which are based on the so-called Bayes' theorem expressing the change of previous assumptions in the light of new facts.

A Bayesian network (or causal network) is represented as a directed acyclic graph (DAG). Each node in this graph is a variable that has certain states. The directed edges in this graph represent relationships between variables—if there is a directed edge between two variables, then one is dependent on another [34]. If there is no connection between the two nodes, it does not mean that they are completely independent, because they can be connected through other nodes. However, they may become dependent or independent depending on the evidence that is established at other nodes. Nodes and connections build the structure of the Bayesian network, and we call it the structural specification.

This model consists of several parameters. The first one is the prior probability of parent nodes, which are not dependent on any states. Every child node has a conditional probability table (CPT) that states the prior knowledge between the node and its parent. An element of the CPT is defined by [35]:

$$\text{CPT}\_{\text{ij}} = \text{P}(\text{childstate} = \text{j} | \text{parentstate} = \text{i}) \tag{2}$$

Some variables may have specific values that were observed. Let *Y* be the set of observed variables and *Y*<sup>0</sup> the corresponding set of values. Let *X* be the set of variables that are interesting for us. Inference is the process of computing the posterior probability *P*(*X*|*Y* = *Y*0). The posterior probability *P*(*X*|*Y* = *Y*0) is defined by [36]:

$$P(X|Y=Y\_0) = \frac{P(X, Y=Y\_0)}{P(Y=Y\_0)}\tag{3}$$

In this paper, we will only consider a finite set *U* = {*X*1, ..., *Xn*} of discrete random variables where each variable *Xi* may take on values 0 or 1. In our case, these random variables will be aggregated alerts—hyper-alerts. We define each node of the causal network to have a binary state, i.e., 1 or 0. The value of 1 represents the alert in the node being raised, while the value of 0 indicates that it was not. Since the variables are discrete, the conditional probability tables contain the probabilities that a variable will contain one of all possible values for each combination of their parents' values.

#### *4.4. Bayesian Network Construction*

For Bayesian network generation, the causal relationships and conditional probabilities between hyper-alerts are needed. Therefore, the data from the previous subsection that are captured in the causal\_relationships table will be used. The procedure for creating the Bayesian network is shown below. The method for creating the Bayesian network takes three input parameters: (I) agr\_alerts\_all, (II) correlated\_alerts, and (III) causal\_relationships. The output of this process is the Bayesian network of the hyper-alerts. The steps for Bayesian network construction are as follows:

1. Step 1: For each causal relationship between hyper-alerts *xi* and *xj* in the correlated\_alerts table, a directed edge *xi* -> *xj* is generated.

2. Step 2: Each node in the Bayesian network has a conditional probability table (CPT). This table displays the probability of the node given the values of its parent nodes. After all the edges are added to the network in Step 1, a method for generating the conditional probability table of each node was used. This method was introduced by [8]:

$$P(\mathbf{x}\_{j}|Pa(\mathbf{x}\_{j})) = \begin{cases} 0, & \forall \mathbf{x}\_{i} \in Pa(\mathbf{x}\_{j}), \mathbf{x}\_{i} = false \\ P(\underbrace{\bigcup}\_{\mathbf{x}\_{j} = true}, t\_{i}) = 1 - \prod\_{\mathbf{x}\_{j} = true} (1 - P(t\_{i})), & \text{otherwise} \end{cases} \tag{4}$$

In this function, *xi* indicates values of the variables in the parent nodes *Pa*(*xj*) of *xj*. The variable *ti* denotes the transition that changes the state of the network from *xi* to *xj*, where *xi* ∈ *Pa*(*xj*). Using this formula, each field in the conditional probability table in the vertex *xj* is calculated based on the values in the parent nodes. It follows from this procedure that if all of the parent nodes have a value of 0 and, thus, no such alerts have occurred, the child node cannot occur either, and the value in the appropriate field will be 0. As a result of this procedure, the Bayesian network with conditional probability tables conditioned on different states of parents in each node has been constructed.

#### *4.5. Alert Prediction*

Based on the created Bayesian network, we can further calculate the probability of occurrence of a certain alert under the condition of other alerts using Bayesian inference. After an intrusion system generates one or more alerts, the so-called posterior probability, which is the probability of occurrence of every other state, can be computed. In this paper, only the probabilities of the alerts that belong to the third (Attempt) or fourth stage (Malicious) of the proposed model will be computed. Therefore, the most probable endings of the attack can be determined. With this knowledge, the system administrator can make precautions so they can mitigate the risk of a successful cyber attack that would otherwise cause bigger damage.

#### **5. Data Preprocessing and Data Analysis**

#### *5.1. Datataset*

For this paper, we work with the Intrusion Detection Evaluation Dataset (CICIDS2017) [37]. It includes benign and the most common attacks, which match the real-world data in ( pcap format). It also includes the results of the network traffic analysis using the CICFlowMeter with labeled flows based on the timestamp, source, and destination IPs, source and destination ports, protocols, and attack. The data capturing period started at 9 a.m., Monday, 3 July 2017, and ended at 5 p.m. on Friday, 7 July 2017, for a total of five days. Monday only included regular traffic. The implemented attacks include Brute Force FTP, Brute Force SSH, DoS, Heartbleed, Web Attack, Infiltration, Botnet, and DDoS. They were executed in both the morning and afternoon on Tuesday, Wednesday, Thursday, and Friday [38]. We can see all of the implemented attacks for each day of data collection in Table 3.


**Table 3.** Overview of the activities in the dataset by day.

This dataset was processed by the Snort intrusion detection system [39], which raised multiple alerts that matched the described attacks. As will be described later in this work, the alerts were aggregated based on the exact criteria into one hyper-alert. They were afterwards correlated—relationships between Hyper-alerts were established based on some properties. After these methods, a directed weighted graph was made, where vertices are hyper-alerts and the weighted edges are relations between them. This graph will be used as a base graph for the cyber attack prediction method using the discrete model—the Bayesian network.

The alerts generated from Thursday's traffic are used as a demonstration of a specific case. This day included multiple web attacks, such as cross-site scripting and SQL injection. Then, in the afternoon, an infiltration was performed. We can see the detailed description in Table 4.

#### *5.2. Alert Preprocessing*

For alert processing, the intrusion detection system Snort [40] was used. It analyzes the above-mentioned dataset based on two sets of alert rules. It takes a *.pcap* file as an input and resolves it based on the rules defined by the user in the configuration file. The first rule set was created by Hansson [41]. The company Proofpoint provides the second open rule set [42]. Rules from the first rule set are marked as "NF" and rules from the second rule set are marked as "ET". Once an attack or an abnormal situation is identified, an alert will be raised.

Snort [39] is an open-source network intrusion detection system that is capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis and content searching/matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, Common Gateway Interface (CGI) attacks, SMB probes, OS fingerprinting attempts, and much more.


**Table 4.** Description of Thursday's activities in the Intrusion Detection Evaluation Dataset (CICIDS2017).

As mentioned above, the .pcap files from the CICIDS2017 dataset were analyzed by the Snort intrusion detection system. An output that contains raised alerts was generated into a .csv (comma-separated values) file. Data from this file were inserted into pandas DataFrame objects. Existing intrusion detection systems sometimes generate many false alerts. Therefore, we looked at the benign activity in the network from Monday. Data from each day that contained cyber attacks were filtered with benign activity from Monday's data. Thus, they would contain false positives. That being the case, only suspicious, non-normal cyber alerts were analyzed further. Based on the proposed model, which contains four stages, alerts from the intrusion detection system were assigned into various stages. Raised alerts were sorted based on their types to the proposed stages.

#### *5.3. Alert Generation and Preprocessing*

After using the Snort intrusion detection system to analyze these data, the input file in .csv format was created. Next, the data from this file were imported into Python, into the pandas DataFrame data structure. The data were filtered with alerts from Monday so they would not contain any false alerts or false positives. After that, 35 types of alerts remained. As we can see in Table 5, their numbers were very high.

#### *5.4. Alert Aggregation*

Therefore, aggregation must be performed on the data. This will significantly reduce the number of redundant alerts so that they can be further processed. As mentioned, an AgrAlert class object was created for each alert. The time window for aggregation was set to 10 min. The set of rules determined if the alerts would be merged into one. Two alerts had to be in the same time window and have the same message and the same pair of IP addresses. All of the assembled alerts were stored in the agr\_alerts\_all variable. After this procedure, only 203 hyper-alerts remained for further processing. A preview of them can be seen in Table 6.

#### *5.5. Causal Relationship Discovery*

A very important step in creating the Bayesian network is to determine the relationships between hyper-alerts. Therefore, an adjacency matrix correlated\_alerts with frequencies on the edges was calculated based on a set of rules mentioned in the previous section. The value on the edge depicts how many times one alert occurred after another. A graph was later constructed from this matrix. Number one was added to the field in the matrix, and thus, a directed edge was created between the two alerts if the criteria between two alerts were fulfilled. They must have occurred in the same time window, which was set to an hour and a half. There were four rules that needed to be fulfilled. The first one was that the order had to be maintained. The second one said that the pair of IP addresses was the same or the destination IP address of the first alert was the same as the source IP address of the second one. The other two rules are based on the design of the attack model. The edge A -> B—hence, the edge from A to B—was only created if A and B were not in the same phase, and on top of that, the phase of A had to be in a lower phase than the alert B. In consequence, all of the cycles were removed, and a graph with a tree structure could be created. The table of the correlated\_alerts can be seen in Table 7. In this table, we omitted the columns with only zero values (no correlation). The alerts in the columns are marked as follows: A3 - GPL NETBIOS SMB-DS IPCshare access; A12 - NF - Echo Reply Payload - Bigger than 100 bytes; A24 - NF - Bad TLD domain - click DNS query - Check domains; and A34 - NF - Echo Request Payload-Bigger than 100 bytes.



For the construction of Bayesian network, conditional probabilities between adjacent vertices needed to be calculated. Therefore, two variables were computed—Cor(A,\*), which is the number of all alerts originating in A, and Cor(A,B), ergo, the number of times that alert B occurred after alert A. Next, the table of causal\_relationships was created, containing all the information that will be used in Bayesian network creation.



**Table 7.** Table of correlated alerts.


#### *5.6. Bayesian Network Construction*

Since all of the information for making the Bayesian network was obtained, all that is left is to calculate conditional probability tables (CPTs) for each vertex in the graph. The created graph is illustrated in Figure 2. This graph will become the Bayesian network by adding the CPTs. The legend to the graph is shown in Table 8, joining numbers in the graph with alerts (equivalent to ID) and their messages and stages. Stages are numbered as follows: *1—SCAN, 2—DELIVERY, 3—ATTEMPT, 4a—DEPLOY MALWARE, 4b—MALICIOUS TASK*.

All of these alerts were assigned to these stages before. The keyword in the alert message is used to categorize a rule for intrusion detection. For example, most of the alerts that belong to the "Scan" phase contain the keyword "SCAN" in the beginning; therefore, they can be categorized mostly automatically. The alerts that could not be categorized automatically were assigned into stages manually.

Unfortunately, the table shows that no alerts belong to stages 3 (ATTEMPT) and 4a (DEPLOY MALWARE). The fourth phase is present only in 4b (MALICIOUS TASK) because there are no malware execution or distribution actions in this dataset. Due to its nature, there are no attack attempts on the Bayesian network. This is because this dataset was created by collecting and joining simple attacks. Therefore, there is no complex sample of an attack on it. Another reason is that Snort very often detected only an attempt phase, which was not related to other alerts. Therefore, a separate vertex without relationships with others was not added to the graph.

**Figure 2.** The graph that was created.

**Table 8.** Description of alerts.


The computational complexity of creating a Bayesian network is very high. Therefore, the algorithm will store the network's information, such as vertices and conditional probability tables, in the file. The output file is in BIF format, which is a structure that the pgmpy library can work with. We advanced through the vertices in topological order. Topological sorting is a linear ordering of its nodes such that for all directed paths from *x* to *y (x!=y)*, *x* comes before *y* in the ordering. Only the acyclic graph has a topological ordering.

#### **6. Results and Discussion**

In this section, the process of the evaluation of the individual methods will be presented. At first, the idea of this paper came from the research made by Ramaki et al. [8]. However, several problems occurred when we tried to follow the steps they took in their approach. The issues within that paper are presented in this section, as well as the modified approach that was developed in order to avoid those problems.

The authors in the mentioned paper tried to create a Bayesian network to predict cyber attack steps. After preprocessing our data from Snort, a similar method of aggregation was used to reduce the number of alerts. Next, the algorithm for causal relationship discovery was evaluated. It was also inspired by the method in the mentioned paper.

At this point, in their proposed method, a problem arose. The occurrence of cycles in the resulting graph was not mentioned in the given paper. However, we succeeded in solving this problem because the two conditions were stated in the causal relationship discovery phase. The attacker can only move across the stages of the cyber attack.

The creation of these conditions was based on the presented model of attack steps. The first condition resulted in eliminating the double-sided edges between the vertices. For example, many vertices from the SCAN phase would be interconnected. The rule said that there should be no edge between two hyper-alerts belonging to the same phase. The second rule resulted in the overall elimination of cycles. The rule was defined so that an oriented edge can only go from an alert that is in a lower phase to an alert in the higher phase. As a result, there are no cycles or bidirectional edges in the resulting graph and the Bayesian network.

After applying the rules, a Bayesian network was created. The following sections display an example of usage of the methods presented in the previous section. The data from Thursday were used to introduce the results of the individual implemented methods. This approach aims to create a Bayesian network designed to predict cyber attacks. The data from this day are described in detail. After that, the aggregation, causal relationship discovery, and Bayesian network construction methods are shown, along with other auxiliary methods.

After the Bayesian network was constructed and written into a file, the last step of the algorithm followed. The Python library pgmpy was used to load the network from the file with BIF format. After that, the Bayesian inference could finally be calculated, and the probabilities of attack steps could be computed. Our Bayesian network tells us how likely it is that an alert from the final stages will occur if the occurrence of an alert from the first phase, i.e., the scanning phase, has been detected. The results are presented in Table 9. In our case, there are two alerts in the Bayesian network belonging to the final phase. These two belong to phase number 4b, which symbolizes some malicious tasks.

The first of these alerts that we can see in the graph under ID - A3 is *GPL NETBIOS SMB-DS IPC\$ share access*. This alert symbolizes the establishment of a connection using the samba protocol. It is meant to detect share access from outside the network. In this case, for example, it may be an EternalBlue infection. This exploit uses a vulnerability in Microsoft's implementation of the SMB (Server Message Block) protocol for remote code execution. However, this type of network activity is often a false positive case. It can be a null session attack on samba functionality, which enables anonymous access to hidden administrative shares on a system. On the other hand, it may be legitimate network traffic; for example, traffic to a domain controller. This alert emerges if the rule defined in the Snort detection system is fulfilled.


**Table 9.** The probability of reaching the final stage provided that specific stages occur.

The second alert that belongs to the final phase is *NF - Bad TLD domain - click DNS query - Check domains*. It can be recognized under ID - A24 in the graph. This means that the device has accessed a domain whose TLD is marked as malicious. A top-level domain can be lablled as bad when there were some indications that it was tied to spam or malware dissemination. Websites using the new top-level domains, such as .men, .work, or .click, are some of the riskiest. The rule that was made for this detection is presented next.

The mentioned alerts and all others emerged from the rules defined in Snort IDS. As was mentioned before, two sets of rules were used—NF and ET.

Next, the types of paths in the graph will be described based on a certain grouping of alerts. Based on the groups of alerts from the first phase according to the type of attack, paths were created in the graph. Their probabilities were calculated using the Bayesian network. Three groups of alerts belonging to the SCAN phase were created.

#### *6.1. SCAN Suspicious Inbound to SQL*

The first group of alerts contains all of the SQL-related alerts. All of them cohere with SQL port scans. The alerts belonging to this group are:


All of the alerts can proceed into both of the second-stage alerts. Alerts in this phase show that a payload of at least 100 bytes has been transmitted into and out of the network:


From this point, the attack can end in either one of the final stages. If the attack's path contained an alert with number 12, it will certainly end in an alert with number 3. If the path went through alert 34, the attack can end in any of the final stages:


Table 10 shows the probabilities of occurrence of final stages based on some of the paths in the graph that contain the first and the second stages.

**Table 10.** Probabilities of paths including alerts from the group SCAN Suspicious inbound to SQL.


After summarizing the results of these calculations, we get clear paths and ends of probable attacks. In the first phase, the SQL service (ports 3306,5432,1521,1433) is scanned from the external network. Subsequently, the payload (>100 bytes) is downloaded or sent. Next, the malicious activity has been executed—access from the external network to the samba protocol or demand for a bad TLD domain (e.g., .tk, .fit, or .rest [43]).

#### *6.2. SCAN 1*

The second group contains alerts that did not connect to all of the subsequent stages. All of the alerts only continued into one of the second-stage alerts. The contents of this group include:


As mentioned, all of the alerts can only go to a second-stage alert with ID A34. This alert was described in the previous group. The message of this variable is 'NF - Echo Request Payload - Bigger than 100 bytes'.

From this point, the attack can proceed and end in any of the final stages. Both of them have also been described in the previous group's definition. An example of the attack path that contains the first and the second stage and ends in the fourth stage can be seen in Table 11.


**Table 11.** Probabilities of paths including alerts from the group SCAN 1.

From these findings, it is possible to deduce the path by which an attacker can lead to their malicious activity. The first phase is scanning of some device. It can either be an NMAP scan that sets the FIN, PSH, and URG flags in the packet, or an NMAP scan that tries to detect the target operating system. After this, packets with payloads bigger than 100 bytes are downloaded or sent. The attack can end in two ways—connection to the samba protocol from an external network or requesting one of the bad TLD domains.

#### *6.3. SCAN 2*

This group of alerts are connected to every one of the subsequent stages. It contains NMAP scans or VNC scans. This group includes:


As was described before, the attack from this group of alerts can proceed in more than one path. The second stage is the same as that in the SCAN Suspicious inbound to the SQL group. The attack can end in both of the mentioned final stages that were described before. An example of an attack that starts with scanning of the designated ports can be seen in Table 12.

**Table 12.** Probabilities of paths including alerts from the group SCAN 2.


From these data, it was concluded that the attack could proceed as follows. The goal of the first phase of the attack was to scan a wide range of ports to find some open vulnerability. It could be scanning all of the designated ports (0–1024) so the attacker can find out what services run on the device and if any of them are vulnerable. The attacker can also be scanning Virtual Network Computing (VNC) ports, which belong to a graphical desktop sharing system. The second phase of the attack is once again sending or downloading big payloads of data, which is suspicious. The attack could end in any of the final stages. The more probable result is that the attacker found an open, vulnerable Server Message Block (SMB) port and tried to exploit this vulnerability.

Since the dataset was not complex and did not contain a wide range of data, further studies are needed in order to test this approach. A larger dataset with an emphasis on attack stages is needed so the proposed methods can be further verified. In this evaluation, we presented some of the attack paths that are likely to happen in real traffic. From the data that were collected, it was discovered that many of the attackers use malicious domains to execute an attack. It was also concluded that some of the ports, like SMB ports, that are considered vulnerable are very often the target of an attack.

#### **7. Conclusions**

Prompt response to security incidents means minimizing the damage caused by the security incidents to the organization. The main goal of the organization is maximum preparation for handling security incidents, as well as their prevention through proactive activities. The transition from reactive activities to proactive activities is currently a challenge in cybersecurity research.

The attack—or the steps of the attackers—can be divided into several stages. Consequently, one of the ways to move from reactive activities to proactive activities is to identify the initial stages of the attack. To be able to make such an identification, it is necessary to predict the next steps of the attacker, which is called the projection of attacks in the current research.

Within this paper, we focused on the projection of attacks, and for this purpose, we defined four stages of attacks. The aim of the paper was the prediction of the final stages (the third and fourth stages), provided that we knew the first two stages of the attack. For this purpose, we chose Bayesian networks.

The aim was to design a model that, based on the projection of the attack, would identify the early stages of the attack. The proposed model includes not only the aggregation of alerts, but also their correlation. We used the proposed attack model for the prediction itself. As research has shown, the paper [8] on which our research is based and was the inspiration for the use of the Bayesian network does not take into account the situation where an attacker can return within a particular stage. The situation creates a cyclic graph, which creates a problem, since the Bayesian network assumes an acyclic graph as the input. For this reason, it was necessary to add a condition to the model under which the attacker does not return within the individual stages.

We tested the proposed model on the publicly available Intrusion Detection Evaluation Dataset CICIDS2017. In the paper, we showed the real application of the proposed model on a prepared dataset, including the creation of alerts, their aggregation and correlation, and the subsequent detection of early stages based on the attack projection.

This research can be expanded in the future. There are several challenges for future work. One of them is the processing and prediction of events, even if there are cycles in the attack graph. This case is problematic because many computational models that take into account acyclic graphs cannot be used. Therefore, it could be appropriate to try another method. For example, using attack graph modeling or a hidden Markov model would be successful. The second challenge that this research presents is creating a complex and comprehensive dataset. Nowadays, to the best of our knowledge, no suitable datasets have been created that emphasize the attacks. Therefore, it is important to work with a dataset that would contain attacks that cover all detectable stages of an attack.

**Author Contributions:** Conceptualization, M.P., T.B. and P.S.; methodology, M.P. and T.B.; data processing, M.P. and T.B.; results analysis, M.T. and P.S.; writing—original draft preparation, M.P.; writing—review and editing, M.P., P.S. and T.B.; supervision, P.S. All authors have read and agreed to the published version of the manuscript.

**Funding:** This paper is funded by the project VVGS-PF-2019-1062, project VVGS-PF-2020-1427, and the Slovak APVV project under contract No. APVV-17-0561.

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **References**




© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
