A Design of an Integrated Cloud-based Intrusion Detection System with Third Party Cloud Service

3.1 Feature extraction

Machine learning-based security approaches are likely vulnerable to poisoned datasets which can be caused by a legitimate defender's misclassification or attackers aiming to evade detection by contaminating the training data set. There also exist obvious gaps between the lab environment and the real world. Giving importance to the former fact which necessitates the need for an auditing system as a part of any cloud-based IDS. Regardless of the type of detection method, the auditing system captures data flow passing through the entire infrastructure of the cloud. Then, the collected flow should be analyzed by carrying out an important process called feature extraction. Afterwards, these extracted features are useful for training or building prediction models.

Basically, the term “feature” stands for a particular aspect of information in the record. Thus, feature extraction is a process where a set of descriptive statistics of the traffic flow is extracted for each packet separately. After that, these extracted features are saved together into one record where each field of that record represents one of the extracted features. Continuing in this manner, a set of records of different data packets are obtained and stored in a database or data warehouse for training or testing purposes. Determining which features to be extracted from the collected raw data is a big dilemma. Because it is critical to extract only features that are able to characterize successfully the activity of the origin data packets. This will help prediction models to determine whether the packet has a malicious activity or not, and then a decision is taken to decide which traffic may pass and which traffic is blocked accordingly. In this subsection, we specify a set of features to be extracted by the auditing system of our proposed CIDS. These features are well-known and are reported in some of previous studies in the literature.

Lashkari et al. [36] presented a new software known as CICFlowMeter which is publicly available on the Canadian Institute for Cybersecurity website [12]. By using CICFlowMeter, they generated Tor flows and proposed a set of time-related features to identify and characterize Tor traffic. In addition to that, they have proved that using time-related features only they can identify and characterize Tor traffic to some extent.

After that, Sharafaldin et al. [57] have extended the former study and published a new reliable IDS dataset called Canadian Institute for Cybersecurity Intrusion Detection Systems 2017 (CICIDS2017) [9]. CICIDS2017 is completely labeled dataset and has 80 network traffic features which are extracted from pcap raw data using the CICFlowMeter. Further, the features are extracted and calculated for both benign and intrusive flows which are based on various applications and network protocols. In order to cover a diverse set of common attack scenarios, they executed 20 different attack types which can be categorized into 7 major attack families or categories, namely, Brute Force, Heartbleed, Botnet, Denial of Service (DoS), DDoS, Web attack, and Infiltration. Moreover, they tested the full extracted features using a RandomForestRegressor to select a short feature subset which can be the best detection features for all seven attack categories. Hence, they reported that a subset of 23 features is the optimal feature set for all attack types [57]. The list of the optimal features and the corresponding attack categories and protocols is shown in the first row of Table 1. The Forward term means a traffic flow from the source to the destination. Whereas, the Backward term indicates a traffic flow in the inverse direction, that is, from the destination to the source. Finally, the term Flow means a bi-directional flow in either direction.

In a similar manner, the Coburg Intrusion Detection Data Set (CIDDS) is a labeled flow-based dataset for the evaluation of anomaly-based IDS, and it is also publicly available on the Internet [13]. Indeed, CIDDS has two versions, namely, CIDDS-001 [53] and CIDDS-002 [54]. The main difference between them is that CIDDS-001 has various attack types with a total of 92 attack types whilst CIDDS-002 is a port scan attack only dataset with a total of 43 port scan attacks. Furthermore, they collected unidirectional NetFlow audit data and analyzed them to extract 10 different features as well as an additional attribute for the appropriate label. The attack types in CIDDS-001 are also grouped into four major attack categories such as DoS, Brute Force, Port Scan, and Ping Scan. Thus, we included nine features of CIDDS to our auditing system, where the remaining feature is duplicated. The selected features of CIDDS are presented in the second row of Table 1.

