A. Requirements definition

The Academic CSIRT in Ecuador is responsible for reporting computer incidents that the universities network record and detect, and for counting with a vulnerability review service. Within this service, several points have been established such as frequent reviews of the institutions public networks, revisions of configuration files of routers and firewalls, configuration review, updates and security implemented in Linux and Windows servers, and policy compliance in database systems, servers, and routers, among others ^[7]. However, an effective automatic solution to detect and classify malicious events is still missing, due to the high volume of such events. For the CSIRT, it has been fundamental that its members have a tool that allows analyzing effectively the traffic that their network tracks, accomplishing quick decisions towards malicious events.

B. Evaluation of the traffic analysis tools

In this section, we will evaluate the Snort and PVS tools. Snort is an open source intruder detection and prevention system capable of real-time traffic analysis ^[8]. PVS is a product of the Tenable Network Security Company, which stands out for analyzing all the traffic transmitted within a network. PVS generates two files: the first intended to monitor real-time vulnerabilities, and the second focused on monitoring the Web and FTP activities ^[9]. We determined that PVS does not act as an IPS, meaning that it simply verifies the traffic that flows through the network, with no activity on the circulating packages.

To conduct an unbiased comparison, within similar conditions, we used data sets from the DARPA Intrusion, detection, and evaluation group at MIT Lincoln laboratory ^[10]. We analyzed the data in the alert file and the logs generated by Snort, as well as the real-time file and reports generated by the PVS. Based on this analysis we compared the results shown in Table 1.

Table 1 Comparative analysis between snort and PVS 

Table 1 documents the specified consumption that the tools registered on a Centos7 distribution with a 64-bit architecture. The data demonstrated that Snort consumes less resources than PVS, mainly because Snort lacks the graphical user interface Web deployed by default in the system. In addition, the analysis in Snort was structured in "rules", in which the parameters were established subject to the packet to be captured. Furthermore, PVS analyzes the "plugin's", which provided a specification to be displayed when they do not capture the packets to be analyzed. Within the assessment, we established that the PVS lists more categories to classify the risk of the raised events in the network than Snort.

With the capture of FTP and HTTP traffic, we identified a clear difference in the volume of analyzed data between the two tools. This occurred because Snort acts with default rules. Therefore, the optimal performance of Snort was just the configuration of the rules with "Ruleset" that appeared from a variety of sources. This evaluation allowed inferring that the tools have not been exclusive, as they complement each other, providing a more forceful protection to the network.

C. Design and implementation of algorithms and the application of business intelligence

Here, we used the phases of the methodology proposed by Ralph Kimball ^[11], diving it into three sections: ^[1] specific software to analyze the benefits; ^[2] database design and structure of ETL; ^[3] specifications of the BI application and development of the product. Below, we further describe the developed process.

The ETL processes for data capture and filtering are fundamental for this study, because they represent the technique that allows organizations to move, reformat, and clean data from multiple sources, using SQL algorithms. ETL allow extracting, analyzing, and interpreting upcoming information. Nonetheless, the data formats may vary among organizations due to their source of origin. Therefore, in an unprecedented way, to homogenize the data from their sources, ETL algorithms have been designed, implemented, and subsequently loaded into a MySQL, DataMart, or Data Warehouse database to submit them to a business process ^[11]. In this study, the information from the Snort and PVS registers was relatively condensed and had no standardized format. However, the created ETL algorithms solved this issue, preventing to overload the database with potential irrelevant information.

We developed three solutions related to the PVS processes, based on vulnerability analysis, real-time activities, and risk filtering. Each solution processes its information from files, since the vulnerabilities have been encountered in an enriched ".XML" (.nessus) ^[12], and both the real-time files and the filtering work in a ".txt" file. We generated a transformation flow for the vulnerabilities, which originated from the PVS system (Fig. 2). Also, we generated flows that support the optimization of the processed packages, avoiding generating redundant or delayed data. Figure 3 illustrates the flow that which handles a "Work" generated by the Pentaho BI data integration system; in this flow, the transformation was executed establishing a parameter of repetition, and highlighting the error notification via e-mail, allowing for a subsequent call to an execution process, which manages to filter the risks according to the established parameters.

