SDN-enabled adaptive security framework for multi-cloud infrastructures using deep learning-based threat detection and policy management

Software Defined Multicloud Defense Controller (SDMDC)

The centralized intelligence element of the architecture is the SDMDC, which controls security operations among heterogeneous multiple clouds. It operates at the control plane, separating security management operations from the data plane, where the MCIDS-G are situated. The SDMDC attains a uniform and scalable security posture on leading cloud platforms such as Azure, AWS, and Google Cloud by enabling global security strategy, threat detection, and policy management enforcement.

Each of the SDMDC’s three core components—policy optimization, global IDS, and policy management—is responsible for providing real-time cloud security.

Policy management

The SDMDC policy management module is indispensable for creating, sharing, and enforcing security policies in a multi-cloud system. These rules enable cloud platform reaction mechanisms, govern traffic, and generate threat levels. By centralizing control and coordinating security measures, the SDMDC ensures that all cloud environments adhere to a consistent policy, which helps minimize misconfigurations and enforces policy consistency across clouds.

The SDMDC monitors incoming data and adjusts rules dynamically to reflect emerging risks and traffic behavior. Suppose the local IDS in Google Cloud detects the Structured Query Language (SQL) Injection attack. In that case, the SDMDC will modify the policy to prevent the application from being exploited and roll it across to all connected cloud platforms, including AWS and Azure. When a botnet campaign or other coordinated attack is detected, the SDMDC notifies all MCIDS-G of the necessary security policies to implement to reduce the impact on all clouds caused by command and control (C&C) nodes. To prevent security vulnerabilities from being exploited, this coordinated mechanism ensures consistent protection across all connected cloud environments.

Centralized Intrusion Detection System (global IDS)

The Cross-Cloud Threat Transformer (CCTT) is used by the global IDS, the principal hub of the SDMDC, to identify and link threats across different cloud infrastructures. In order to detect threats in real time and correlate them across clouds, it collects distributed MCIDS-G security alerts, logs, and unusual traffic.

Cross-Cloud Threat Transformer (CCTT)

The CCTT model controls traffic flows between clouds; it uses hierarchical attention to identify and organize coordinated cyberattacks on different cloud services. It aggregates security alerts sent by all MCIDS-G modules that are monitoring traffic patterns in their own particular clouds. Such alerts are then combined and examined to determine bigger attack campaigns, which can’t be detected in one cloud. The global IDS analyzes traffic patterns and logs to identify Botnet operations, DDoS assaults, and multi-vector intrusions.

The CSE-CIC-IDS2018 dataset was adapted to reflect an SDN-enabled multi-cloud security setting by simulating inter-cloud traffic flows using an enterprise-grade multi-cloud emulation environment. Each traffic flow was labeled according to the originating virtual cloud domain (e.g., Cloud-1, Cloud-2, Cloud-3), mimicking segmentation patterns such as AWS Virtual Private Clouds (VPCs), Azure Virtual Networks (VNets), and Google Cloud Platform (GCP) subnets. SDN-specific behaviors such as OpenFlow-style rule propagation, controller-to-switch signaling, and inter-VPC routing were simulated using Mininet in conjunction with the OpenDaylight SDN controller. This enabled realistic domain-aware policy enforcement and visibility of east-west traffic. The CCTT was trained to detect coordinated attack patterns across cloud segments, while LSTM-based MCIDS-G modules learned localized ingress and egress patterns. This process maintained the fidelity of original flows without generating artificial data, enhancing domain alignment with real-world SDN multi-cloud infrastructures.

The CCTT comprises four transformer encoder layers, each containing eight self-attention heads with an embedding dimension of 256. The model processes multivariate input sequences derived from the extended CSE-CIC-IDS2018 dataset, including flow statistics (e.g., duration, bytes), SDN-specific metadata (e.g., domain labels, controller paths), and cloud anomaly indicators (Canadian Institute for Cybersecurity, 2018).

