MSNM-Sensor: An Applied Network Monitoring Tool for Anomaly Detection in Complex Networks and Systems

MSNM-Sensor: An Applied Network Monitoring T ool for Anomaly Detection in Comple x Networks and Systems Roberto Mag ´ an Carri ´ on Dpt. of Computer Engineering Univ ersity of C ´ adiz Network Engineering & Security Group Univ ersity of Granada { roberto.magan@uca.es, rmagan@ugr .es } Jos ´ e Camacho Dpt. of Signal Theory , T elematics & Communications, Network Engineering & Security Group Univ ersity of Granada { josecamacho@ugr .es } Gabril Maci ´ a-Fern ´ andez Dpt. of Signal Theory , T elematics & Communications, Network Engineering & Security Group Univ ersity of Granada { josecamacho@ugr .es } Angel Ru ´ ız-Zafra Dpt. of Computer Engineering Univ ersity of C ´ adiz { angel.ruiz@uca.es } Abstract —T echnology evolv es quickly . Low-cost and ready- to-connect devices are designed to provide new services and applications. Smart grids or smart healthcare systems are some examples of these applications, all of which are in the context of smart cities. In this total-connectivity scenario, some security issues arise since the larger the number of connected de vices is, the greater the surface attack dimension. In this way , new solutions for monitoring and detecting security e vents ar e needed to address new challenges br ought about by this scenario, among others, the large number of devices to monitor , the large amount of data to manage and the real-time requirement to pro vide quick security event detection and, consequently , quick response to attacks. In this work, a practical and ready-to- use tool for monitoring and detecting security events in these en vironments is developed and introduced. The tool is based on the Multivariate Statistical Network Monitoring (MSNM) methodology for monitoring and anomaly detection and we call it MSNM-Sensor . Although it is in its early development stages, experimental results based on the detection of well-known attacks in hierarchical network systems pro ve the suitability of this tool for more complex scenarios, such as those found in smart cities or IoT ecosystems. Index T erms —MSNM, sensor , monitoring, anomaly detection, IDS, security , communication networks, IoT , smart cities I . I N T RO D U C T I O N Sev eral technical reports forecast 30 billion IoT (Internet of Things) devices around the world by 2021 [1] and more than 3 billion M2M (Machine to Machine) connections by 2022 [2]. This scenario enables ne w services and applications for improving people’ s daily life as well as business opportunities. Howe v er , many challenges arise, with security being one of the most important. Underlying systems and communications networks are con- tinually being threatened by attackers, ev en more in these hiper-connected en vironments. For instance, it is worth men- tioning two recent attacks, Dyn (2016) [3], [4] and VPNFilter (2018) [5], where thousands of Internet of Things (IoT) devices were compromised causing, on the one hand, a high economic impact and, on the other hand, and ev en worse, personal costs. The way to monitor and control what is happening in these kinds of scenarios is a great challenge since the attack expo- sure surface grows almost exponentially with the number of devices interconnected. A more challenging issue is to manage the generated data gathered from different information sources such as applications, networking de vices and communications. In this way , ke y aspects such as managing the volume, v eracity or velocity of the data are crucial for achieving quick and efficient detection and reaction against security attacks [6]. Furthermore, these aspects may limit the practical application of the solutions, especially in the described scenario. T o address the previous issues, IDS (Intrusion Detection System) and SIEM (System Information and Event Manage- ment) tools are widely used by the specialized community on ICT (Information and Communication T echnologies) se- curity . IDS systems are commonly categorized as one of two types: 1) Network-based IDSs (NIDSs) and 2) Host- based IDSs (HIDSs). NIDSs monitor network ev ents such as traffic flows or firewall logs, while HIDSs behav e similarly but consider host (endpoint)-related e vents, e.g. , syslog, CPU load, etc. Along with this categorization, we can also discern between Anomaly-based IDSs (AIDSs) and Signature-based IDSs (SIDSs), depending on the detection technique applied. The first one (AIDS) tries to find anomalous patterns in the monitored information, while the second one (SIDS) intends to detect the presence of an attack by comparing the gathered information with previously defined attack signatures. Snort [7] and Zeek (Bro) [8] are some examples of practical and widely used IDS tools. SIEM tools also include monitoring and detection func- tionalities but also provide services for e vent correlation and reporting capabilities, among others. Moreov er , SIEM tools can also handle information gathered from IDS systems as a suitable data source for alerting security events. Splunk [9] and AlientV ault [10] are some examples of practical and widely used SIEM tools. Howe v er , neither IDSs nor SIEM tools can efficiently manage new monitoring and security e vent detection needs arising from new communication and computation paradigms. In this work the MSNM-Sensor (Multiv ariate Statistical Net- work Monitoring Sensor) tool is introduced to address the previous issues. It is based on the MSNM (Multiv ariate Statistical Network Monitoring) approach coined by Camacho et al. [11] and successfully tested afterwards in works [12], [13], [14]. Briefly , MSNM methodology comprises four main steps which are parsing , fusion , detection and diagnosis . All the previous stages has successfully been integrated into the MSNM-Sensor ha ving a useful tool for monitoring and anomaly detection in real-time. Among others characteristics, it is able to manage heterogeneous data sources in real time; reduces the monitoring network traffic without significant impact in the detection performance; is lightweight, scalable, versatile and dynamically adaptable to changes in the network en vironments; keeps pri vac y on communications; provides a friendly interactiv e dashboard and it is an open source project. In order to demonstrate its suitability to be used in complex network en vironments, MSNM-Sensor has been tested to monitor hierarchical networks and systems for detecting well- known attacks like DoS , port scanning and data exfiltration as can be seen in IV section. The paper has been organized as follo ws. Section II describes the fundamentals of MSNM methodology , which supports the core functionality of the sensor . In Section III the components and operation modes of MSNM-Sensor are described. The detection capabilities of the sensor are validated in realistic network architectures through Section IV. Moreover , attacks such as DoS, data exfiltration or port scanning are successfully detected and located in the proposed network architecture. Finally , conclusions and further work are described in Section V. I I . F U N DA M E N TA L S O F M U LT I V A R I AT E S T A T I S T I C A L N E T W O R K M O N I T O R I N G In this section we briefly introduce MSNM, which is the basis of the MSNM-Sensor tool. MSNM relies on PCA (Principal Component Analysis), a main tool for multi variate analysis. PCA has been established as a promising technol- ogy to perform network anomaly detection [15], [16], [17], [18]. Besides, the unsupervised nature of PCA allows to un veil anomalous behavior from unknown attacks which is a desired characteristic in those solutions working in real en vironments. Apart from its unsupervised nature, PCA is a white-box model. In comparison to the bulk of machine learning solutions, PCA models are explainable since trends or relationships in the features and observations of the data, can be easily connected. MSNM has been demonstrated to be a promising methodol- ogy in network anomaly detection through sev eral works [11], [12], [13], [14], [19] offering a high detection performance in this context. Four stages comprise the MSNM methodology . They are: a) parsing , b) fusion , c) detection and d) diagnosis . All of them are introduced in the follo wing and integrated in the MSNM-Sensor tool as can be seen in next section. A. P arsing Information from communication networks usually comes in the shape of huge logs and traffic based files contain- ing heterogeneous information. This makes it impossible to directly use this information as input of detection systems and learning models to identify different kinds of attacks. Howe v er , to overcome this issue, data sources are processed in order to build a more suitable input for automatic detectors or classifiers. In this sense, the application of some feature engineering technique is proposed to build a well-structured input, suitable for monitoring and detection systems in general. Thus, the Feature as a Counter (F aaC) [6] technique is used as a functional solution to the problem of learning from large het- erogeneous datasets. It consists in transforming different data sources (structured or not) of information with features into new variables. The new ones are just counters of the original ones computed in a giv en interval of time. For instance, it could be interesting to count the number of accesses to port 22 in a given time windo w interval, because a high number might mean a brute force SSH attack. The practical implementation of the FaaC approach, named FCParser , is av ailable online for downloading at [20]. B. Fusion In communication networks and systems it is expected to find more than one information data source to be monitored. Apart from the parsing functionality of F aaC, the FCParser tool is also able to fuse dif ferent data sources in a single set of features. For each dif ferent source of data, a set of features (counters) is defined. All the sources under monitoring are appended into a simple data stream to b uild the calibration matrix for the PCA model. For that, each source is sampled with equal sampling rate, then parsed and finally fused into an unique data stream. This procedure is periodically repeated at each sample time. The combination of the parsing and the fusion procedures is specially suited for the subsequent multiv ariate analysis, resulting in high dimensional feature vectors that need to be analyzed with dimension reduction techniques, like PCA. Moreov er , the diagnosis procedure benefits from the definition of a large number of features for a better description of the anomaly taking place. Finally , counters and their correlation are easy to interpret. C. Detection PCA is the core of MSNM. PCA identifies a number of linear combinations of the original v ariables in a data set X 1 , the so-called PCs (Principal Components), containing most of its rele v ant information (variability). This process in volv es a change in variables from the original ones in the X space to those in the PC subspace. If X contains M variables and N observ ations of each v ariable, PCA reduces its dimensions from M v ariables to A PCs by finding the A -dimensional latent subspace of the most variability captured. PCA is described through the following equation: X = T A · P t A + E A (1) where P A is the M × A loading matrix, T A is the N × A score matrix and E A is the N × M residual matrix. The maximum variance directions are obtained from the eigen v ectors of X t · X , and they are ordered as the columns of P A by the explained v ariance. The rows of T A are the projections of the original N observations in the new latent subspace. E A is the matrix that contains the residual error , and it plays a key role in the anomaly detection, as shown later . The projection (score) onto the PCA subspace of a new observation is obtained as follows: t new = x new · P A (2) 1 X contains the data matrix obtained in the previous tw o stages. where x new is a 1 × M vector that represents a ne w object and t new is a 1 × A v ector that represents the projection of the latent subspace, while e new = x new − t new · P t A (3) corresponds to the residuals. In order to detect anomalies in the monitored system Q -st [21] and D -st (also known as T 2 ) [22] statistics are commonly used. Q -st compresses the residuals in each observation, and D -st is computed from the scores. Their v alues for a specific observation can be computed through the following equations: D n = A X a =1  τ an − µ a σ a  2 (4) Q n = M X m =1 ( e nm ) 2 (5) where τ an represents the score of the n -th observ ation of the a -th PC, µ a and σ a stand for the mean and standard deviation for the scores of that PC in the calibration data, respectively , and e nm represents the residual value corresponding to the n -th observation of the m -th variable. W ith both statistics (4) and (5) computed from the cali- bration data X , Upper Control Limits (UCLs), i.e. detection thresholds, can be established with a certain confidence lev el [11], [23]. Subsequently , new data are monitored using these limits, and an anomaly is identified when UCL limits are exceeded by new incoming observations. D. Diagnosis After detecting something anomalous in the system, it is necessary to find out where the ev ent came from and the reason as well. Most often, the diagnosis procedure is manually carried out by a security analyst alerted by the system. The diagnosis procedure could be a tricky and tedious task, due to the large amount of information to analyze. Feature contributions to a giv en anomaly can be a useful tool to iden- tify where the anomalous behavior comes from. Contribution plots or other diagnosis methods like oMED A (observation- based Missing-data method for Exploratory Data Analysis) [24] or Univ ariate Squared (US) [25] can be used to identify the feature contributions. Thus, anomalies are detected in the D -st and/or Q -st statistics, and then the diagnosis is performed with e.g. , oMEDA. For instance, The output of oMED A is a 1 × M vector where each element contains the contribution of the corresponding feature to the anomaly under study . Those contributions with large magnitude, either positiv e or neg ativ e, are considered to be relev ant. I I I . M U L T I V A R I A T E S TA T I S T I C A L N E T W O R K M O N I T O R I N G S E N S O R : M S N M - S E N S O R In the following section, MSNM-Sensor modules are in- troduced and thoroughly explained. In addition to others, like those in charge of inter-sensors communications or information sources management, the most important ones corresponds to the four steps found in MSNM methodology . Apart from that, the principal sensor operations are also described through illustrativ e examples. A. Modules The inv olved MSNM-Sensor functional modules, depicted in Figure 1, are described as follows: 1) IS (Information Source): The IS module handles the data coming from the information sources. T wo types of data sources, according to their location, are considered: • Local (LIS). The information gathered from these data sources is generated by the device where the MSNM- Sensor is deployed. For instance, local information sources can be obtained from firewall log files, NetFlow traffic flows and host-based information ( e.g. , syslog in Linux-based systems), among others. LIS data is processed by the P ARSING & FUSION modules. • Remote (RIS). The incoming data from other MSNM- Sensors are handled as a remote information source. Most of the data from other MSNM-Sensors will be the computed values of the monitoring statistics Q n,m - st and D n,m -st, allowing anomaly detection in complex and hierarchical systems. Ho wev er , an y other information could be obtained from a remote sensor, e.g. , those requested by a security analyst for an anomaly diagnosis. 2) P ARSING & FUSION : As mentioned in Section II parsing and fusion modules do, on one hand, a transformation of LIS data sources (structures or not) into a ne w structured form where new features are counters of the original. On the other hand, in case of considering sev eral LIS data sources, all of them are fused by appending one after another . As a result, we hav e a homogeneous data stream of quantitativ e v alues to be afterwards used in the DETECTION module for anomaly detection. Both processes are carried out by the FCParser [20] which implements the FaaC approach. 3) DETECTION: This module represents the sensor func- tional core for anomaly detection. It provides multiv ariate statistical-based methods and algorithms to compute the mon- itoring statistics Q n,m -st and D n,m -st in real time. This module enables the detection of anomalies in the monitored system when statistics computed from a new observation exceed certain control limits. T wo control limits are calcu- lated: UCLq and UCLd for Q n,m -st and D n,m -st respectively . Detailed information on monitoring statistics and UCL limits construction can be found in [11]. The DETECTION module supports three different func- tions: • Prepr ocessing . The DETECTION module performs data preprocessing for new observations and learning models. The standard normalization is used by default, but addi- tional methods are also av ailable and ready to use. • Modeling . This operation is in charge of the sensor calibration from a set of observ ations that are, ideally , un- der NOCs (Normal Operation Conditions), i.e. , without known anomalies. Currently , the PCA model is used, but other machine-learning-based techniques can be easily integrated [26][27]. • Monitoring . This operation computes the abov e men- tioned statistics for each incoming observation. In addi- tion to the precomputed control limits, the monitoring operation is able to detect anomalous behavior when these limits are exceeded. [Q 1,m+1 ,D 1,m+1 , ... ,Q n,m+1 ,D n,m+1 ] [Q n,m ,D n,m ] S n,m MANA GER IS L R P ARSING DETEC TION FUSION M S N M DIA GNOSIS DR T [C m ] [R m ] [C m+1 ] [R m+1 ] Fig. 1. Functional modules of a generic sensor S n,m . n corresponds to the sensor ID, and m is the hierarchical level ID where the sensor n is deployed. Because of the dynamic nature of information coming from networks and systems, learning models should periodically be re-calibrated or re-trained in order to adapt it to normal changes in the en vironment that avoids high false positiv e rates. Usually , such changes are due to the own cyclo- stationary nature of the information from network commu- nications and systems [28] which are different in volume and variety depending on the hour, day , week, etc. These behavioral patterns are periodically repeated. The EWMA (Exponentially W eighted Mo ving A verage) approach is used to dynamically calibrate the sensors e very 60 minutes [29]. Each sample rate, new UCL limits are also computed. 4) DIA GNOSIS: The diagnosis procedure takes place when an anomaly is detected on the monitored system. It is neces- sary to find out where the e vent came from and the reason as well, to afterwards deploy the adequate response measures to counteract against the attack. How to manage this problem is the duty of the DIA GNOSIS module. The DIAGNOSIS module relies on the use of statisti- cal multiv ariate techniques to determine the source of the anomaly . Currently , the oMED A (observ ation-based Missing- data method for Exploratory Data Analysis) [24] method is implemented, but other methods can be included, for instance, the contribution plots of the diagnosis method proposed in [25]. Although the DIAGNOSIS module solves the anomaly diagnostic by itself, it is done locally , i.e. , in the device where the sensor was deployed. In addition, defining the de vice and data source(s) in volv ed in an anomalous behavior in the whole system under monitoring is not a trivial task. For this reason, we create the DR T (Diagnosis Routing T able), which acts similarly to the well-kno wn routing IP tables b ut adds together the information of local and remote sources. The diagnosis flow and routing procedure are explained in detail in Sections III-B and III-C. 5) COM (COMmunications): The COM module allows each MSNM-Sensor to exchange information. In this way , the COM module handles the exchange of specific messages. The system supports (but is not limited to) two types of messages: data and command. The messages mainly differ in the payload and type. For instance, a data message can include any information required in sensor operations, e .g. , the monitoring statistics. On the other hand, command messages are devised to control these processes. Depicted in Figure 1, two information flows are clearly dif- ferentiated: monitoring and diagnosis. It is worth mentioning that only the first one (monitoring) is currently implemented, while the second one is an ongoing work (see the project in [30]). Howe ver , we decided to mention and describe both of them because the y are complementary . In this way , monitoring information flo w e xchanges data messages containing the computed statistics Q n,m and D n,m , while the diagnosis flow controls the entire diagnostic procedure. In this early stage, there is no specific routing algorithm between sensors. Instead, each sensor must be manually configured to send and receive data to and from others. A self-deployed sensor process will be added in future releases. Both flo ws and the exchanged messages are described in Sections III-B and III-C. 6) MANA GER: As depicted in Figure 1, all modules work together following an ex ecution pipeline and sharing the necessary information. The module in charge of orchestrating and managing the others is the MANA GER. As mentioned above, there are two different information flows: monitoring and diagnosis. The first one (monitoring) in volv es four main modules (IS, P ARSING, FUSION and DETECTION) that should be in v oked sequentially , because the output of each module is the input of the next one. Howe v er , the second flow (diagnosis) inv olves the DIAG- NOSIS module, which is inv oked if a specific message is receiv ed. Finally , MAN A GER handles the orchestration of which MSNM-Sensor module should run and when. A highly detailed description of the module interactions in each sensor is giv en in Section III-B. B. Operations Thus far , the main functional MSNM-Sensor modules have been described. Howe ver , high-le vel operations, including sev eral modules, are devised in accordance with the principal MSNM-Sensor functionalities: monitoring and diagnosis. The diagnosis process is still an ongoing w ork; ho wev er , we decide to briefly describe it for completeness. 1) Monitoring Operation: T o be aware of what is happen- ing in systems or networks, it is important to detect anomalous behaviors (deliberate or not). Ho we ver , this is not a trivial task, since a previous work must be done to select which element and information should be supervised. In this manner, the monitoring flo w and the in volv ed modules of fer a versatile and scalable tool allowing the user to freely select data sources and variables to be monitored. Figure 2 shows a detailed view of module interactions and the exchanged information. In the figure, one can see a hypothetical local data source LI S v with M v variables to monitor a total of N v gathered observations, the latter being split into k batches ( b v 1 , b v 2 , . . . , b v k ). Each batch has j = M v variables and i different numbers of observ ations each. As a result, we are able to 1) process less information, reducing the computation time, which is a key point for real-time applications, and 2) adapt the monitoring time step granularity , 1 2 3 . . . 2 1 V1 1 V21 V12 V13 V1j V22 V23 V2j V i1 V i2 V i3 V ij . . . . . . i j . . . . . . . . . . . . . . . { M v { N v 1 2 3 . . . 2 1 V1 1 V21 V12 V13 V1j V22 V23 V2j V i1 V i2 V i3 V ij . . . . . . i j . . . . . . . . . . . . . . . . . . 1 2 3 . . . 2 1 V1 1 V21 V12 V13 V1j V22 V23 V2j V i1 V i2 V i3 V ij . . . . . . i j . . . . . . . . . . . . . . . { b v1 { b v2 { b vk C1v2 . . . C2v2 C3v2 Czv2 C1v1 . . . C2v1 C3v1 Czv1 1 2 3 z 1 2 3 z C1vk . . . C2vk C3vk Czvk 1 2 3 z P ARSING . . . . . . . . . { C v + + + . . . . . . . . . [Q (n,m) 1 ,D (n,m) 1 ] DETEC TION RIS 1 . . . C [1:z] v1 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Qr1,Dr1 C [1:z] v2 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Qr2,Dr2 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Qrk,Drk [Qrk,Drk] C [1:z] vk RIS 2 RIS r LIS l C [1:p] lk C [1:p] l2 C [1:p] l1 C [1:p] lk C [1:p] l2 C [1:p] l1 [Qr2,Dr2] [Qr1,Dr1] LIS v { [Q (n,m) k ,D (n,m) k ] [Q (n,m) 2 ,D (n,m) 2 ] P ARSING P ARSING P ARSING DETEC TION DETEC TION FUSION Fig. 2. In volved modules and the information exchanged among them for an S n,m monitoring flow . The information comes from different data sources, namely , two local ( LI S v and LI S l ) and one remote ( RI S r ), to be divided into k batches ( b v 1 , b v 2 , . . . , b vk ). LIS sources (raw) are parsed for each batch. The new variables, counters of the original ones, are fused together with the remote ones. All variables together conform the observation to be monitored. After that, the Q n,m and D n,m statistics are computed by the MSNM module. sometimes hardly limited by the monitored data source or the anomaly to be detected. As explained in Section IV, 60 seconds is enough to monitor NetFlow -based data sources in the detection of DoS attacks, for example. For each b v k batch of observations, a new one is generated by parsing and fusing the original information (raw). This task is the duty of the P ARSING & FUSION modules (see Section III-A2). At the time of writing this article, the im- plemented module was the FCParser [20] which implements the F aaC approach, a ne w feature engineering methodology that transforms the original information variable space into a new one where the ne w v ariables ( z ) are counters ( C v ) of the original ones. This smart transformation makes the system highly versatile and scalable, allowing the user to define a large number of dif ferent ne w v ariables from a limited original set. For instance, counting the number of dif ferent destination ports in a certain period of time could be rele v ant for port scanning or port knocking attacks. Although just one data source has been considered so far , additional local (LIS) or remote (RIS) data sources can also be included if needed. Figure 2 shows the procedure to add new data sources. In this case (but not limited to it), there are three data sources in v olved: two local ( LI S v and LI S l ) and one remote ( RI S r ). At each monitoring step, a new fused observation is created. In this way , the extended space will hav e e variables, with e = z + p + 2 , where z is the number of variables (counters) from a batch k of source LI S v ; p is the number of v ariables (counters) from the same batch of source LI S l ; and RI S r has two v ariables as the number of statistics generated by the remote sensor . This observation is the input of the DETECTION module which is in charge of computing the monitoring statistics ( Q ( n,m ) k , D ( n,m ) k ). At this point, the system can detect anomalous behaviors when the control limits are e xceeded. In addition, if this sensor is not the root in the hierarchy , the generated statistics will also be sent to the corresponding remote sensor for hierarchical x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Qrk,Drk C [1:z] vk C [1:p] lk DR T { RIS r 172.X. Y .Z LIS l localhost LIS v localhost C 1 vk . . . . . . C 2 vk C 3 vk C z vk C 1 lk C 2 lk C 3 lk C 4 lk C p lk Qrk Drk C 5 lk May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 iptables.log (LIS v ) oMED A observation Fig. 3. Diagnosis operation steps to determine the origin of an anomaly in the system. In this case, the anomaly comes from a variable ( C 3 v k ) with a high contribution in the observation under inspection. This variable corresponds with a local data source LI S v , which is a firew all log. monitoring and anomaly detection. 2) Diagnosis Operation: As aforementioned, after detect- ing an anomaly in the system, the diagnosis procedure should be launched to determine its origin. Figure 3 depicts the operation steps launched to determine which IS is in volv ed in the anomaly . For instance, we suppose that a security e vent arose from the LI S v local data source that in turn represents an iptables firew all. Once the corresponding observation to be inspected has been retriev ed from the sensor, the oMED A algorithm is launched. This algorithm outputs the contrib ution of each vari- able, where those variables with high v alues (either positi ve or negati ve) must be inspected in detail as they are rele v ant. In this case, the v ariable with a high positiv e v alue is C 3 v k (the one in red in Figure 3), which belongs to the LI S v data source according to the DR T . The DR T structure and role in this operation are described in the next section. T ogether , the timestamp and the observ ation under in ves- tigation allo w the sensor to extract the corresponding piece of raw information to be afterwards analyzed by the security analyst. C. W orking All T ogether: A Hierar c hical Appr oach As aforementioned, a single MSNM-Sensor instance is able to monitor and detect anomalous behaviors from a wide range of heterogeneous local and remote data sources. Howe ver , the really novel idea behind the use of Q ( n,m ) and D ( n,m ) statistics is their capability of maintaining the monitoring and anomaly detection performance when they are included in the hierarchy of comple x network en vironments. This useful characteristic has been demonstrated in work [31]. Although the tool will be tested in Section IV, in a realistic network scenario, an e xample of sev eral MSNM-Sensors co- operating within a hypothetical and common network deploy- ment is described as follows for clarification. Figure 4 sho ws a simple network scenario where several MSNM-Sensors are deployed at hosts and network devices. W e can discern in the figure two in volv ed information flows: the monitoring and diagnosis flows. The former (black dashed lines) transports pairs of monitoring statistics ( [ Q ( n,m ) , D ( n,m ) ] ) coming from lower to higher le vels in the hierarchy . In this synthetic example, sensors S 1 , 3 , · · · , S n, 3 are deployed at hosts in the deepest architecture lev el, sending the generated statistics [ Q (1 , 3) , D (1 , 3) ] , · · · , [ Q ( n, 3) , D ( n, 3) ] to the next closest sensor in the hierarchy . Indeed, they act as remote sources of S 1 , 2 . Now , this sensor aggregates and processes it, giving the [ Q (1 , 2) , D (1 , 2) ] values. Finally , the root sensor ( S 1 , 1 ) gathers the statistical information from its immediately lower levels, processes it and generates the last statistics to be observed for anomaly detection. This final monitoring task is commonly carried out by a security analyst, who determines the presence of an anomaly when certain control limits are exceeded by the statistics [11]. Once the anomaly is detected, a deeper inspection should be done to determine, for example, where the anomaly comes from and the its reason. This is the diagnosis procedure, which is represented in Figure 4 with solid green and dashed bro wn lines, that is, the command and response inv olved actions, respectiv ely . In this example, the anomaly comes from S 1 , 3 , which is in charge of monitoring firewall traffic logs. First, a command message [ C m ] to find the anomaly origin is sent. How this message should be routed across the multilevel scenario is defined in the DR T , which maps RIS and LIS data sources kno wn by each MSNM-Sensor and the observation timestamps. T o determine which data source motiv ates the anomaly at a certain timestamp, a diagnosis algorithm is in vok ed. As mentioned before, oMED A algorithm is currently used, though some other methods could easily be integrated. This procedure is repeated until the data source origin is found. Shortly thereafter, the in v olved piece of information (raw) falling into the observation period of time is returned to the root sensor to be analyzed in detail. A new message called response [ R m ] allows this operation. S 1,3 S n,3 S 1,2 [Q n,3 ,D n,3 ] net B S 1,3 S n,3 S 2,2 [Q 1,3 ,D 1,3 ] [Q n,3 ,D n,3 ] net C [Q 1,3 ,D 1,3 , ... ,Q n,3 ,D n,3 ] [Q 1,3 ,D 1,3 , ... ,Q n,3 , D n,3 ] S 1,1 net A [Q 1,2 ,D 1,2 ] [Q 2,2 ,D 2,2 ] [Q 1,1 ,D 1,1 ] [Q 1,2 , D 1,2 , Q 2,2 , D 2,2 ] [C 1 ] [C 2 ] [C 3 ] [R 1 ] [R 2 ] [R 3 ] DR T DR T DR T [Q 1,3 ,D 1,3 ] 0 10 20 30 40 50 60 70 80 90 Observaciones 0 1 2 3 4 5 Q 1 , 1 0 10 20 30 40 50 60 70 80 90 Observaciones 0 5 10 15 20 25 D 1 , 1 Anomaly May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 May 24 16:48 :31 r oberto -POR TEGE -Z930 k er nel: [ 25088.4 97618] IN= OUT=lo SR C=127. 0.0.1 DST=127.0. 0.1 LEN=5 2 TOS=0x00 P REC=0 x00 T TL=64 ID=708 0 DF PR OTO=T CP SPT =8888 DPT =56694 WINDOW=990 RES=0x0 0 A CK UR GP=0 ipta bles_2505201718 45.log Diag nosi s and infor mat ion r ecovery Moni tori ng a nd detec tion { { { L evel 1 L evel 2 L evel 3 Fig. 4. A hypothetical deployment of se veral MSNM-Sensors (orange boxes) throughout an interconnected system for hierarchical monitoring, anomaly detection (dashed black lines) and diagnosis (solid green and dashed bro wn lines). I V . P R AC T I C A L A P P L I C A T I O N O F M S N M - S E N S O R F O R M O N I T O R I N G A N D A T TAC K D E T E C T I O N I N C O M P L E X N E T W O R K E N V I RO N M E N T S A. Experimental En vir onment T o e valuate the performance of IDS-based systems, ready- to-use datasets are widely used. Consequently , choosing one or another dataset is a very relev ant decision with consid- erable consequences, not only in obtaining results but also in establishing the v alidity of the conclusions the authors claim. In this way , Maci ´ a-Fern ´ andez et al. [28] build a recent and real network dataset that copes with the main drawbacks found in the most commonly used ones in the specialized literature. Ne vertheless, not all of them are valid for use in certain application scenarios, because there are differences between the en vironment where the dataset was b uilt and the one where the IDS solution will be deployed. In this manner , ready-to-use solutions for real-time anomaly detection are recommended. These types of approaches could eliminate the need to use previously gathered datasets, which are, on the other hand, very dif ficult to build. T o validate the monitoring and anomaly detection per- formance of the MSNM-Sensor in complex systems, we spread several sensors over a controlled scenario with vir- tual machines running in a cluster . This scenario has been previously de vised to theoretically prove the hypothesis of the application of MSNM for hierarchical systems [31]. The key characteristics required are introduced in the follo wing section. Interested readers can obtain more details in the mentioned reference. The complete scenario with the dif ferent machines is de- picted in Figure 5. This en vironment simulates a typical net- work architecture of a corporation so we can observe sev eral subnetworks, network de vices and end-devices. For instance, a DMZ is located in the inner network, separated from the outside world (Internet) with a BR (Border Router) and S 1,2 network B (192 .168.1 .0/24 ) S 2,2 S 1,1 network C ( 192.16 8.2.0/ 24) S 3,2 network D (192 .168.3 .0/24 ) [ Q 3 , 2 , D 3 , 2 ] net A network A (172 .16.0. 0/24) - DMZ [ Q 1 , 2 , D 1 , 2 ] [ Q 2 , 2 , D 2 , 2 ] [ Q 1 , 1 , D 1 , 1 ] [ N e t fl o w R 1 ] [ N e t fl o w B R , Q 1 , 2 , D 1 , 2 , Q 2 , 2 , D 2 , 2 , Q 3 , 2 , D 3 , 2 ] [ N e t fl o w R 2 ] [ N e t fl o w R 3 ] R1 [ Q 1 , 1 , D 1 , 1 ] Port Sca nni ng Data Ex fi ltra tion DoS BR R2 R3 web server s web server (DMZ) MSNM-dash boar d attac k er INET Fig. 5. Experimental scenario. Four MSNM-Sensors ( S 1 , 2 , S 2 , 2 , S 2 , 3 , S 1 , 1 ) are deployed at each router . Each sensor monitors a NetFlo w local data source generated from each router , while S 1 , 1 also aggregates all the statistics generated by the lo wer-le vel routers. departmental networks in turn delimited by the corresponding routers (R1, R2, and R3). In this scenario, we hav e two types of network traffic: normal and malicious. Normal traffic comprises all HTTP communications from all departmental hosts requesting HTTP resources allocated at the se veral web servers placed in the Internet and DMZ. As shown in Figure 5, the BR is aware of all the incoming traffic from and outgoing traffic to the Internet. On the other hand, Rx routers, with x = 1 , 2 , 3 , observe the corresponding portion of the previous HTTP traffic, which is generated by the hosts in their networks. Additionally , departmental hosts request HTTP resources to the web server in the DMZ. On the other hand, the malicious traffic is generated from different locations in the predefined architecture, simulating very well-known and state-of-the-art attacks. These are 1) DoS (high and low rate); 2) port scanning, a relev ant step in the recognition phase in a penetration testing procedure; and 3) data exfiltration for pri v acy violation purposes. W e run our scenario during a period of 25 hours. In the first 23.5 hours, only normal traf fic is generated. During the last hour and a half, the attacks previously described are generated sequentially and do not ov erlap in time, with 5 minutes giv en for each one: high-rate DoS, low-rate DoS, scanning attack and data exfiltration. The different routers in the network (R1, R2, R3 and BR) are equipped with NetFlow inspectors that generate NetFlow v5 information. These data are afterwards consumed in real time by the corresponding MSNM-Sensors, which are deployed in the mentioned network devices. These sensors are S 1 , 2 , S 2 , 2 , S 2 , 3 and S 1 , 1 , which are represented by orange- colored boxes in Figure 5. All of them consider only a local data source: the generated information of the corresponding NetFlow inspectors. Ho we ver , only S 1 , 1 is in charge of ag- gregating the monitoring information in the form of statistics coming from the sensors in the network lower le vel. Every minute, a new observation is gathered by each sensor , meaning that two statistics are generated ev ery minute. B. Experimental Results As we stated in pre vious sections, a key characteristic of the MSNM-Sensor is its applicability in real and complex en vironments monitoring a large variety of devices and com- munications. The MSNM-Sensor system is able to detect abnormal behaviors in the whole system considering only a couple of monitoring statistics. 2 Figure 6 shows the Q -st (blue inv erted triangles) and D -st (orange filled circles) statistics e v olution with time obtained from the BR sensor . These kinds of graphics are the so-called monitoring plots. In addition, upper control limits are also shown for the Q -st (UCLq), represented by a green dashed line, and for the D -st (UCLd), represented by a red continuous line. Subfigure 6(a) sho ws the statistics values for the total duration of the experiment, while Subfigure 6(b) shows the last 1.5 hours, when the attacks were launched. In the first subfigure, we can discern between three different intervals. In the first one, we experience a high false positive rate, which is caused by the initial random calibration of the sensor . Each sensor uses the EWMA (Exponentially W eighted Mo ving A verage) approach to dynamically calibrate the sensors every 2 T o reproduce the obtained results, related data and scripts are av ailable at the official GitHub repository . 14:30 15:00 15:30 16:00 16:30 17:00 17:30 18:00 18:30 19:00 19:30 20:00 20:30 21:00 21:30 22:00 22:30 23:00 23:30 00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30 06:00 06:30 07:00 07:30 08:00 08:30 09:00 09:30 10:00 10:30 11:00 11:30 12:00 12:30 13:00 13:30 14:00 14:30 15:00 15:30 Observation time 1 0 2 1 0 9 1 0 1 6 1 0 2 3 1 0 3 0 1 0 3 7 1 0 4 4 1 0 5 1 Value (log) borderRouter Qst Dst UClq UCLd (a) 14:15 14:20 14:25 14:30 14:35 14:40 14:45 14:50 14:55 15:00 15:05 15:10 15:15 15:20 15:25 15:30 15:35 15:40 15:45 Observation time 1 0 3 1 0 1 0 1 0 1 7 1 0 2 4 1 0 3 1 1 0 3 8 1 0 4 5 1 0 5 2 Value (log) borderRouter (attacks) Qst Dst UClq UCLd (b) Fig. 6. Q -st and D -st statistics evolution for the entire experiment (25 hours) (a) and for the attack period (last 1.5 hours) (b). 14:15 14:20 14:25 14:30 14:35 14:40 14:45 14:50 14:55 15:00 15:05 15:10 15:15 15:20 15:25 15:30 15:35 15:40 15:45 Observation time 1 0 0 1 0 4 1 0 8 1 0 1 2 1 0 1 6 1 0 2 0 1 0 2 4 Value (log) routerR1 (attacks) Qst Dst UClq UCLd Fig. 7. Q -st and D -st statistics e volution for the attack time interval in R1. It is clearly shown when the port scanning attack is taking place. 14:10 14:15 14:20 14:25 14:30 14:35 14:40 14:45 14:50 14:55 15:00 15:05 15:10 15:15 15:20 15:25 15:30 15:35 15:40 Observation time 1 0 1 1 0 3 1 0 7 1 0 1 1 1 0 1 5 1 0 1 9 1 0 2 3 Value (log) routerR2 (attacks) Qst Dst UClq UCLd Fig. 8. Q -st and D -st statistics e volution for the attack time interval in R2. It is clearly shown when the data e xfiltration attack is taking place. 60 minutes [29]. The second one co vers almost all the experimental time, where we can see the effecti veness of the dynamic adaptation of the sensor to the en vironment because the computed v alues are belo w the control limits mainly throughout the experimental time. Finally , the third one shows a clear de viation in the normal behavior of the statistics and the system in general. In this time period, the control limits are 14:20 14:25 14:30 14:35 14:40 14:45 14:50 14:55 15:00 15:05 15:10 15:15 15:20 15:25 15:30 15:35 15:40 15:45 15:50 Observation time 1 0 1 1 0 3 1 0 7 1 0 1 1 1 0 1 5 1 0 1 9 1 0 2 3 Value (log) routerR3 (attacks) Qst Dst UClq UCLd Fig. 9. Q -st and D -st statistics e volution for the attack time interval in R3. It is clearly shown when the DoS attacks are taking place. undoubtedly , exceeded indicating that something anomalous is occurring. Apart from the previous global results, it is w orth paying special attention to the attack period. In this way , Subfigure 6(b) sho ws clear deviations of the statistics values when the attacks are taking place. From DoS (high and lo w rate) to data exfiltration, the MSNM-Sensor sensor approach is able to detect anomalous beha viors coming from different parts of the whole systems by taking into account only two simple numerical values. Moreover , we can distinguish where the anomaly is coming from by inspecting similar monitoring graphics, but in this case, they are computed from each of the in volv ed routers. This process can be viewed in Figures 7, 8 and 9 for the sensors deployed at R1, R2 and R3, respectively . For instance, from the inspection of the R3 monitoring graph, we can conclude that the attack originated somewhere in the R3 network, similarly for R1 and R2 for the port scanning and data exfiltration attacks, respectively . Additionally , we can see the dynamic adaptation on the sensor to the changes in the en vironment. It is more evident in the R3 monitoring graphic (see Figure 9), where the UCLq limit adapts its v alue to cov er new trends in Q -st. Although the previous figures are included in the text to enhance the reading, the MSNM-Sensor application comes Fig. 10. MSNM-Sensor dashboard snapshot of the monitoring view . The logical connections of the sensor (orange boxes) are shown in the upper section of the figure, while the monitoring graphs are in the bottom part. with a specific and interacti ve dashboard. Thanks to this dashboard, the security analyst or the application operator can, in real time, access the previous information and the logical connections of the sensors. A snapshot of the monitoring main section of the tool is shown in Figure 10. The upper part sho ws the logical connections created among the sensors. The operator can see the direction o f the monitoring flow . In this specific scenario, it is clearly sho wn ho w the sensors in routers R1, R2 and R3 are configured to send their monitoring information to the BR. In addition, the monitoring graphs will appear in the bottom part by clicking on a specific sensor . Among other actions, the operator can interact with these graphs to pause/play the updating procedure for a better inspection. The dashboard is needed for whatev er monitoring system that allo ws the operator to reduce the response/reaction time when an attack takes place. V . C O N C L U S I O N S & F U T U R E W O R K This work introduces the MSNM-Sensor (Multivariate Sta- tistical Network Monitoring Sensor), a practical and ready-to- use tool for monitoring and detecting security ev ents in com- plex systems and network environments. The MSNM-S relies on the implementation of the MSNM methodology which allows it address new technological challenges arising from all-connected scenarios, e.g . , smart cities and IoT ecosystems, where a large number of de vices share information. Inherited from the MNSM methodology , MSNM-Sensor reduces and efficiently handles the monitoring information, maintaining its detection performance. On the other hand, existing IDS or SIEM solutions consider raw data, thus adding extra monitoring traf fic o verhead. Moreover , MSNM-Sensor inherently adds pri v acy in monitoring communications since no sensible or raw data is sent to the central station just the monitoring statistics instead. The MSNM-Sensor uses lightweight algebraic and statistics operations that allow it to be embedded in less powerful devices, e.g. , wearable devices, en vironmental sensors and IoT devices in general. Last but not least, the MSNM-Sensor operates in real time, and it is adaptable to changes in the en vironment where it is deployed without an y previous training phases. Although the MSNM-Sensor has been tested successfully with promising results in hierarchical network systems and architectures to monitor and detect well-kno wn network at- tacks, the MSNM-Sensor capabilities should be tested in real and complex scenarios, e.g. , IoT ecosystems or those found in smart cities. Finally , the anomaly diagnosis operation is still in de velopment; thus, we will focus our future work on this topic. R E F E R E N C E S [1] A. Nordrum, “Popular internet of things forecast of 50 billion devices by 2020 is outdated. ” [Online; Accessed 30-September-2019] https:// bit.ly/2kVkk9A. [2] Cisco Systems, “Cisco visual networking index: Global mobile data traffic forecast update, 2017-2022 white paper , ” [Online; Accessed 30- September-2019] https://bit.ly/2TY O1DG. [3] ENISA, “ENISA Threat Landscape Report 2017, ” [Online; Ac- cessed 22-September-2019] https://www .enisa.europa.eu/publications/ enisa- threat- landscape- report- 2017. [4] N. Chaabouni, M. Mosbah, A. Zemmari, C. Sauvignac, and P . Faruki, “Network Intrusion Detection for IoT Security Based on Learning T echniques, ” IEEE Communications Surveys Tutorials , vol. 21, no. 3, pp. 2671–2701, 2019. [5] ENISA, “ENISA Threat Landscape Report 2018, ” [Online; Ac- cessed 22-September-2019] https://www .enisa.europa.eu/publications/ enisa- threat- landscape- report- 2018. [6] J. Camacho, G. Maci ´ a-Fern ´ andez, J. D ´ ıaz-V erdejo, and P . Garc ´ ıa- T eodoro, “T ackling the Big Data 4 vs for anomaly detection, ” in 2014 IEEE Conference on Computer Communications W orkshops (INFO- COM WKSHPS) , April 2014, pp. 500–505. [7] Cisco Systems, “Snort IDS, ” [Online; Accessed 30-September-2019] https://www .snort.or g/. [8] I. Johanna Amann, “Zeek (bro) IDS, ” [Online; Accessed 30-September- 2019] https://www .zeek.or g/. [9] Splunk, “Splunk, ” [Online; Accessed 30-September -2019] https://www . splunk.com. [10] A. V ault, “ Alient vault, ” [Online; Accessed 30-September-2019] https: //www .alien v ault.com/. [11] J. Camacho, A. P ´ erez-V illeg as, P . Garc ´ ıa-T eodoro, and G. Maci ´ a- Fern ´ andez, “PCA-based multiv ariate statistical network monitoring for anomaly detection, ” Computers & Security , vol. 59, pp. 118–137, June 2016. [12] J. Camacho, P . Garc ´ ıa-T eodoro, and G. Maci ´ a-Fern ´ andez, “Traf fic Mon- itoring and Diagnosis with Multiv ariate Statistical Network Monitoring: A Case Study, ” in 2017 IEEE Security and Privacy W orkshops (SPW) , May 2017, pp. 241–246. [13] J. Camacho, G. Maci ´ a-Fern ´ andez, N. M. Fuentes-Garc ´ ıa, and E. Sac- centi, “Semi-supervised Multiv ariate Statistical Network Monitoring for Learning Security Threats, ” IEEE T ransactions on Information F or ensics and Security , pp. 1–1, 2019. [14] J. Camacho, J. M. Garc ´ ıa-Gim ´ enez, N. M. Fuentes-Garc ´ ıa, and G. Maci ´ a-Fern ´ andez, “Multiv ariate Big Data Analysis for intrusion detection: 5 steps from the haystack to the needle, ” Computers & Security , vol. 87, pp. 1–11, No vember 2019. [15] A. Kanaoka and E. Okamoto, “Multivariate statistical analysis of network traffic for intrusion detection, ” in 14th International W orkshop on Database and Expert Systems Applications, 2003. Proceedings. , September 2003, pp. 472–476, iSSN: 1529-4188. [16] A. Lakhina, M. Crovella, and C. Diot, “Diagnosing network-wide traffic anomalies, ” in Proceedings of the 2004 confer ence on Applications, technologies, arc hitectur es, and protocols for computer communica- tions , ser . SIGCOMM ’04. Portland, Oregon, USA: Association for Computing Machinery , August 2004, pp. 219–230. [17] C. Calle gari, L. Gazzarrini, S. Giordano, M. Pagano, and T . Pepe, “Improving PCA-based anomaly detection by using multiple time scale analysis and Kullback–Leibler di vergence, ” International Journal of Communication Systems , vol. 27, no. 10, pp. 1731–1751, 2014. [18] A. Delimargas, E. Skev akis, H. Halabian, I. Lambadaris, N. Seddigh, B. Nandy , and R. Makkar, “Evaluating a modified PCA approach on network anomaly detection, ” in 2014 International Conference on Next Generation Networks and Services (NGNS) , May 2014, pp. 124–131. [19] R. Mag ´ an-Carri ´ on, J. Camacho, and P . Garc ´ ıa-T eodoro, “Multiv ariate Statistical Approach for Anomaly Detection and Lost Data Recovery in W ireless Sensor Networks, ” International Journal of Distributed Sensor Networks , vol. 11, no. 6, pp. 1–20, June 2015. [20] A. P ´ erez-V illeg as, J. Garc ´ ıa-Jim ´ enez, and J. Camacho, “FaaC (feature- as-a-counter) parser - Github, ” [Online; Accessed 30-September-2019] https://github .com/josecamachop/FCParser. [21] J. E. Jackson and G. S. Mudholkar, “Control Procedures for Residuals Associated with Principal Component Analysis, ” T echnometrics , v ol. 21, no. 3, pp. 341–349, 1979. [22] H. Hotelling, Multivariate Quality Contr ol. T echniques of Statistical Analysis . MacGraw-Hill, 1947. [23] P . Nomikos and J. F . MacGregor , “Multiv ariate SPC Charts for Monitor- ing Batch Processes, ” T echnometrics , vol. 37, no. 1, pp. 41–59, February 1995. [24] J. Camacho, “Observation-based missing data methods for exploratory data analysis to unv eil the connection between observations and vari- ables in latent subspace models, ” Journal of Chemometrics , vol. 25, no. 11, pp. 592–600, November 2011. [25] M. Fuentes-Garc ´ ıa, G. Maci ´ a-Fern ´ andez, and J. Camacho, “Evaluation of diagnosis methods in PCA-based Multiv ariate Statistical Process Control, ” Chemometrics and Intelligent Laboratory Systems , vol. 172, pp. 194–210, January 2018. [26] M. H. Bhuyan, D. K. Bhattacharyya, and J. K. Kalita, “Network Anomaly Detection: Methods, Systems and T ools, ” IEEE Communi- cations Surveys Tutorials , vol. 16, no. 1, pp. 303–336, 2014. [27] Z. Li, A. L. G. Rios, G. Xu, and L. T rajkovi ´ c, “Machine Learning T echniques for Classifying Network Anomalies and Intrusions, ” in 2019 IEEE International Symposium on Cir cuits and Systems (ISCAS) , May 2019, pp. 1–5. [28] G. Maci ´ a-Fern ´ andez, J. Camacho, R. Mag ´ an-Carri ´ on, P . Garc ´ ıa- T eodoro, and R. Ther ´ on, “UGR‘16: A new dataset for the e valuation of cyclostationarity-based netw ork IDSs, ” Computers & Security , v ol. 73, pp. 411–424, March 2018. [29] J. Camacho, “Visualizing Big data with Compressed Score Plots: Approach and research challenges, ” Chemometrics and Intelligent Lab- oratory Systems , v ol. 135, pp. 110–125, July 2014. [30] R. Mag ´ an-Carri ´ on, J. Camacho, and G. Maci ´ a-Fern ´ andez, “MSNM- S: Multiv ariate Statistical Network Monitoring-Sensor - Github, ” [Online; Accessed 30-September-2019] https://github.com/nesg- ugr/ msnm- sensor. [31] G. Maci ´ a-Fern ´ andez, J. Camacho, P . Garc ´ ıa-T eodoro, and R. A. Rodr ´ ıguez-G ´ omez, “Hierarchical PCA-based multiv ariate statistical net- work monitoring for anomaly detection, ” in 2016 IEEE International W orkshop on Information F orensics and Security (WIFS) , December 2016, pp. 1–6.