FIG. 2 ETL algorithm transformation from a flat text file. 

FIG. 3 A generation algorithm of an information filter with control of possible errors in the transformation. 

Within the vulnerability report, the events transformation flow occurs in real time (Fig. 4). In such programming, a control of the events was established, specifying a classification that was stored in MySQL database. Like the vulnerabilities, the control of the flow transformation was highlighted by a warning via e-mail (Fig. 5).

FIG. 4 A Transformation algorithm due to information extraction from an enriched XML file. 

FIG. 5 A generation algorithm of the data load of any given time, controlling possible errors that may arise during the transformation. 

Snort is a tool with the complementary system Barnyard2, which allows migrating the alerts detected by the IDS to a MySQL database (Fig. 6 and 7). Hence, we adapted the fields to generate a relational model. For filtering, the transformation was based on programming in Pentaho BI (Spoon Data Integration) ^[13a, which is based on the content registered in a file, allowed to catalog the obtained packages with Snort as relevant; this prevented a potential database overload with records that lack interest.

FIG. 6 Snort database diagram with the most significant tables. 

FIG. 7 Transformation algorithm that generates a filter from parameters in a flat file. 

In agreement with Stephen Few ^[14], who defines a Dashboard as a scorecard in which a dense array of information must be demonstrated in a reduced manner, we used the Pentaho BI with the Community Dashboard Framework (CDF) guidelines ^[15]. In this way, to visualize the data collected from the PVS, we developed two control panels: a first panel destined to the events in real time, and a second panel used for the vulnerability analysis. For Snort, we developed a panel that allowed visualizing a matrix with the latest detected events. Such information complements the real-time events registered in the PVS.

Regarding the implementation of the application, we applied Scrum as a methodology to develop agile projects because it is independent of technologies and allows coupling to different programming models, focuses on people, as users and developers have defined roles, provides quick results, considers time management, is iterative, responds to changes, and the client is active ^[16].

We used Node.js, a platform created on Chrome's JavaScript Runtime ^[17] as programming language, since it allows implementing fast and scalable network applications. Node.js uses an event-driven, non-blocking I/O model that performs lightly and efficiently, being suitable for data-intensive applications in real-time.

A. Proof of concept

The environment and the flow where the concept was proven (Fig. 8) are represented by 1) the generation of a request for Dashboard or Access to the Pentaho BI system; 2) the system generating the queries to the MySQL database; 3) the system generating the control panel that will be displayed in case of a Dashboard request, while an access has been requested, depending on the user's profile and taking into account that the Dashboard may be edited; 4) the requested Dashboard being displayed in the BI System; and 5) the BI System allowing impression, as well as submission of the data to Excel, generating a proper record file.

FIG. 8 Experimental diagram of the proof of concept. 

B. Results assessment

The application was verified in a real-time trial period, in which the users were able to browse the entire network. Thus, for example, in the records of the last week of June, we could determine that the day with most events was the 27^th (Fig. 9). Fig. 10 illustrates a variety of events recorded in the trial period. The most common event was the "ET SCAN Potential SSH Scan", which generated multiple connections to the server where the product was previously installed.

FIG. 9 Number of events per day. 

FIG. 10 Type of events and frequency. 

The maximum vulnerability tracking point in the protected network was obtained on day 14 (Fig. 11). Afterwards, the flow became normal, with few days with fewer and others with more vulnerabilities; consequently, we can infer that control actions were taken on the observed vulnerabilities.

During this analysis, the false positives decreased, which implies an improvement in the fulfilment of the Academic CSIRT services. Therefore, the system focused on supporting the Academic CSIRT to improve its services for detecting vulnerabilities and tracking malicious activity on the network; this aims at uprising awareness among members to lead to a more efficient deal with incidents occurring in their network, thus achieving adequate and timely attention to their weaknesses and threats.