Moreover, NSL-KDD is a well-known IDS dataset and widely used in intrusion detection field [49, 61]. NSL-KDD is an improved version that resolved all limitations of earliest IDS datasets: DARPA [43, 45] and KDD CUP 99 [60, 62]. They captured tcpdump raw data and then processed it to extract 41 different features. In addition to that, NSL-KDD has 38 attack types which are combined into four major attack categories, namely, DoS, Probing (Probe), Remote to Local (R2L), and User to Root (U2R). There are many previous studies that performed a feature selection process to NSLKDD to select feature subsets that suited with each attack category [3, 5, 47, 48, 66]. We concluded all these feature subsets in the third row of Table 1 after removing duplicated attributes.

In this study, we selected all the forty features in Table 1 to be calculated and extracted from traffic flows through our auditing system by using the same procedures that were used in the previous studies discussed above. We believe that the selected set of features are able to represent the different activities of the users as well as cover wide range of common attack families. Finally, Gharib et al. [25] proposed an evaluation framework for IDS datasets that reflects the characteristics of a valid dataset, and consists of eleven characteristics, namely, Complete Network Configuration, Complete Traffic, Labeled Dataset, Complete Interaction, Complete Capture, Available Protocols, Attack Diversity, Anonymity, Heterogeneity, Feature Set, and Metadata. It has been shown that the selected features in Table 1 are totally complied with aforementioned evaluation framework [25].

3.2 Data preprocessing

Most of the machine learning models can only work with numerical values for training and testing. Therefore, it is necessary to convert all non-numerical values to numerical values by performing data numericalization. We prefer to use the method of data numericalization such that for each nominal feature, its values are ordered alphabetically. After that, the ordered nominal values are converted to numerical values by assigning specific values to each variable ranged in [1, length of the list].

Then, the data normalization process has taken place when all numeric features in the dataset (including the transformed nominal features) are mapped into [0,1] linearly by using the following Min-Max transformation formula [65].

where x_i is the numeric feature value of the i^th sample, Min and Max are the minimum and maximum values of every numeric feature, respectively.

3.3 Feature and Hyperparameter selection

Recently, Elmasry et al. [21] proposed a novel double Particle Swarm Optimization (PSO) algorithm for automatic feature and hyperparameter selection. It is a top-down hierarchical metaheuristic which simply consists of two sequential levels. In the upper level, it receives the given dataset with full feature set (D) and runs the Fitness Proportionate Selection Binary Particle Swarm Optimization and Entropy (FPSBPSO-E) algorithm [21] to select the optimal feature subset. FPSBPSO-E is a modified version of the single-objective filter-based feature selection method that was introduced by Cervante et al. [10]. The major difference between FPSBPSO-E and the method in the study of [10] is applying the Fitness Proportionate Selection Binary Particle Swarm Optimization (FPSBPSO) algorithm [70] in the core of optimization process rather than using the traditional Binary PSO. FPSBPSO-E determines the relevance and redundancy of the selected feature subset by measuring the entropy of each group of features. Mathematically, the fitness function can be computed using the following formula [10].

where

where X is the set of the selected features and C is the set of class labels. D₂ indicates the relevance between the selected features and the class labels by calculating the information gain (entropy) in the class labels given information of the selected features. R₂ evaluates the redundancy contained in the selected feature subset by measuring the joint entropy of all the selected features. Fitness₂ is a maximization fitness function which minimizes the redundancy (R₂) and simultaneously maximizes the relevance (D₂). In addition to that, α₂ is a weight parameter which is a constant value ranged in [0,1]. Finally, FPSBPSO-E outputs the optimal feature subset and reduces the original dataset to the reduced dataset D^* with only the selected features.