The data collection also includes attacks that imitate cloud-based adversarial behaviour, such as DDoS, Brute Force (BF), Botnet, SQL Injection, and Infiltration. This enhances model identification of complicated, dispersed assaults, cross-cloud attack correlation, and end-to-end traffic analysis.

Collecting Data: The SDMDC receives traffic traces and security alerts sent by each MCIDS-G’s LSTM-augmented local IDS, which undergo a thorough examination. The CCTT examines this data to detect suspicious patterns or potential dangers that could be signs of cross-cloud assault activities. The global IDS can detect any DDoS campaign that spans more than one cloud. Figure 2 shows the components of the CCTT model used in the global IDS module.

The CCTT model uses a transformer-based architecture to examine and correlate security risks across various cloud environments. Utilizing a self-attention mechanism, it simultaneously examines data on network traffic time series and security warnings from various cloud platforms to identify unusual patterns that might indicate coordinated assaults.

Input representation (cloud traffic and alerts)

The provided data for the CCTT comprises the progression of traffic vectors, each illustrating network traffic tendencies or notifications from a distinct MCIDS-G at a particular time step. Assume the given progression at the moment it is denoted as:

(1) $$X_t=\left[x_{t,1},x_{t,2},\dots ,x_{t,n}\right]$$where $x_{t,i}$ is the traffic or alert data from the $i^{th}$ cloud platform (e.g., AWS, Azure, GCP) at time $t,$ and $n$ is the number of cloud environments being monitored.

1. Self-Attention Mechanism

The CCTT applies a self-attention mechanism to compute the relationships between $ea\subset h$ input element $\dot{\mathrm{\$}}n$ the sequence; for each input $X_t$, the model computes three vectors:

• Query (Q)

• Value (V)

• Key (K)

These vectors are computed as:

(2) $$Q=X_t{W}_{\mathrm{Q}},K=X_t{W}_k,V=X_t{W}_V$$where $WQ,W_{\mathrm{k}}$ and $W_V$ are learned weight matrices for the queries, keys, and values.

The significance score for each pair of traffic data points is calculated by performing the inner product of the query and key vectors, followed by a softmax function to standardize the scores:

(3) $$\mathrm{A}\mathrm{t}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\left(Q,H,V\right)=softmax\left({\displaystyle \frac{Q{K}^T}{\sqrt{d_k}}}\right)\mathrm{V}$$where $d_k$ is the dimension of the key vectors, this approach enables the model to prioritize key traffic flows or anomalies by weighting each data point’s importance.

2. Multi-Head Attention

To grasp various aspects of the traffic data, the CCTT employs multi-head attention. Each attention head calculates its distinct set of $Q,K$. and V matrices, enabling the model to identify diverse relationships between cloud traffic flows:

(4) $$MultiHead\left(Q,K,V\right)=\left[hea{d}_1,hea{d}_2\dots ,hea{d}_h\right]W_0.$$

Each head operates as a distinct self-attention mechanism, and $W_O$ acts as the resultant projection matrix. The fusion of all heads generates a more extensive representation of the traffic and anomaly patterns across clouds.

3. Positional Encoding for Sequential Data Since

Transformers do not natively interpret sequential data (like time-series traffic f1ows), the CCTT applies positional encoding to convey information about the arrangement of the input sequence. The positional encoding is incorporated into the input traffic vectors to sustain the chronological structure:

(5) $$P{E}_{\left(\mathrm{p}\mathrm{o}\mathrm{s},2i\right)}=\mathrm{s}\mathrm{i}\mathrm{n}\left({\displaystyle \frac{pos}{{10\text{,}000}^{2i/{\mathrm{d}}_{model}}}}\right),P{E}_{\left(\mathrm{p}\mathrm{o}\mathrm{s},2\mathrm{i}+1\right)}=\mathrm{c}\mathrm{o}\mathrm{s}\left({\displaystyle \frac{pos}{{1\text{,}000}^{2i/d_{model}}}}\right)$$where $pos$ represents the position of the traffic data in the sequence, and $i$ indexes the dimensions of the input vector.

4. Output and Anomaly Detection

