Source-linked AI summary
FLEAM: A Federated Learning Empowered Architecture to Mitigate DDoS in Industrial IoT
J. Li, L. Lyu, X. Liu, X. Zhang, X. Lyu
TL;DR
DDoS attacks threaten IIoT, while existing mitigation focuses on defending individual victims and gives inadequate attention to hacking costs and defender collaboration. FLEAM combines federated learning with fog/edge computing to coordinate joint detection and source-end mitigation; compared with classic solutions, it reports 72% lower mitigation response time and 47% higher mitigation accuracy.
Problem
DDoS attacks threaten IIoT, while existing mitigation focuses on detection and mitigation at the victim and gives inadequate attention to hacking costs and defender collaboration.
Method
FLEAM combines federated learning and fog/edge computing to coordinate joint detection, distributed training, and mitigation along the attacking path.
Results
72% lower mitigation response time and 47% higher mitigation accuracy are reported for FLEAM compared with classic solutions.
Takeaways & Limitations
FLEAM pushes mitigation toward the source, potentially removing zombies before they attack another victim within the defender alliance.
Takeaways & Limitations
FLEAM's federated-learning process remains vulnerable to lost model updates and suboptimal global models in fragile IIoT communication environments.
Abstract
from arXiv · showhide
The distributed denial of service (DDoS) attack is detrimental to the industrial Internet of things (IIoT) as it triggers severe resource starvation on networked objects. Recent dynamics demonstrate that it is a highly profitable business for attackers using botnets. Current centralized mitigation solutions concentrate on detection and mitigation at a victim's side, paying inadequate attention to hacking costs and the collaboration of defenders. Thus, we propose the federated learning empowered mitigation architecture (FLEAM) to advocate joint defense, incurring a higher hacking expense. FLEAM combines FL and fog computing to reduce mitigation time and improve detection accuracy, enabling defenders to jointly combatting botnets. Our comprehensive evaluations showcase that the attacking expense incurred is 2.5 times higher, the mitigation delay is about 72% lower, and the accuracy is 47% greater on average than classic solutions.
I. INTRODUCTION
DDoS attacks threaten resource-constrained IIoT systems, while centralized defenses inadequately address attacker expense and defender collaboration. FLEAM combines federated learning with fog/edge computing and attacker-centric mitigation to support joint defense.
- DDoS attacks have become a significant public hazard, and botnet-for-hire services make them highly profitable for attackers.
- Resource-limited IIoT devices often cannot train machine-learning models, while application-specific nodes may lack sufficient training samples.
- Federated learning lets collaborators train a global model locally and exchange model parameters, reducing latency and traffic while supporting distributed detection.
- FLEAM places mitigation intelligence along attacking routes rather than tightly around victims, advocating attacker-centric mitigation and joint defense.
- The IMA-GRU protocol performs joint accurate detection on distributed data, while FLEAM enables cross-defender detection and mitigation.
- 72% lower mitigation response time and 47% higher mitigation accuracy are reported for FLEAM compared with classic solutions.
III. PROBLEM FORMULATION
The problem formulation models distributed botnets attacking alliance victims while defenders detect and mitigate individually. It motivates a cooperative fog/edge and federated-learning defense that removes bots closer to their sources.
- III. PROBLEM FORMULATION: Victim-centric defenses detect and mitigate near victims individually, leaving other users exposed until bots are recognized and removed at their sources.
- A. System Model: Fog/edge connects IIoT systems, with MPM monitoring and classifying traffic, LAM analyzing traffic and adjacent MPM health, and DPM coordinating policies and models.
- A. System Model: Centralized training sends collaborator data to the cloud, creating latency and resource concerns for dynamic, application-specific IIoT environments.
- A. System Model: Federated learning distributes a model to collaborators, who retrain it locally while the cloud aggregates parameters without requiring dataset uploads.
- 1) Botnets: The botnet consists of networked zombies in distributed networks that attackers control to launch passive and active attacks against alliance victims.
- 2) Defense Goals: The defense has two goals: catch bot flows targeting alliance victims and remove bots rooted in a collaborator’s network.
3) Offensive Firepower:
FLEAM frames DDoS defense around offensive firepower, attacker-centric mitigation, and collaboration among defenders. Its architecture distributes monitoring, analysis, policy, and federated training across the defense alliance.
- 3) Offensive Firepower: Offensive firepower represents attackers’ aim to generate more output from distributed botnets with minimum input.
- 3) Offensive Firepower: The model assumes offensive firepower is generally inversely proportional to stealth and that fog/edge manages and protects IIoT nodes.
- 3) Offensive Firepower: FLEAM assumes there are no malicious collaborators in the alliance so federated learning can train an accurate model.
- Rapid depletion of CPU and memory resources can trigger system failure, and a victim is compromised when a defender cannot allocate additional supplies.
- Active mitigation distributes detection and mitigation along attack routes to remove malicious codes, unlike victim-centric placement around the target.
- Joint defense lets parties share defense information and actionable knowledge against a common adversary.
- FLEAM’s MPM, LAM, DPM, and aggregator coordinate monitoring, filtering, detection, analysis, policy storage, and training.
- The local analysis module makes provisional traffic decisions, while collaborators mitigate locally according to policies derived from training results.
B. FL Design in FLEAM
FLEAM’s federated-learning design profiles packet sequences, uses GRU-based occurrence probabilities to detect anomalies, and jointly optimizes a model across collaborators.
- FLEAM’s training elements—AS, DPM, and aggregator—form a worker, coordinator, and cloud-server hierarchy.
- Packet sequences are represented as ordered chains of packets, with each packet associated with a symbol and position.
- Incoming packets are profiled using the symbols and features specified for packet and policy analysis.
- A GRU estimates each symbol’s occurrence probability from preceding symbols, supporting sequence-based traffic analysis.
- The baseline ∆ contains occurrence-probability values and serves as the detection threshold for distinguishing traffic patterns.
- Traffic is treated as potentially malicious when its occurrence probability is smaller than the benign-data pattern and the anomaly condition is met.
- Multiple collaborators jointly optimize the current model with local data using stochastic gradient descent across all collaborators’ samples.
2) Training Process:
The training process coordinates collaborators through a server, DPMs, and LAMs, combining local retraining, policy generation, and parameter aggregation. The GRU-based process uses defined model, loss, regularization, and prediction components.
- Training objective: The global objective minimizes collaborators’ local loss functions while including a regularizer controlled by λ.F(ω) is the general loss function, ω is the local model parameter, and m is the number of collaborators.
- Model components: The GRU functions support training by mapping feature-space inputs to predictions through an update function and information-flow weight.
- Participant coordination: The scheduler selects participants, while DPMs verify local LAM availability before accepting collaborators into a training round.Unavailable LAM modules cause invitations to be rejected.
- Local retraining: Participants receive the global model, retrain locally for E epochs using batches of size B, and return updated parameters for aggregation.Local updates use gradient optimization with learning rate θ.
- Policy generation: During training, AS establishes thresholds and produces an actionable policy, while DPM stores the result and updated model before forwarding parameters to the aggregator.
3) The FL Implementation:
FLEAM implements federated learning across fog and edge nodes rather than resource-constrained IIoT devices, coordinating local models through DPMs and a cloud server. The resulting policy supports joint detection and mitigation, while separating combat from training.
- FL placement: Fog and edge nodes host training because IIoT data are distributed and non-IID, while these nodes offer more samples and fewer communication constraints.
- FL coordination: DPM coordinates multiple LAMs, stores the latest model and parameters, and distributes training jobs according to local availability.
- Policy deployment: The trained model forms a DDoS policy in a traffic-policy database that instructs MPM in joint detection and mitigation.
- Training protection: Separating combat from training limits traffic entering the training equipment without affecting training because LAMs retain enough packet samples.
- Training configuration: FLEAM uses synchronous IMA-based training with SGD, self-adaptive local epochs, and one aggregation per global training epoch.
1) Necessary Condition:
FLEAM’s necessary condition models DDoS economics around attackable entities, positive attacker profit, botnet cost, and mitigation delay. The design targets higher attack expense by reducing mitigation delay and accounting for bot population requirements.
- Attack conditions: The attack model requires a nonempty set of attackable entities and a positive attack profit.
- Target selection: Attackers select valuable targets from the attackable set to maximize return.
- Cost model: The simplified cost model counts botnet expenses, including rental and setup payments.
- Cost dynamics: Reducing mitigation delay increases attack cost, while the required bot population depends on available idle resources and killing power.
- Delay and cost: Mitigation delay is the most critical DDoS factor and a significant component of attack cost.
2) Node Selection:
FLEAM selects fog nodes using network-importance measures and distributes mitigation intelligence along attacking routes. Its evaluation compares malicious traffic patterns, mitigation times, and attacking expenses against prior solutions.
- Node-selection criteria: Fog nodes are evaluated using degree, betweenness, and closeness importance to guide mitigation placement.
- Degree importance: Degree importance measures direct connections, while its normalized form compares a node with the highest-degree node.
- Path-based importance: Betweenness importance measures shortest paths passing through a node, whereas closeness importance uses average shortest distance to other nodes.
- Mitigation placement: Distributing mitigation intelligence at the fog or edge layer enables source-end removal of malicious data within the defender alliance.
- Evaluation comparisons: The evaluation compares victim-centric and FLEAM mitigation time using combined malicious traffic patterns and country-specific attacking expenses.
V. QUANTITATIVE EVALUATION
The evaluation compares FLEAM with victim-centric and unprotected settings across attack intensity, mitigation delay, and incurred attack expense. FLEAM reduces mitigation delay and increases the expense required to sustain attacks.
- Mitigation delay: FLEAM reduces mitigation delay to approximately 28% of the victim-centric model as bot populations increase.System response time still grows as the bot population increases.
- Attacker expense: FLEAM increases the attack expense to about 3.7 times the victim-centric model, reaching $0.37 per second versus $0.1.The calculation uses the expense for a 1000-bot attack against one victim.
- Attacker response: FLEAM’s shorter mitigation delay reduces bot survival time and requires attackers to invest more bots to overwhelm a victim.The authors report that this may discourage cost-sensitive cybercriminals from continuing attacks.
- Attack levels: CPU utilization rises from 20% in the baseline to 45%, 85%, and 98% across light, medium, and heavy attacks.The scenarios also measure active TCP connections and benign-data upload and download delays.
- Evaluation setup: FLEAM places mitigation at the fog firewall, whereas Classic replicates victim-centric protection at the cloud firewall.The testbed uses OPNET Modeler and includes a workstation, switched LAN, firewall, router, cloud, server, and reflector.
2) The Result Comparison:
The result comparison evaluates service behavior, mitigation accuracy, and the IMA-GRU protocol. FLEAM improves benign-data delays and joint mitigation accuracy, while federated training approaches centralized accuracy with greater practicality for IIoT.
- System performance: FLEAM reduces benign-data downloading delay to 0.7–5 seconds, compared with 6–10 seconds for Classic and 50–100 seconds when unprotected.Protection can increase server delay, but the authors describe this as an acceptable cost associated with reduced queuing time.
- System performance: FLEAM’s cross-defender mitigation restores benign traffic and saves bandwidth by stopping DDoS codes from entering the system.The comparison also measures queuing delay, uploading bandwidth, throughput, and related service metrics.
- Mitigation accuracy: Joint mitigation reaches up to 98% accuracy with FLEAM, compared with up to 95% in Classic solutions.Individual mitigation accuracy is approximately 51% in the attacker-centric setting and 52% in the victim-centric setting.
- Protocol dependence: FLEAM’s reported detection performance depends heavily on accurate detection from the IMA-GRU protocol.The paper explicitly links mitigation accuracy to the protocol’s detection performance.
- Protocol testbed: The IMA-GRU protocol is tested on the labeled UNSW NB-15 intrusion-detection dataset using four virtual collaborators.The experiment distributes random portions of the dataset among collaborators and uses local testing subsets.
- Accuracy comparison: Federated training produces accuracy with an almost ignorable difference from centralized training on the full UNSW NB-15 dataset.The authors state that centralized training would incur excessive communication cost in realistic IIoT deployments, making FL more scalable and practical.
VII. DISCUSSIONS AND CONCLUSION
The discussion positions FLEAM as a cooperative, attacker-centric architecture that combines fog/edge computing with federated learning and source-end mitigation. The authors report benefits for delay, expense, scalability, and practical deployment, while identifying communication and data heterogeneity as FL constraints.
- Discussion: FLEAM trains and protects at the fog/edge layer to address IIoT computing, communication, data, latency, and security constraints.Federated learning trains a global model without moving training data to the cloud aggregator.
- Discussion: The IMA-GRU protocol updates a shared model from collaborators’ retrained parameters, enabling local bot recognition and removal.The server aggregates parameters and sends the latest model back with limited parameter exchange.
- Discussion: Frequent inter-node communication can lose model updates in fragile IIoT networks and produce suboptimal global models.The paper also identifies heterogeneity in dataset size, distribution, and life cycle as an FL limitation.
- Discussion: FLEAM distributes mitigation intelligence along the attacking path, potentially removing botnet zombies before they attack a second alliance victim.This attacker-centric design pushes the defensive front line toward the source end.
- Conclusion: FLEAM is presented as simple, scalable, and easily adoptable while generating actionable intelligence at the source end.Its practical claim follows from combining cooperative detection with distributed source-side mitigation.
- Conclusion: The paper reports advantages in mitigation delay and incurred expense, alongside accuracy validation on the UNSW NB-15 dataset.The authors limit the demonstrated scope to DDoS but present FLEAM as an example for profit-driven, expense-sensitive attacks.