After that, in the lower level, the double PSO-based algorithm receives a copy of the reduced dataset D^* and the type of the deep learning model M as inputs and then executes a continuous PSO-based algorithm [19] for hyper-parameter selection. The PSO-based algorithm maximizes the accuracy of model M over the given training set of the reduced dataset D^* and outputs the optimal hyperparameters vector H^* of the model M. Finally, the double PSO-based algorithm outputs both D^* and H^* and terminates. Figure 1 shows the diagram of the double PSO-based algorithm.

Figure 1

The diagram of the double PSO-based algorithm.

5.1 Monitoring module

Primarily, the cloud users access their data and applications on remote servers at the site of CSP over the cloud network. Thus, user actions and requests must be monitored and logged through an auditing system. The monitoring module is deemed to be the auditing system of the proposed CIDS. It performs two separated functions, namely, capturing traffic flows and feature extraction.

The first function of the monitoring module is capturing all the in-bound and out-bound data packets that are traversing within the cloud network. In order to facilitate this task, the monitoring module uses sensors to sensitize network traffic. Further, the monitoring module has the flexibility to capture data packets of different application, transport and network protocols such like TCP, UDP, ICMP, IP, HTTP, SMTP, etc. The collected traffic flows is stored immediately in the shared queue. The aim of using the shared queue is to be an intermediate station between packets capturing and feature extraction, that is, to store collected data packets until the feature extractor processes them sequentially. The shared queue has enough space in term of storage capacity to store the collected data packets without overflow.

Afterwards, the feature extraction process takes place through a feature extractor. Our feature extractor handles every data packets in the shared queue in such a way it extracts 40 features from the data packet as mentioned in subsection 3.1. Then, it put all the extracted features of the data packet into a data record or tuple and sends it to the next module, i.e., the processing module. These data records are the essence of the scene and the raw material that we need for training and prediction. Figure 4 shows the process of the monitoring module. It is worthy to say that the operation of the monitoring module is lasting, continuous and independent from other modules.

Figure 4

The process of the monitoring module.

5.2 Processing module

The processing module performs all required missions prior to the prediction process. It firstly receives data records from the feature extractor and tries to assign them to the proper class label (either “Normal” or “Attack”). This can be accomplished by leveraging a signature-based detection procedure which employs a set of pre-defined rules (signatures) to match the inspected data record against known attack patterns. If there is a match, the data record will be labeled as an “Attack”. Otherwise, it will be labeled as “Normal”. These rules are defined and set by the cloud service provider. After that, processing module stores the labeled data record in a database we named it as “master database”.

The former process will take place only in the first run of the system. In other words, in the first run, the processing module will create the master database from scratch, receive data records, label data records using the above mentioned method, and save the labeled data records in the master database sequentially. Once the master database becomes rich enough in diversity and quantity, the processing module will stop the former process and creates another database from scratch. We named it as “unseen database”. Then, all new coming data records will be saved in the unseen database without labeling. Accordingly, the master database which contains labeled data records will be used as the training set of our cloud-based IDS. On the other hand, the unseen database which contains unlabeled data records will be the test set.

The last function of the processing module is data preprocessing. It occurs just when processing module finished filling in the master database. The data preprocessing will be handled on the master database using the same procedure which is explained in subsection 3.2.

5.3 Analysis module

The analysis module performs pre-training and training phases of the deep learning models. In the pre-training phase, the analysis module executes the double PSO-based algorithm which is explained in subsection 3.3 for both feature and hyperparameter selection. Firstly, the analysis module receives a copy of the master database after data preprocessing. Next, it executes the upper level of the double PSO-based algorithm on the master database to find out the optimal feature subset. After that, it reduces the master database using only the optimal features. Then, it executes the lower level of the double PSO-based algorithm by using the reduced master database to obtain the optimal hyperparameter vector of the desired deep learning model. Because we have three deep learning models, the latter step will be repeated three times one for DNN, LSTM-RNN and DBN models, respectively. Afterwards, the training phase takes place for each deep learning model separately on the reduced master database.

5.4 Prediction module

