## 4 Intrusion Detection Systems Based on Federated Learning
### Comparative Analysis of Federated-Learning-Based Intrusion Detection Systems
#### 4.1.1 The Federated Learning-Based Intrusion Detection Systems for Smart Home Settings
**  
In [20], a federated self-learning anomaly detection system for IoT--DIoT--is presented. The authors use the federated learning approach for the intrusion detection based on anomalies in the device type communication behavior. To detect anomalies, the authors represent the network packets as symbols and use language analysis techniques. _Federated learning architecture_. The authors implemented the centralized architecture. The IoT devices are connected to the local security gateways that implement an anomaly detection service that trains models locally; these models are aggregated in the global detection model by the external IoT security service connected to multiple gateways. The federated learning process is organized as follows. In the first step, each security gateway requests the initial gated recurrent unit (GRU) model for the specific IoT device profiles (_type#k_) from the IoT security service (initially the model is random) and obtains it in the second step. In the third step, the security gateways retrain the global model locally. Then, in the fourth step, the security gateways send the model updates to the IoT security service. It aggregates the local models to enhance the global model [1]. In the final step, IoT security service shares the updated global model for _type#k_ devices with security gateway and uses it for anomaly detection. _ML model_. The authors used the gated recurrent unit (GRU) model. _Implementation_. To implement the described architecture, the following tools are used:  
* Server-side application--the flask [63] and flask_socketio [64] libraries;
* Client-side application--the socketIO-client [65] library and the event asynchronous framework [66], which provides a clean API for concurrency and network related tasks;
* Gated recurrent unit (GRU) network--the Keras [67] library with Tensorflow backend;DatasetThe authors collected three datasets--activity dataset, deployment dataset, and attack dataset--using a laboratory network. It incorporated a laptop with Kali Linux where hostapd was used to create a gateway acting as an access point with WiFi and Ethernet interfaces. IoT devices were connected to this access point. The authors used tcpdump on the gateway to collect the network traffic packets from the IoT devices. The activity dataset incorporates traffic representing device activity for 33 IoT devices (i.e., IP cameras, smart power plugs and light bulbs, sensors, etc.) as well as traffic collected during two to three, during which actions were triggered only occasionally. The deployment dataset was collected from 14 Smart Home IoT devices installed in a realistic Smart Home deployment setting during one week. Attack dataset was collected for the devices infected with Mirai malware [3] including the traffic when Mirai was in a standby mode. Used aggregation methodGlobal model aggregation:  
\[G=\sum_{i=1}^{n}\frac{s_{i}}{s}W_{i}, \tag{1}\]  
where \(n\)--number of clients; \(W_{1},\ldots,W_{n}\)--clients' associated model weights; \(s_{1},\ldots,s_{n}\)--associated number of data samples used for training; \(s=\sum_{i=1}^{n}s_{i}\). Used metrics  
False positive and true positive rate;  
Average detection time: 257 \(\pm\) 194 ms;  
Processing performance of GRU--average processing time per symbol (packet) for prediction--0.081 (\(\pm\)0.001) ms for the desktop utilizing its GPU and 0.592 (\(\pm\)0.001) ms when executed on the laptop with CPU;  
On average, training a GRU model for one device type took 26 min on the desktop and 71 min on the laptop hardware.