The outcome of the CCTT is a threat detection score that indicates whether a particular traffic flow or sequence appears abnormal. This is calculated after transmitting the multi-head attention outputs through multiple entirely linked layers with Rectified Linear Unit (ReLU) activation functions:

(6) $$\mathrm{Z}=\mathrm{R}\mathrm{e}\mathrm{L}\mathrm{U}\left({\mathrm{W}}_{\mathrm{Z}}\cdot \mathrm{M}\mathrm{u}\mathrm{l}\mathrm{t}\mathrm{i}\mathrm{H}\mathrm{e}\mathrm{a}\mathrm{d}\left(\mathrm{Q},\mathrm{K},\mathrm{V}\right)+{\mathrm{b}}_{\mathrm{Z}}\right).$$The output $\mathrm{Z}$ is then fed into a softmax layer to produce a probability distribution over potential threats, with the highest probability indicating the detected attack type (e.g., DDoS, Botnet, SQL Injection).

Implementation and training configuration

PyTorch was deployed to implement the CCTT which has a four-layer transformer encoder and contains eight attention heads per-layer along with the embedding dimension of 256. The model employes sinusoidal positional encoding, and domain-aware embedding to encode temporal and cross-domain context. The dropout was put at 0.2 in order to overcome overfitting. Optimizer used was Adam with the learning rate of 0.0001 and batch size of 64. The model was trained on the Adam optimizer to up to 25 epochs early stopping (patience = 5) and converged around the 16^th epoch. The categorical cross-entropy was used as the loss function, and it is appropriate because of many types of attacks that need to be classified. Input sequences were formed by 50 time-stepped observations which contained a combination of flow metadata, SDN state, and anomaly indicators. The training was performed in an NVIDIA A100 Graphics Processing Unit (GPU).

Policy optimization

The policy optimization component built into the SDMDC optimizes security configurations and operational parameters across cloud infrastructure to balance computation efficiency and threat detection accuracy. Employing the Lemurs Optimizer (LO) (Abasi et al., 2022), an advanced global optimization metaheuristic, the component dynamically tunes anomaly detection limits and resource allocation in response to real-time network dynamics and evolving security threats. During high-volume traffic times or attack scenarios, detection sensitivity is heightened to capture weak anomalies, whereas, in instances of low network usage, thresholds are decreased to decrease computational overhead. This adaptive system can scale effectively during high traffic while maintaining accurate threat detection.

The first step is for the LO algorithm to generate potential policies based on various detection thresholds and available resources. The effectiveness of each candidate’s identification and real-time resource consumption define its fitness. Lemur velocities and locations are adaptively updated to explore novel options and policy parameters are altered to improve performance according to traffic needs. The best candidate is updated frequently until an optimum policy is reached, guaranteeing optimal resource usage and threat detection in the multi-cloud system.

LO calculates the Feed-Forward (FF) to improve classifier accuracy, using a positive number to signify improvement. The FF measures classifier error reduction.

(7) $$fitness\left(x_i\right)={\displaystyle \frac{No.ofmisclassifiedinstances}{TotalNo.ofinstances}\ast 100.}$$

The LO employed for adaptive policy tuning in the SDMDC was configured with a population size of 30, and a maximum number of 100 iterations. The stopping rule was set at the maximum number of iterations or convergence on fitness value on three consecutive generations. The fitness function took a multi-objective score integrating policy decision latency, detection accuracy, and policy conflict rate. The optimization process encoded parameters such as flow rule weights, alert correlation thresholds, and controller path selection, which allowed it to tune dynamically across inter-cloud SDN segments.

Multi-cloud IDS gateways (MCIDS-G)

MCIDS-G refers to the centralized security nodes within the multi-cloud data layer. Within each cloud environment, such as AWS, Azure, or Google Cloud, the gateways continuously monitor and detect security risks in ingress, egress, and lateral traffic flows. There is a local IDS based on LSTM in every MCIDS-G (Alimi et al., 2022). It then sends security alerts to SDMDC for further investigation and regulation enforcement based on findings from its analysis of cloud traffic, with an emphasis on localized threats.