The prediction module is the core of the proposed CIDS that performs two sequenced functions. The first is construction of the bagging ensemble system which was proposed in Section 4 using the learned DNN, LSTM-RNN and DBN models that previously obtained from the analysis module. Then, processing module gets a copy of the unseen database and performs a data preprocessing on it as well. The second function of the prediction module is to pick up a data record from the preprocessed unseen database sequentially. After that, the picked data record is tested using the bagging ensemble system, and the final decision obtained from the majority voting engine is delivered to the response module.

5.5 Response module

The response module is in charge of controlling the whole operation in the proposed CIDS by carrying out three major functions. First, it receives the final decision along with the tested data record, and then it labels the tested data record with the final decision. Thereafter, it updates the master database by saving the new labeled data record at the end of the master database.

The second function is responsible for taking a reaction upon the final decision whether it is “Normal” or “Attack”. In the case of “Normal”, the response module sends a command to the prediction module to continue with the next data record in the unseen database to predict its label. On the other hand, if the received final decision is “Attack”, then the response module raises an alarm that the cloud network is undergoing a potential malicious activity. Afterwards, the response module terminates the session of the attacker as well as blocks all traffic flows belonging to that malicious activity. In addition to that, the response module enforces the processing module to perform a data preprocessing on a new copy of the updated master database, and sends the preprocessed master database to the analysis module. Then, the analysis module runs again to produce new optimized deep learning models, and sends them to the prediction module which in turn constructs the bagging ensemble system again and predicts a new data record from the unseen database.

The final function of the response module is logging all events in a private log file for further processing later. Figure 5 depicts the framework of the proposed cloud-based IDS.

Figure 5

The framework of the proposed CIDS.

7.1 Hybrid CIDS

It is reported that the traditional IDSs are not suitable for cloud environment, because the signature-based detection IDSs cannot detect new or unknown attacks, meanwhile, the anomaly-based detection IDSs are computationally expensive and need a large amount of pure normal data [46]. As mentioned in Section 5, the proposed CIDS combines the two detection techniques together, since it performs knowledge-based detection (known trails of previous attacks) in the processing module as well as performs behavior-based (comparison of recent user actions to usual behavior) in the prediction module. At the result, the proposed CIDS will cover all known attack signatures as well as knowledge of new threats. Moreover, using a hybrid detection IDS will increase the accuracy and decrease the false alarm rate significantly [26].

7.2 Dynamic CIDS

The proposed CIDS is a dynamic system through three different perspectives. Firstly, it uses an ensemble system for intrusion detection that combines three well-known deep learning models which have the superiority over traditional machine learning methods in terms of performance. Secondly, it utilizes the double PSO-based algorithm for both feature and hyperparameter selection which makes the architecture of the deep learning models modifies dynamically. This can be explained by the fact that every time the analysis module executes the double PSO-based algorithm, it generates new optimal feature subset from the master database, then it outputs the optimal hyperparameters for each deep learning model that maximizes the accuracy over the reduced master database.

The third perspective is that the response module updates the master database periodically with new predicted “Normal” and “Attack” data records. Accordingly, this makes the master database representative dataset of real-world traffic. Furthermore, in the case of an attack, the response module enforces the analysis module to execute the double PSO-based algorithm again for new feature and hyperparameter selection which makes the deep learning models taking into account the history of all previous predictions in the master database when generating a new prediction for an unseen data record.

7.3 Multithreaded CIDS

Equally important is that the cloud computing generates an enormous amount of data due to a high network access rate. Therefore, cloud-based IDSs should be robust against false positives and noise data. In general, the traditional IDSs are not sufficient for cloud like environments for many reasons such as these IDSs are single threaded and the cloud computing has a massive network traffic that doomed to failure to handle such a large data flow, and due to rich dataset flow [26].

In order to overcome this concern, we designed the proposed CIDS to be a multithreaded IDS, that is, every module operates separately inside an independent thread of the same server. This results in the multithreaded CIDS being able to process large amount of data, reduce the packet loss, and avoid overloading of the VM hosting IDS. As a result, the proposed CIDS will improve the performance over the cloud infrastructure.

