Skip to content

Autoencoder

Dimitris Lioprasitis edited this page Feb 9, 2021 · 7 revisions

Autoencoder is the core component of Security Framework, encapsulates the detection logic and produces the results visualized on Grafana dashboard.

Below are the stages that autoencoder functions:

Preprocessing

Training data have been collected from both Node Exporter and Amari Exporter. Because of these two different systems, there is a small difference in timestamps for these metrics. For this reason the training dataset is resampled every 15 seconds, to synchronize records from these two exporters. For training, the following features have been selected: CPU percentage rate, RAM percentage rate, RX/TX CPU percentage rate, rate of transmitted/received bytes and rate of bytes downloaded/uploaded from 5G interface. These features are normalized using Min-Max Normalization. The min & max values that will be used for normalization will be saved in a JSON file. After resampling and normalize the dataset is split in sequences, with four steps per sequence, where the first three records will be used to predict the fourth.

Training

For training the architecture of an Autoencoder has been used. Model consisted of 9 Bidirectional LSTM layers and one Dense layer at the end.

As activation function ReLu is used. SGD with Nesterov momentum has been selected as optimizer, with learning rate equal to 0.01. As validation dataset 10% of the trainset has been used. The model is trained for 50 epochs.

Evaluation

If evaluation is enabled, trained model will be loaded and used for testing in three different datasets. The first dataset has been collected during a CPU stress test attack. The second dataset has been collected during an iperf stress test attack. The third dataset is the training set. All these datasets will be normalized with saved normalization values during training. Using these datasets, the RMSE between the actual and predicted values will be calculated. Network features’ thresholds, will not be affected from CPU stress dataset and CPU features’ thresholds will not be affected from iperf stress test dataset. The 99th percentile of each feature’s RMSE will be considered as threshold from anomaly detection algorithm. The 99th percentile has been selected compared with the max value in order to avoid outliers, that may exist in these datasets. User-defined thresholds will not be overridden from calculated RMSEs.

Testing

Trained model will be used in order to predict the next features’ values in the time series. Because it is trained in normal traffic it will predict these values considering that the incoming traffic is normal. If the RMSE between the predicted and actual value is above a set threshold this record will be considered as anomaly. Algorithm fetches the last received from an Influx DB every 15 seconds. For predicting the next value, a sliding window with size equal to 30, keeping only last records is used. Fetched records are been preprocessed and normalized before used by the model for predicting. After prediction the RMSEs between the actual and predicted values are calculated and compared with set thresholds, to identify if the record considers an anomaly or not. A possible cause of the anomaly is also saved in the database with the detected anomalies or an ‘unknown cause’ will be set if the cause cannot be identified. A proposed thresholds JSON file for testing is the follow:

{"cpu_threshold": 0.05, "mem_threshold": 0.1, "cpu_tx_threshold": 0.1, 
"cpu_rx_threshold": 0.1, "net_up_threshold": 0.501, 
"net_down_threshold": 0.501, "net_5g_up_threshold": 0.501, 
"net_5g_down_threshold": 0.501, "overall_threshold": 0.15}
Clone this wiki locally