Every one of the cloud settings has the MCIDS-G as its principal security measure. Local IDS employ LSTM models to detect injection attacks (including SQL injection and command injection), data extraction efforts, botnet operations, and DDoS assaults on networks and the IoT. The LSTM-based IDS is highly effective at detecting patterns of assaults that occur over time, such as slow-rate DDoS attacks, progressive brute force offences, and gradual data breaches (Koroniotis & Moustafa, 2021). The MCIDS-G provides strong protection for cloud infrastructures by detecting and mitigating internal and external threats, including lateral infiltration.

The localized intrusion detection engine is the MCIDS-G component, which implements a two-layer LSTM architecture over PyTorch. Each of the model’s two layers had 128 hidden units, used ReLU activation, which was meant to learn nonlinear patterns in time. These modules process input sequences from the BoT-IoT dataset focusing on temporal features such as packet counts, flow duration, and byte intervals. Features selection was guided by temporal relevance (for LSTM) and cross-domain correlation (for CCTT), and all inputs were normalized prior to training. We trained with dropout of 0.3 in order to lessen overfitting. The Adam optimizer was used to optimize the model with the learning rate of 0.001, and the model was deployed with a batch size of 64. The loss function was chosen as Binary cross-entropy, which is applicable in the observation of the anomalies in binary form. Training was capped at 20 epochs with early stopping (patience = 5) to avoid overfitting. Input sequences had a length of 30 time steps, to show segments of ingress and egress flows in each of the cloud zones separately.

The feature selection relied on the extended CSE-CIC-IDS 2018 data containing both traditional flow-based features (e.g., total Fwd packets, flow duration, flag counts) and SDN-specific metadata (e.g. flow rules, controller-assigned policy tags, cloud domain IDs). We followed related work on ranking methods, like Lin et al. (2021), and chose the 30–40 highest ranked features that helped mostly to separate anomalies with classes in each cloud segment. The multivariate input was segmented using positional and domain embeddings to prepare for transformer-based processing.

Local IDS for egress traffic (LSTM-based detection)

Egress traffic, data leaving the cloud infrastructure, is also vital for detecting data exfiltration, malware communication, and insider threats. LSTM-based local IDS at the Egress Gateway continuously monitors outbound network flows for unusual patterns, such as massive data transfers or interactions from infected VMs. For example, when a vulnerable VM in Google Cloud initiates unauthorized data exfiltrations to an outside host containing sensitive information, the LSTM model detects and reports this anomaly. This report is routed to the SDMDC, which checks the traffic pattern methodically and validates the threat. Consequently, the SDMDC promptly updates the flow rules in the Google Cloud SDN controller to filter out the illegitimate egress traffic from the compromised VM and quarantine it to avoid further spread or illegitimate communication.

Egress Gateway detection for East-West traffic (lateral movement)

Other than hitting inbound and outbound traffic, the local IDS powered by LSTM conducts systematic inspection of sideways traffic, including intra-cloud communication among VMs, services, or applications in a single VPC or multiple VPCs. Lateral movement is a common strategy attackers use to pivot between affected resources within a shared cloud environment. For instance, if a threat actor gains entry into a VM within Azure and attempts to extend mobility to another service in the same VPC, the local IDS identifies abnormal communication patterns grouping the VMs, marking the traffic as a notable cybersecurity threat. The notification is immediately transmitted to the SDMDC, which dynamically alters the Azure SDN controller’s flow rules to limit further interaction between compromised and uncompromised VMs. In addition, the compromised VMs are immediately quarantined to isolate the breach and reduce the chance of additional escalations.

The LSTM operates on a sequential timeline, with $x_t$ representing the input instance (for example, network flow at time $t$) and $A$ representing the preserved memory of past traffic sequences, retaining important contextual characteristics. The weighted parameters $W$ are adjusted during training to capture relevant traffic patterns. Unlike typical Recurrent Neural Networks (RNNs), which suffer from gradient depletion or amplification when processing long sequences, LSTM mitigates these issues by utilizing a memory cell. This process enables LSTM to maintain and analyze long dependencies in network traffic and is critical for identifying complex, dynamic cyber threats in dynamic cloud environments, as illustrated in Fig. 3.