For the sake of further improvement, we also added levels of multithreading in our design of CIDS. Whereas the top level contains all the main modules, the bottom level includes the entire functions of each module. Figure 8 shows the mechanism of the proposed multithreaded CIDS. Finally, we believe that such a Parent-Child hierarchy will provide a fast and quick processing.

Figure 8

The mechanism of multithreading in the proposed CIDS.

7.4 Transparent CIDSS

The proposed CIDSS acts as an intermediate gate between the user or CSP and the the proposed CIDS. It not only controls the entire CIDS, but it also provides transparency for both the users and CSP. It keeps the users and CSP up-to-date by sending periodic reports to them in order to inform them about any intrusions happened.

7.5 Effective CIDS

In order to evaluate the performance of the proposed CIDS, an empirical experiment on real data is performed. We utilized two well-known IDS datasets, namely, NSL-KDD and CICIDS2017 datasets to test our ensemble system against single DNN, LSTM-RNN, and DBN models. Table 3 presents the results of the empirical experiment. The underlined values in Table 3 refer to the best score of the particular dataset. Based on these findings, our ensemble system outperformed other models in terms of Detection Rate (DR) and False Alarm Rate (FAR) in all datasets.

In order to interpret the results of Table 3 visually, we also plotted the Critical Difference Diagram (CDD) [16]. Figure 9 illustrates the CDD of the tested models on all datasets. Finally, we obtained the Critical Difference (CD) value which is shown as a bar above the figure and equals 3.3166.

Figure 9

The critical difference diagram of the tested models on all datasets.

7.6 Computational complexity

The core part of the proposed CIDS is the analysis and prediction modules. Regarding the analysis module, a double PSO-based algorithm is applied to select the optimal feature subset as well as the optimal hyperparameters. As mentioned before, the double PSO-based algorithm utilized the FPSBPSO-E algorithm for feature selection which have a complexity of O(pnlog(n)) where n is the initial population size and p is the number of iterations. Further, the double PSO-based algorithm exploited a PSO-based algorithm for hyperparameter selection and since the PSO-based hyperparameter selection algorithm computes fitness function for each particle, updates each particles personal best vector, and finally updates the global best vector for the swarm regarding all iterations, the complexity become O(n⁴). In order to emphasize the computational overhead, we benefited from the Rosenbrock function to reveal the performance of the FPSBPSO-E algorithm, and we observed that it was more consistent but less sensitive to the choice of hyperparameters whereas the PSO-based hyperparameter selection algorithm produced better results than any other alternative. However, it has a slower convergence on locating the global minimizer. When comparing both approaches, the PSO-based hyperparameter selection algorithm requires almost double the resources and execution time against FPSBPSO-E algorithm [21].

On the other hand, the prediction module depends on a bagging ensemble system of three deep learning models to predict intrusions. We can distinguish between three phases of the bagging ensemble system: training, search of the optimal ensemble, and inference. It is reported that the computational complexity of the training phase is O(B(N + R)), where N is the number of classifiers, R is the number of replacements, and B is the number of bags. Meanwhile the computational complexity of the searching phase is O(N), the computational complexity of the inference phase is O(B) [23].

7.7 Limitations

The proposed system might suffer from two potential limitations. Firstly, the Processing module used a signature-based detection procedure in creating the master database. The signature-based detection relies on a set of rules that defined solely by the CSP to determine which records are attack or not. If these rules are not updated enough to classify the attacks correctly, then the master database may have several misclassified records inside and then the process of the analysis module which depends on the master database may be affected significantly. Secondly, the proposed multithreaded CIDS needs a lot of resources that one server cannot afford. Therefore, the process of multithreading can be divided to a cluster of machines in order to benefit from the parallel computation capability.