To control the flow of data inside the network, LSTM uses three primary gates: input, forget, and output. The forget gate controls the deletion of data according to historical traffic patterns. The sigmoid activation function is utilized by this gate and is defined as:

(8) $$f_E=\sigma \left(W_f{X}_t+b_f\right).$$The weights and biases are denoted as $W_f$ and $b_f$, respectively. The current input vector at time $t_i$, which combines the hidden state from the previous step with the current network sample, is represented by $X_t$.

The input gate determines the relevance of the current input traffic pattern to be added to the memory. This gate also uses sigmoid and $\mathrm{t}\mathrm{a}\mathrm{n}\mathrm{h}$ activation functions as follows:

(9) $$i_t=\sigma \left(W_i{X}_t+b_i\right)$$

(10) $$g_t=\mathrm{t}\mathrm{a}\mathrm{n}\mathrm{h}\left(W_g{X}_t+b_g\right).$$

$i_t$ and $g_t$ represent the influence of the present input data on the hidden state, which is used to determine whether to keep or discard fresh traffic data.

To control the output, the output gate updates the memory state $c_t$ as follows:

(11) $$c_t=f_t\cdot {\mathrm{c}}_{t-1}+{\mathrm{i}}_{\mathrm{t}}\cdot g_t.$$This ensures that only relevant information about the current traffic pattern is retained.

Finally, the output vector $h_{t_i}$, which represents the detected anomaly or normal behaviour at time $t$, is calculated as:

(12) $$o_t=\sigma \left(W_o{X}_t+b_o\right)$$

(13) $$h_t={\mathrm{o}}_t\cdot \mathrm{t}\mathrm{a}\mathrm{n}\mathrm{h}\left(c_t\right).$$

The local IDS facilitates real-time network traffic analysis, utilizing LSTM’s memory capabilities to recognize anomalous patterns such as DDoS or injection attacks based on historical traffic data.

The seamless interaction between the MCIDS-G and the SDMDC ensures that detected threats are identified locally and systematically across the entire multi-cloud infrastructure, leading to coordinated responses and real-time policy enforcement.

Results

Two benchmark datasets to evaluate the efficiency of the proposed SDMDC framework consist of the extended CSE-CIC-IDS2018 dataset (Kaggle, 2024) and the BoT-IoT dataset (Koroniotis et al., 2019). Table 1 shows how the 27,000 samples generated were distributed into seven classes of attacks over which the CCTT model was trained.

Likewise, the BoT-IoT dataset consists of 2,056 samples distributed across five unique classes, as outlined in Table 2.

Figures 4A, 4B depict the confusion matrices generated by the SDMDC model using a 70:30 split of Threat Response and Analysis System/Threat Evaluation and Scoring System (TRAS/TESS), while Figs. 4C, 4D show the corresponding precision-recall and Receiver Operating Characteristic (ROC) curves, confirming its strong multi-class classification performance.

To address class imbalance across multiple attack categories, stratified sampling was used during dataset splitting, ensuring proportional representation of minority classes in both training and test sets. Additionally, the model was trained using a categorical cross-entropy loss function, which supports multi-class classification and reduces the bias toward dominant classes.

Table 3 and Fig. 5 portray the overall intrusion detection outcomes of the SDMDC method. The experimental values emphasized that the SDMDC model correctly recognized all samples proficiently. With 70% TRAS, the SDMDC technique offers an average $acc{u}_{racy}$ of 98.32%, $price$ of 92.89%, $rec{a}_{ll}$ of 91.02%, $F_{score}$ of 91.89%, and MCC of 90.92%. Simultaneously, with 30% TESS, the SDMDC model provides an average $acc{u}_{racy}$ of 98.48%, price of 93.44%, $rec{a}_l$l of 91.72%, $F_{score}$ of 92.53%, and MCC of 91.65%.

Figure 6 shows the training and validation accuracy trend of the SDMDC method, with accuracy values monitored between 0 and 25 epochs. The outcome indicates a steady improvement in training and validation accuracy values, proving the SDMDC technique’s ability to optimize performance in successive iterations. Moreover, the training and validation accuracy values stay close to each other during the epochs, demonstrates better results with overfitting and generalization ability of the SDMDC system that guarantees accurate predictions on unseen data.

Figure 7 illustrates the training and validation loss curve of the SDMDC method, where loss values were calculated between 0 and 25 epochs. The chart indicates a declining trend in training and validation loss, highlighting the SDMDC system’s effectiveness in optimizing data fitting and generalization. The continuous reduction in loss values also supports the improved performance of the SDMDC model and its ability to enhance predictive accuracy with time.

A comparative analysis with state-of-the-art models is conducted in Table 4 and Fig. 8 to assess the performance of the SDMDC approach (Okey et al., 2022; Lin et al., 2021; Alzughaibi & Khediri, 2023; Wang et al., 2023). Baseline models were chosen because they have been evaluated previous on the same dataset (CSE-CIC-IDS2018) in order to allow benchmarking. The simulation results reveal that the CNN-based approach was not optimal, yielding the lowest classification accuracy. In contrast, the Enhanced Lightweight Temporal Convolutional Network-Based Intrusion Detection and Security Management System with Reinforcement Engine (ELTCNIDSMS-RE), Intrusion Detection and Intelligent Network Traffic using Machine Learning and Deep Learning (IDINT-MLDL), Multilayer Perceptron optimized with Particle Swarm Optimization (MLP-PSO), and Long Short-Term Memory with Attention Mechanism (LSTM+AM) models exhibited moderately improved and comparable performance. Meanwhile, the AdaBoost and Deep Neural Network (DNN) models demonstrated to surpass previous models. Nevertheless, the SDMDC technique demonstrates superior performance with enhanced $acc{u}_{racy}$ of 98.48%, $prc{e}_n$of 93.44%, $rec{a}_{ll}$ of 91.72%, and $F_{score}$ of 92.53%. Therefore, the SDMDC approach can be used to improve security in the multi-cloud environment.

Figure 9 illustrates real-time traffic behavior under diverse cyber-attack scenarios in an SDN-enabled multi-cloud environment, employing the Cross Cloud Threat Transformer (CCTT) model for in-depth traffic flow assessment. The graph illustrates fluctuations in traffic volume, legitimate requests, and multiple attack vectors, including DDoS, Botnet, BF, Infiltration, and Web Attacks. DDoS attacks generate significantly higher traffic volumes, highlighting their disruptive impact compared to other threats. This fluctuations emphasize the need for real-time, adaptive security mechanisms within the proposed framework. The dynamic security policy management enabled by the SDN Multicloud Defense Controller (SDMDC) ensures uniform, centralized detection and mitigation of these evolving threats.

In our suggested SDN-enabled multi-cloud security framework, real-time traffic analysis and anomaly detection are key elements in maintaining a consistent security posture across multi-cloud heterogeneous environments. Figure 10 illustrates traffic variations and anomalies identified on three cloud platforms (Cloud 1, Cloud 2, and Cloud 3).

The red-highlighted areas of the graph represent anomalous traffic patterns accurately recognized by the CCTT model. These patterns occurred in the 50- and 80-time intervals. The discovery also demonstrates the framework’s ability to detect potential threats, such as DDoS attacks, in real-time. The SDMDC ensures that security rules are consistently implemented by providing centralized management. Distributed MCIDS-G provide adaptive responses on a per-cloud basis and mitigate threats locally. Quick and precise reactions to anomalies are made possible by this architecture’s efficient examination of traffic patterns across several clouds. Notably, threat detection accuracy is significantly improved with CCTT and other Deep Learning models, and flexibility and scalability are made possible with the incorporation of SDN. Combined, these components form a robust defensive approach for the whole multi-cloud environment, strengthening defenses against external intrusions, insider threats and lateral movement inside the cloud.