Network security situation awareness method and system based on cloud computing

Abstract

The application provides a cloud computing-based network security situation awareness method and system, and relates to the technical field of cloud computing network security. First, an original security event stream composed of multiple security event units carrying timestamp markers is received from a cloud network edge security probe node. Then, the original security event stream is subjected to security event context association reconstruction processing to generate a security event association chain set. Next, the security event association chain set is subjected to security threat feature extraction and fusion processing to generate a fusion threat feature vector. Then, the fusion threat feature vector is input into a pre-constructed threat evolution situation deduction model to generate a threat evolution situation deduction result. Finally, cloud-native adaptive protection instructions are generated according to the threat evolution situation deduction result and are distributed to cloud security execution nodes. The application can comprehensively and accurately perceive the cloud network security situation and realize dynamic and adaptive cloud network security protection.

Description

Technical Field

[0001] This invention relates to the field of cloud computing network security technology, and more specifically, to a cloud-based network security situation awareness method and system. Background Technology

[0002] With the rapid development of cloud computing, cloud networks are becoming increasingly large and complex, storing and processing massive amounts of critical business data and sensitive information. This makes cloud networks a prime target for cyberattacks. Traditional network security measures primarily focus on the detection and response to individual security incidents, such as simple filtering of network traffic through firewalls or using intrusion detection systems to identify known attack patterns.

[0003] However, security incidents in cloud networks often exhibit discreteness and complexity. A single security incident may only be one link in an attack chain, making it difficult to fully reflect the entire attack landscape. Moreover, the dynamic and virtualized nature of cloud environments, along with the tight coupling between different cloud components, allows attackers to leverage these characteristics for lateral movement and privilege escalation within the cloud network. Traditional protection methods are ill-suited to effectively counter these complex attack behaviors.

[0004] Furthermore, most existing security situation awareness methods lack in-depth mining of security event context information, making it difficult to accurately grasp the potential correlation logic between security events, extract comprehensive and representative security threat characteristics, and thus unable to accurately deduce the evolution of security threats or generate effective adaptive protection commands to ensure the security of cloud networks. Summary of the Invention

[0005] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a network security situation awareness method based on cloud computing, the method comprising: Receive raw security event streams sent by security probe nodes deployed at the edge of the cloud network. The raw security event streams consist of multiple security event units carrying timestamps. Each security event unit includes the event source address, the event destination address, the event protocol type, and the event payload content. The original security event stream is subjected to security event context association reconstruction processing, which associates and combines discrete security event units with potential association logic in the original security event stream to generate a security event association chain set consisting of multiple security event association chains; The security threat feature extraction and fusion process is performed on the security event association chain set. The internal event interaction mode features and external cloud environment coupling features of each security event association chain are extracted, and the internal event interaction mode features and external cloud environment coupling features are fused based on their complementarity to generate a fused threat feature vector corresponding to each security event association chain. The fused threat feature vector corresponding to each security event association chain is input into a pre-constructed threat evolution situation inference model. The threat evolution situation inference model simulates the lateral movement and privilege escalation path of attackers in the cloud environment, infers the potential diffusion direction and evolution stage of security threats in the cloud network topology, and generates the threat evolution situation inference result corresponding to each security event association chain. Based on the threat evolution scenario projection results, the application programming interface of the cloud computing management platform is invoked to generate cloud-native adaptive protection instructions that match the threat evolution stage. The cloud-native adaptive protection instructions are then sent to the corresponding cloud security execution nodes. The cloud-native adaptive protection instructions include micro-segmentation policies for cloud workloads, access control rules for cloud network traffic, and dynamic authentication policies for cloud identity credentials.

[0006] Furthermore, embodiments of the present invention also provide a cloud computing-based network security situation awareness system, comprising: A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the aforementioned cloud-based network security situation awareness method by executing the machine-executable instructions.

[0007] In another aspect, embodiments of the present invention also provide a computer program product, the computer program product including machine-executable instructions, the machine-executable instructions being stored in a computer-readable storage medium, the processor of the cloud-based network security situation awareness system reading the machine-executable instructions from the computer-readable storage medium, the processor executing the machine-executable instructions, causing the cloud-based network security situation awareness system to execute the aforementioned cloud-based network security situation awareness method.

[0008] Based on the above, by receiving the raw security event stream sent by security probe nodes deployed at the edge of the cloud network, the system performs security event context association reconstruction processing on the raw security event stream, associating and combining discrete security event units to generate a set of security event association chains. This effectively uncovers the potential correlation logic between security events. The system then performs security threat feature extraction and fusion processing on the security event association chain set, extracting and fusing internal event interaction pattern features and external cloud environment coupling features to generate a fused threat feature vector. This vector characterizes the security threat from multiple dimensions, improving the effectiveness and representativeness of the features. Inputting the fused threat feature vector into a pre-built threat evolution scenario simulation model can simulate the attacker's behavior path in the cloud environment, predict the potential spread direction and evolution stage of security threats in the cloud network topology, and generate cloud-native adaptive protection instructions matching the threat evolution stage based on the threat evolution scenario simulation results. These instructions are then distributed to the corresponding cloud security execution nodes, achieving dynamic and adaptive protection of cloud network security. This effectively addresses complex and ever-changing attack behaviors in the cloud network, significantly improving the security and reliability of the cloud network. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the execution flow of the cloud-based network security situation awareness method provided in an embodiment of the present invention.

[0010] Figure 2 This is a schematic diagram of exemplary hardware and software components of a cloud-based network security situation awareness system provided in an embodiment of the present invention. Detailed Implementation

[0011] Figure 1 This is a flowchart illustrating a cloud-based network security situation awareness method according to an embodiment of the present invention, which will be described in detail below.

[0012] Step S110: Receive the raw security event stream sent by the security probe node deployed at the edge of the cloud network. The raw security event stream consists of multiple security event units carrying timestamps. Each security event unit includes the event source address, the event destination address, the event protocol type, and the event payload content.

[0013] In this embodiment, multiple security probe nodes deployed at the edge of the cloud network continuously monitor and capture network data traffic passing through them. Each security probe node encapsulates a network data packet or detects a specific system log trigger into a security event unit after capturing it.

[0014] Specifically, taking a virtual private cloud environment running containerized microservices as an example, assume that the environment contains hundreds of virtual machine instances and container groups. Security probes deployed on the virtual switch ports of each physical host machine capture all incoming and outgoing data packets in real time. For each captured data packet, the probe extracts its 5-tuple information and data packet payload.

[0015] The event source address is recorded as the originating Internet Protocol (IP) address of the data packet, such as a floating IP address from a container group; the event destination address is recorded as the destination IP address of the data packet, such as an intranet address pointing to a cloud database instance; the event protocol type is recorded as a transport layer protocol, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Internet Control Message Protocol (ICS), and further refined to an application layer protocol, such as Hypertext Transfer Protocol Security (HTTP) or Structured Query Language (SCL); the event payload contains application layer data after removing the network layer and transport layer headers from the transport layer and above, such as the Uniform Resource Locator (URL), request header, and body of an HTTP request, or a SCL query statement. Each security event unit is appended with a high-precision timestamp upon generation, derived from the network time protocol synchronization clock of the host machine where the probe resides, to ensure global time consistency. All security probe nodes aggregate their generated raw security event streams in real time to the security situation awareness processing center at the central cloud platform via an encrypted message queue, such as a distributed messaging system encrypted with a transport layer security protocol.

[0016] Step S120: Perform security event context association reconstruction processing on the original security event stream, associate and combine discrete security event units with potential association logic in the original security event stream to generate a security event association chain set composed of multiple security event association chains.

[0017] Step S121: Perform network segment aggregation analysis on the original security event flow for the event source address and the event target address, and calculate the mask matching degree of the network segment to which the event source address belongs and the mask matching degree of the network segment to which the event target address belongs for any two security event units.

[0018] After receiving the aggregated raw security event stream at the security situation awareness processing center, the streaming data is first buffered into micro-batch processing windows, such as windows with a fixed time length of 5 seconds or windows with a fixed number of events of 10,000. For all security event units within the window, their event source address and event destination address are parsed; both addresses are Internet Protocol version 4 or version 6 addresses. Next, the subnetting information for all current virtual private clouds is obtained from the cloud platform's network configuration management database. This subnetting information includes the network segment address and corresponding subnet mask length for each subnet. For the event source address of a security event unit, all subnets are traversed, and a bitwise AND operation is calculated between this address and each subnet segment address. This result is then matched with the subnet mask to determine its subnet identifier. Similarly, the same subnet attribution calculation is performed on its event destination address. For any two security event units, compare whether their source address subnet identifiers are identical. If they are identical, the source address mask match score is recorded as 1, indicating a perfect match; if they are not identical, the source address mask match score is recorded as 0, indicating a complete mismatch. Perform the same comparison on the event destination address to obtain the destination address mask match score. This step aims to identify security event unit pairs whose sources originate from the same internal subnet or whose destinations point to the same external subnet.

[0019] Step S122: Based on the mask matching degree, identify security event units whose event source addresses belong to the same internal subnet and whose event target addresses point to the same external service address, and mark the security event units as potential related event groups.

[0020] Next, based on the source address mask matching degree and destination address mask matching degree calculated in step S121, security event units whose source addresses belong to the same internal subnet identifier and whose destination addresses point to the same external service address are selected. Here, the external service address can be a specific public Internet Protocol address (IPA) or an address resolved from a hosting service domain name provided by a cloud platform. For example, multiple security event units from the same virtual machine subnet may all have their destination addresses pointing to the same IPA corresponding to the Uniform Resource Locator (URL) of the same cloud object storage service. These security event units that meet the above conditions are extracted from the original security event stream and logically grouped into a potentially related event group. This potentially related event group represents a series of activities that may originate from the same internal source and target the same external objective.

[0021] Step S123: Perform serialization and sorting processing on the timestamp markers within the potential associated event group to generate a sequence of security event units ordered by time, and calculate the event protocol type conversion probability of adjacent security event units in the security event unit sequence.

[0022] For each potentially related event group marked in step S122, all security event units within it are sorted from earliest to latest according to their respective timestamps, forming an ordered sequence of security event units. Then, this sequence is scanned, and for each pair of adjacent security event units, their event protocol types are extracted. For example, the event protocol types of adjacent units might be Secure Shell protocol and File Transfer protocol, respectively. To calculate the probability of a transition between these two protocol types, a protocol type transition probability matrix is ​​pre-constructed. This matrix is ​​built based on massive amounts of historical security event data, statistically analyzing the frequency of transitions from one protocol type to another in all historical event sequences, and normalizing the transition frequencies from each source protocol type to all target protocol types to obtain probability values. Therefore, for the current pair of adjacent units, by querying this protocol type transition probability matrix, the probability value of a transition from the event protocol type of the first event unit in the pair to the event protocol type of the second event unit can be obtained.

[0023] Step S124: Based on the event protocol type conversion probability, determine whether there is an event sequence segment in the security event unit sequence that converts from a low-privilege detection protocol to a high-privilege control protocol.

[0024] Based on the event protocol type conversion probabilities of adjacent event units calculated in step S123, and combined with a preset protocol permission level mapping table, which categorizes common network protocols into low-privilege detection classes (e.g., Internet Control Message Protocol, Simple Network Management Protocol) and high-privilege control classes (e.g., Secure Shell Protocol, Remote Desktop Protocol), the entire security event unit sequence is traversed to identify all consecutive sub-sequence segments that gradually convert from low-privilege detection protocol types to high-privilege control protocol types. Specifically, if the event protocol type of the starting event unit of a sub-sequence segment belongs to the low-privilege detection class, while the event protocol type of the ending event unit belongs to the high-privilege control class, and the conversion probabilities of all adjacent conversions within the segment are higher than a preset conversion probability threshold (e.g., a threshold set to 0.6), then the sequence segment is determined to conform to an attack behavior pattern from detection to control.

[0025] Step S125: Extract event sequence fragments with protocol conversion, analyze the event payload content of each security event unit in the event sequence fragment, and identify whether the same attack tool fingerprint or the same command and control instructions exist in the event payload content.

[0026] For each event sequence segment with protocol conversion identified in step S124, the event payload content of each security event unit within the segment is extracted. The event payload content may contain various forms of data, such as plaintext, binary data, compressed data, etc. Decoding and parsing operations are performed on each payload content. For example, if the protocol type is Hypertext Transfer Protocol (HTTP), the Uniform Resource Locator (URI) and HTTP header are parsed; if the protocol type is Domain Name System (DNS), the query domain name is parsed. From the parsed payload, static features are extracted, such as specific user agent strings, specific URI path patterns, specific binary file hash values, and dynamic behavioral features, such as specific instruction strings commonly found in command and control channels. Then, the features extracted from all event units within the segment are compared pairwise to calculate their similarity. For example, the edit distance between strings appearing in two payloads is calculated; if the edit distance is less than a preset threshold, they are considered to contain the same attack tool fingerprint or command and control instructions.

[0027] Step S126: Merge security event unit sequence fragments with the same attack tool fingerprint or the same command and control instructions to form an initial security event association chain candidate set.

[0028] Based on the identification results of step S125, multiple security event unit sequence fragments with the same attack tool fingerprint or the same command and control instructions are merged according to their chronological order. The merging operation involves concatenating the fragments end-to-end to form a longer security event unit sequence. For example, if a probe fragment and a control fragment are temporally consecutive and both detect the same specific command and control instruction string in their payloads, these two fragments are merged into a new sequence. After scanning and merging all fragments, multiple independent long sequences are obtained, each sequence being an initial candidate security event association chain. All these candidate chains constitute the initial security event association chain candidate set.

[0029] Step S127: Calculate the temporal density coherence score for each candidate chain in the candidate set of security event association chains. The temporal density coherence score is obtained by evaluating the uniformity of the timestamp intervals of security event units within the candidate chain.

[0030] For each candidate chain in the initial candidate set generated in step S126, the timestamps of all security event units within it are extracted to form a timestamp sequence. The time interval sequence between adjacent timestamps in this sequence is calculated. Then, the mean and standard deviation of these time intervals are calculated. The time density coherence score is defined as the ratio of the mean to the standard deviation, i.e., the mean divided by the standard deviation. The larger the ratio, the more uniform the distribution of time intervals, indicating that the events exhibit a more regular rhythm in time, which is consistent with the behavioral characteristics of automated attack tools; conversely, if the ratio is small, it indicates that the time intervals are inconsistent, possibly caused by manual operation or random triggering, resulting in low coherence.

[0031] Step S128: Calculate the semantic payload coherence score of each candidate chain in the candidate set of security event association chains. The semantic payload coherence score is represented by the average cosine similarity between vectors of the event payload content of all security event units in the candidate chain after being encoded by a natural language processing model.

[0032] For the same candidate chain, the event payload content of each security event unit within it is preprocessed and then input into a pre-trained natural language processing (NLP) encoding model. This NLP encoding model can employ a transducer-based bidirectional encoder representation architecture to encode each payload content into a fixed-length semantic vector, such as a 768-dimensional vector. After obtaining the semantic vectors corresponding to all event units, the cosine similarity between each pair of these vectors is calculated. The cosine similarity is calculated by dividing the dot product of the two vectors by the product of their magnitudes. Finally, the average of all pairwise similarities is used as the semantic payload coherence score for the candidate chain. A higher semantic payload coherence score indicates that the payload content of each event within the chain is more semantically similar, suggesting that they may be executing the same attack logic.

[0033] Step S129: The temporal density coherence score and the semantic payload coherence score are weighted and fused to obtain the comprehensive association confidence of each candidate chain, and the candidate chains are screened according to the preset comprehensive association confidence threshold.

[0034] For each candidate chain, the temporal density coherence score calculated in step S127 is denoted as variable A, and the semantic load coherence score calculated in step S128 is denoted as variable B. These two scores are weighted and summed using a preset weighting coefficient alpha to obtain the comprehensive association confidence score C. The calculation logic is: C equals alpha multiplied by A plus the number within parentheses minus the alpha multiplied by B. The value of alpha is between 0 and 1, used to balance the importance of temporal coherence and semantic coherence in association judgment. Next, the calculated comprehensive association confidence score C is compared with a preset confidence threshold T. If C is greater than or equal to T, the candidate chain is retained; if C is less than T, the candidate chain is removed from the candidate set.

[0035] Step S1210: Output the candidate chains with a comprehensive association confidence level higher than the comprehensive association confidence level threshold as the final security event association chains, and all the final security event association chains constitute the security event association chain set.

[0036] Following the screening in step S129, all remaining candidate chains are determined as the final security event association chains. These final security event association chains are then aggregated to form a structured set, known as the security event association chain set. Each association chain in this set represents a group of security events with high spatiotemporal and semantic relevance; they are likely traces left from different stages of the same cyberattack. This completes the contextual reconstruction of the original security event flow.

[0037] Step S130: Perform security threat feature extraction and fusion processing on the set of security event association chains, extract the internal event interaction pattern features and external cloud environment coupling features of each security event association chain, and fuse them based on the complementarity of the internal event interaction pattern features and external cloud environment coupling features to generate a fused threat feature vector corresponding to each security event association chain.

[0038] Step S131: Parse each security event association chain, extract the event protocol type sequence of all security event units in the chain, perform one-hot encoding on the event protocol type sequence, and generate a protocol type one-hot encoded vector.

[0039] For each chain in the set of security event association chains, first traverse all the security event units it contains, and extract the event protocol type of each unit in turn. Assuming there are M possible protocol types in a cloud environment, a mapping table is pre-built from each protocol type to a unique index. For a chain containing N event units, its protocol type sequence is converted into an N x M matrix. Each row of this matrix corresponds to an event unit, and in that row, only the position of the protocol type index corresponding to that event unit has a value of 1, while the other M-1 positions have values ​​of 0. This matrix is ​​the protocol type one-hot encoded vector, with a shape of N rows and M columns.

[0040] Step S132: Perform sliding window convolution processing on the one-hot encoding vector of the protocol type to extract the local transfer patterns of the protocol type sequence under different time windows, and perform max pooling on the feature map obtained after convolution to generate the protocol transfer pattern feature vector.

[0041] The protocol type one-hot encoded vector obtained in step S131 is treated as a two-dimensional image or time series data and processed using a one-dimensional convolutional neural network. Multiple one-dimensional convolutional kernels of different sizes are designed, for example, kernel sizes of 3, 5, and 7, with a certain number of kernels for each size, such as 64 kernels per size. Each convolutional kernel slides along the time dimension of the protocol type sequence, performing convolution operations with the one-hot encoded vector within the window to extract the protocol combination patterns within the local window. The output of the convolution operation is called a feature map. For each convolutional kernel, a feature map sequence of length N minus the kernel size plus 1 is generated. Then, max pooling is applied to each feature map sequence, taking the maximum value in the entire sequence as the output of that convolutional kernel. The max pooling outputs of all convolutional kernels are concatenated to form a one-dimensional vector, which is the protocol transition pattern feature vector. This protocol transition pattern feature vector captures the typical transition patterns of protocol types in the association chain within a short time window.

[0042] Step S133: Extract the timestamp sequence of each security event association chain, calculate the time interval sequence between adjacent security event units, perform discrete Fourier transform on the time interval sequence, extract the amplitude of the main frequency component of the time interval sequence in the frequency domain, and generate the attack rhythm frequency domain feature vector.

[0043] For the same security event chain, extract the timestamps of all event units to form a timestamp sequence T1, T2, ..., Tn. Calculate the difference between adjacent timestamps to obtain the time interval sequence delta T1, delta T2, ..., delta Tn-1, where delta Ti equals Ti plus 1 minus Ti. Treat this time interval sequence as a discrete-time signal and perform a Discrete Fourier Transform (DFT) to convert the signal from the time domain to the frequency domain. The result of the DFT is a series of complex numbers, each corresponding to the amplitude and phase of a frequency component. Extract the top K frequency components with the largest amplitudes from the transform result (e.g., K = 5), and record the amplitude values ​​corresponding to these K frequency components. Arrange these amplitude values ​​in ascending order of frequency to form a K-dimensional vector, which is the attack rhythm frequency domain feature vector. This attack rhythm frequency domain feature vector quantifies the periodic or rhythmic characteristics of the attack event over time.

[0044] Step S134: Obtain the cloud resource identifiers involved in each security event association chain, wherein the cloud resource identifiers include the image identifier of the virtual machine, the workload identifier of the container, and the instance identifier of the cloud database.

[0045] The process involves parsing the source and destination addresses of all security event units within each security event chain. By querying the cloud platform's resource management database, these Internet Protocol (IP) addresses are mapped back to specific cloud resource instances. For example, a source address might correspond to a virtual machine instance with a specific image identifier; a destination address might correspond to a container group with a specific workload identifier, or a cloud database with a specific instance identifier. For each chain, the identifiers of all involved cloud resource instances are collected, deduplicated, and formed into a set representing the resource scope reached by this attack chain in the cloud environment.

[0046] Step S135: Based on the cloud resource identifier, query the cloud resource configuration management database to obtain the security baseline configuration information and historical vulnerability disclosure records of the corresponding cloud resource, and generate a cloud resource security context feature vector.

[0047] Based on the set of cloud resource identifiers obtained in step S134, a query is initiated to the cloud platform's configuration management database. For each resource identifier, its current security baseline configuration information is obtained, such as the operating system version of the virtual machine image, the list of installed security patches, the base image version of the container image, the list of open network ports, and the security group rules it belongs to. Simultaneously, historical vulnerability disclosure records related to the resource are queried, including vulnerability IDs, vulnerability severity scores, and vulnerability disclosure dates. The information obtained above is then structured and encoded. For example, the operating system version is mapped to a category vector, the list of open ports is encoded into a multi-hot vector, and the vulnerability severity score is segmented and quantified. Finally, the encoded information corresponding to all resources is aggregated, for example, by averaging or concatenating, to form a fixed-length vector, which is the cloud resource security context feature vector. This cloud resource security context feature vector reflects the security status of the resource itself involved in the attack.

[0048] Step S136: Obtain the event source address and event destination address of each security event association chain, query the cloud network topology relationship graph, calculate the shortest network path hop count of the event source address and event destination address in the topology graph and the set of network device types traversed by the path, and generate a network topology reachability feature vector.

[0049] For the same security event chain, for each event unit, its source address and destination address are extracted. The current virtual network topology graph is obtained from the cloud platform's network topology management service. Nodes represent resources such as virtual machines, containers, and load balancers, and edges represent virtual network connections between them, such as routing rules within a virtual private cloud and access allowed by security groups. For each pair of source and destination addresses, the number of edges (hops) along the shortest path from the source node to the destination node is calculated at the graph theory level. Simultaneously, the types of intermediate network devices along this shortest path are recorded, such as virtual routers, virtual firewalls, and software-defined network switches. These device types are encoded to form a type set. Finally, for the entire chain, the hop counts of all event units are statistically analyzed, such as calculating the average and maximum hop counts. All sets of network device types that have appeared are merged and encoded to generate a network topology reachability feature vector. This network topology reachability feature vector describes the propagation distance and path characteristics of the attack flow in the cloud network.

[0050] Step S137: Concatenate the protocol transfer mode feature vector, attack rhythm frequency domain feature vector, cloud resource security context feature vector, and network topology reachability feature vector to form an initial concatenated feature vector.

[0051] The protocol transfer mode feature vector generated in step S132 is denoted as vector P, with dimension Dp. The attack rhythm frequency domain feature vector generated in step S133 is denoted as vector F, with dimension Df. The cloud resource security context feature vector generated in step S135 is denoted as vector R, with dimension Dr. The network topology reachability feature vector generated in step S136 is denoted as vector T, with dimension Dt. These four vectors are sequentially concatenated along the feature dimensions to form a new one-dimensional vector, denoted as vector U, with dimensions Dp + Df + Dr + Dt. This vector U is the initial concatenated feature vector, which integrates multi-source heterogeneous information from the internal patterns of attack behavior and the external environment.

[0052] Step S138: Construct a feature interaction layer with a multi-head attention mechanism, input the initial concatenated feature vector into the feature interaction layer, calculate the internal interaction attention weight between the protocol transfer mode feature vector and the attack rhythm frequency domain feature vector, and at the same time calculate the external interaction attention weight between the cloud resource security context feature vector and the network topology reachability feature vector.

[0053] A multi-head attention mechanism module is constructed. First, the initial concatenated feature vector U is segmented according to its original components to recover vectors P, F, R, and T. Two sets of attention calculations are defined. The first set is used to calculate the internal interaction, i.e., the association between vectors P and F. Using vector P as the query and vector F as the key and value, attention weights are calculated using a scaled dot product attention mechanism. Specifically, a linear transformation is performed on vector P to obtain the query matrix, and a linear transformation is performed on vector F to obtain the key and value matrices. The dot product of the query matrix and the key matrix is ​​calculated, divided by a scaling factor, and then a soft maximization function is applied to obtain the attention weight matrix. The elements in this attention weight matrix represent the degree of correlation between each dimension of vector P and each dimension of vector F. Similarly, the second set is used to calculate the external interaction, i.e., the association between vectors R and T. Using the same scaled dot product attention mechanism, vector R is used as the query and vector T as the key and value, and the external interaction attention weight matrix is ​​calculated. Multi-head attention means performing the above calculations multiple times, each time using different linear transformation parameters, and finally concatenating the outputs of all heads.

[0054] Step S139: Based on the internal interaction attention weight, the protocol transfer mode feature vector and the attack rhythm frequency domain feature vector are weighted and summed to generate internal event interaction mode features; based on the external interaction attention weight, the cloud resource security context feature vector and the network topology reachability feature vector are weighted and summed to generate external cloud environment coupling features.

[0055] Using the internal interaction attention weight matrix calculated in step S138, the vector F, i.e., the value vector, is weighted and summed. Specifically, the attention weight matrix is ​​multiplied by the linearly transformed vector F, and the result is then subjected to another linear transformation to generate a vector, denoted as the internal event interaction pattern feature vector, H_internal. This vector integrates protocol transition patterns and attack rhythm frequency domain features, highlighting the information related to the two. Similarly, using the external interaction attention weight matrix, the vector T is weighted and summed and linearly transformed to generate the external cloud environment coupling feature vector, denoted as H_external. This vector integrates cloud resource security context and network topology reachability features, reflecting the coupling relationship between attack behavior and the cloud environment.

[0056] Step S1310: Input the internal event interaction pattern features and the external cloud environment coupling features into the feature fusion gating unit. The feature fusion gating unit calculates the fusion gating coefficients of the internal event interaction pattern features and the external cloud environment coupling features based on a learnable weight matrix. The fusion gating coefficients are used to perform weighted fusion of the internal event interaction pattern features and the external cloud environment coupling features, and finally outputs the fused threat feature vector.

[0057] A feature fusion gating unit is constructed. This feature fusion gating unit contains a learnable weight matrix W_gate and a bias vector b_gate. First, the internal event interaction pattern feature vector H_internal and the external cloud environment coupling feature vector H_external are concatenated to form a vector H_concat. Then, H_concat is input into a fully connected layer with an output dimension of 2. The gating logic value is calculated as H_concat multiplied by W_gate plus b_gate. Next, a soft maximization function is applied to these two gating logic values ​​to obtain two coefficients that sum to 1, denoted as gating coefficient alpha1 and gating coefficient alpha2, respectively. Alpha1 corresponds to the weights of the internal event interaction pattern features, and alpha2 corresponds to the weights of the external cloud environment coupling features. Finally, the original feature vectors are weighted and summed using these two coefficients to obtain the final fused threat feature vector V_threat, which is calculated as alpha1 multiplied by H_internal plus alpha2 multiplied by H_external. The vector V_threat dynamically balances the attack's internal behavioral patterns with information from the external environment.

[0058] Step S140: Input the fused threat feature vector corresponding to each security event association chain into the pre-constructed threat evolution situation inference model. The threat evolution situation inference model simulates the lateral movement and privilege escalation path of attackers in the cloud environment, infers the potential diffusion direction and evolution stage of security threats in the cloud network topology, and generates the threat evolution situation inference result corresponding to each security event association chain.

[0059] Step S141: Construct the input layer of the threat evolution situation inference model. The input layer receives the fused threat feature vector and performs linear transformation and nonlinear activation processing on the fused threat feature vector to generate initial hidden state features.

[0060] First, a threat evolution situation inference model is constructed, which is a composite model integrating recurrent neural networks and graph neural networks. The input layer of the threat evolution situation inference model is designed to receive the fused threat feature vector V_threat output from step S1310, and the dimension of the fused threat feature vector is denoted as D_v. The input layer consists of a fully connected layer containing a trainable weight matrix W_input and a bias vector b_input. When V_threat is input into this layer, it first undergoes a linear transformation to obtain an intermediate vector Z, calculated as V_threat multiplied by W_input plus b_input, where the dimension of Z is the predefined hidden state dimension D_h. Then, a nonlinear activation function, such as the hyperbolic tangent function, is applied to Z to obtain the final initial hidden state feature h0, calculated as tanh(Z). This h0 captures the comprehensive information of the attack chain at the current time step.

[0061] Step S142: Input the initial hidden state features into the sequence memory module of the threat evolution situation inference model. The sequence memory module adopts a gated cyclic unit structure to simulate the evolution process of threat features in the time dimension, iteratively update the hidden state features, and generate a hidden state feature sequence containing temporal dependencies.

[0062] The initial hidden state feature h0 generated in step S141 is used as the initial state of the sequence memory module. The sequence memory module adopts a gated recurrent unit structure, which is a variant of a recurrent neural network. Although the attack event chain itself is a discrete set of events, its inherent development process has temporal logic. The model simulates the above temporal evolution through iterative loops. At each virtual time step t, the model receives the input of the current step, but since one association chain corresponds to one fused feature vector, h0 is used as the input state of the first time step. Then, the gated recurrent unit controls the flow of information through update gates and reset gates. The update gate determines how much information from the previous time step can be retained to the current time step, and the reset gate determines how to combine the new input with the previous memory. Through the iterative operation of the gated recurrent unit, a series of hidden states h1, h2, ..., ht are obtained, where t is the preset number of simulation steps. The hidden state at each step contains the threat evolution information up to that step. The sequence of the above hidden states, i.e., the hidden state feature sequence, is denoted as H_seq.

[0063] Step S143: Extract the hidden state features of the last time step from the hidden state feature sequence as the state summary features of the current threat evolution.

[0064] For the hidden state feature sequence H_seq generated in step S142, i.e., h1, h2, ..., ht, extract the last hidden state ht from the sequence. This ht has undergone cyclic iterations through all preset virtual time steps, and theoretically aggregates the abstract information of the entire evolution process. It is regarded as a compact summary of the threat evolution state at the current moment, denoted as the state summary feature vector S_state.

[0065] Step S144: Input the state summary features into the lateral movement inference branch of the threat evolution situation inference model. The lateral movement inference branch consists of multiple fully connected layers. Based on the state summary features, predict the target cloud resource type and corresponding network service port that the attacker may attempt to move laterally next, and generate a lateral movement inference vector.

[0066] Construct a lateral movement inference branch. This branch takes the state summary feature vector S_state as input. The input first passes through one or more fully connected hidden layers, such as two hidden layers, each containing several neurons, and uses a linear rectified function as the activation function to extract higher-order features. Finally, it connects to an output layer. The design of this output layer needs to correspond to the prediction task: simultaneously predicting the target cloud resource type and network service port. Therefore, the output layer can be designed as two parallel sub-layers. One sub-layer uses a soft-maximization activation function and outputs a probability distribution representing the probability that the attacker's next lateral movement target belongs to various cloud resource types, such as virtual machines, containers, serverless functions, cloud databases, etc. The other sub-layer also uses a soft-maximization activation function and outputs a probability distribution representing the probability that the attacker's next attack is various network service ports, such as port 22 of Secure Shell Protocol, port 3389 of Remote Desktop Protocol, and port 443 of Hypertext Transfer Protocol Security Protocol. These two probability distribution vectors are concatenated to form a one-dimensional vector, which is the lateral movement inference vector L_movement.

[0067] Step S145: Input the state summary features into the privilege escalation inference branch of the threat evolution situation inference model. The privilege escalation inference branch is composed of multiple fully connected layers. Based on the state summary features, predict the privileges that the attacker has currently obtained and the privilege escalation techniques that may be attempted next, and generate a privilege escalation inference vector.

[0068] The privilege escalation inference branch is constructed similarly to the lateral movement inference branch. The input is also a state summary feature vector S_state, which undergoes feature transformation through multiple fully connected hidden layers. The output layer is also designed as two parallel sub-layers. The first sub-layer predicts the privilege level an attacker may currently possess, such as ordinary user privileges, administrator privileges, root privileges, etc., outputting a probability distribution for the privilege level. The second sub-layer predicts the privilege escalation techniques the attacker might attempt next, such as exploiting operating system kernel vulnerabilities, exploiting misconfigured container runtimes, stealing cloud service credentials, etc., outputting a probability distribution for various techniques. These two probability distribution vectors are concatenated to form a one-dimensional vector, which is the privilege escalation inference vector P_elevation.

[0069] Step S146: Obtain a real-time topology snapshot of the current cloud environment. The topology snapshot includes the network connection relationships and node attribute information between all active cloud resource nodes.

[0070] Before starting the simulation, a snapshot of the cloud environment topology at the current moment needs to be obtained from the cloud platform's resource management and network monitoring services. This snapshot is a graph data structure. Each node in the graph corresponds to an active cloud resource instance, including all virtual machines, container groups, cloud database instances, load balancers, etc. Each node is accompanied by an attribute vector containing detailed information about the node, such as cloud resource type, instance identifier, security group identifier, list of open ports, operating system or runtime version, historical vulnerability score, etc. Each edge in the graph represents a network connectivity reachability between two nodes. The direction of the edge can be unidirectional or bidirectional, depending on the security group rules and network access control lists. Edge attributes can include bandwidth, latency, protocol limits, etc.

[0071] Step S147: Input the lateral movement inference vector, the privilege escalation inference vector, and the topology snapshot into the graph diffusion simulation module of the threat evolution situation inference model. The graph diffusion simulation module abstracts the cloud environment into a graph structure, where nodes represent cloud resources and edges represent network connections. The attacker's current inferred location is taken as the initial infected node, and the lateral movement inference vector and the privilege escalation inference vector are used as the basis for the transition probability between nodes. Random walk simulation is performed on the graph structure.

[0072] Step S1471: Perform graph structure modeling on the topology snapshot, abstract each cloud resource instance as a graph node, abstract the reachable network connection between cloud resource instances as a directed edge, and assign an attribute vector to each graph node.

[0073] The topology snapshot obtained in step S146 is formally modeled. First, all active cloud resource instances are traversed, and a unique graph node is created for each instance, with the node identifier corresponding one-to-one with the resource instance identifier. Then, all network connection rules are traversed, including virtual private cloud routing tables, security group permission rules, network access control lists, etc. For each rule that allows access from a source resource to a target resource, a directed edge is added to the graph from the source node to the target node. Finally, an attribute vector is attached to each node. The attribute vector is constructed as follows: the cloud resource type of the node is queried from the cloud platform database and encoded as part of a one-hot vector; the list of open ports of the node is queried and encoded as a multi-hot vector; the security group identifier to which the node belongs is queried and mapped to a category identifier; the number of historical vulnerabilities of the node is queried and normalized as a scalar value. All this information is concatenated into a long attribute vector, denoted as Attr_node.

[0074] Step S1472: Map the attacker's current inferred location to the corresponding graph node in the graph structure, mark the graph node as the initial infected node, and set the initial infected state of the initial infected node to active.

[0075] Based on the current security event chain being processed, determine the cloud resource instances that the attacker has already compromised. This can be inferred by analyzing the event target addresses of the last one or several event units in the chain. Identify the graph node corresponding to that address from the graph structure constructed in step S1471, mark it as the initial infected node, and denote it as Node_init. Set a state attribute for this node, such as "infected" or "active," indicating that the attacker currently has execution capabilities on that node.

[0076] Step S1473: Analyze the lateral movement inference vector, which is a probability distribution representing the joint probability of the attacker's preferred next-hop target cloud resource type and network service port.

[0077] The lateral movement projection vector L_movement generated in step S144 is analyzed. L_movement is a concatenated vector, which is divided into two parts: the first part is a probability distribution of length M, denoted as P_resource, where M is the total number of cloud resource types, and each value in P_resource represents the probability that the attacker will attempt to attack that resource type next; the second part is a probability distribution of length N, denoted as P_port, where N is the total number of common network service ports, and each value in P_port represents the probability that the attacker will attempt to attack that port next. These two distributions together characterize the attacker's lateral movement preferences.

[0078] Step S1474: parse the privilege escalation inference vector, which is a probability distribution representing the probability distribution of the privilege escalation techniques that the attacker may use next.

[0079] The privilege escalation inference vector P_elevation generated in step S145 is analyzed. P_elevation is also a concatenated vector, and we mainly focus on its second part, which is a probability distribution of length K, denoted as P_technique. Here, K is the total number of predefined privilege escalation techniques, and each value in P_technique represents the probability that the attacker will attempt to use that technique for privilege escalation in the next step. This distribution reflects the attacker's strategy preferences regarding privilege escalation.

[0080] Step S1475: Calculate the basic transition probability for each directed edge in the graph structure. The basic transition probability is obtained by multiplying the cloud resource type of the target node by the probability of the corresponding resource type in the lateral movement inference vector, and then multiplying it by the matching degree between the open port of the target node and the probability of the corresponding port in the lateral movement inference vector.

[0081] For the currently active infected node, denoted as Node_current, consider each outgoing directed edge pointing to a target node Node_target. First, extract its cloud resource type code from the attribute vector Attr_target of Node_target to determine the resource type of the node, denoted as Type_target. Query the probability distribution P_resource obtained in step S1473 and retrieve the probability value corresponding to Type_target, denoted as Prob_type. Second, extract the list of open ports Ports_target from Attr_target. Iterate through each port Port_i in Ports_target, query the probability distribution P_port obtained in step S1473, and retrieve the probability value Prob_port_i corresponding to Port_i. Then, calculate the sum of the matching degrees of all open ports of the target node, i.e., sum over Prob_port_i, to obtain Sum_prob_port. The base transition probability Base_prob is calculated as follows: Base_prob equals Prob_type multiplied by Sum_prob_port. This product indicates that the more the target node's resource type matches the attacker's preferences, and the more its open ports match the attacker's preferences, the higher the base probability that the attacker will choose this node as the next lateral movement target.

[0082] Step S1476: Based on the difference in permission levels between the source node and the target node and the permission upgrade inference vector, the basic transfer probability is corrected. If the transfer is from a low-permission node to a high-permission node, the probability value of the corresponding technical means in the permission upgrade inference vector is multiplied as the correction coefficient.

[0083] After calculating the base transition probability Base_prob, it needs to be adjusted based on the possibility of privilege escalation. The currently inferred privilege level is obtained from the attributes of Node_current, denoted as Level_current; the available privilege level implied by default or historical vulnerabilities is obtained from the attributes of Node_target, denoted as Level_target. If Level_target is higher than Level_current, there is a possibility of privilege escalation. At this point, the technique most suitable for transitioning from Node_current to Node_target needs to be selected from the probability distribution P_technique obtained in step S1474. This matching process can be accomplished using a predefined mapping table of techniques and vulnerability types. For example, if Node_target has a kernel vulnerability, and the probability of "exploiting a kernel vulnerability" in P_technique is high, then the probability value of that item is selected as the adjustment coefficient. The adjusted transition probability Adjusted_prob is calculated as follows: Adjusted_prob equals Base_prob multiplied by Correction_factor, where Correction_factor is the probability value of the selected privilege escalation technique. If Level_target is not higher than Level_current, then Correction_factor is set to a fixed constant, such as 1, indicating that no corrections related to privilege escalation are made.

[0084] Step S1477: Call the security protection strength factor of the node, query the strictness of the protection rules associated with the security group identifier of the target node, quantify the strictness into a protection strength coefficient, the protection strength coefficient is inversely proportional to the transition probability, and use the protection strength coefficient to attenuate the corrected transition probability.

[0085] Further consider the target node's own defense capabilities. Obtain the security group identifier from the attribute vector `Attr_target` of `Node_target`. Query the cloud platform's security policy management database to obtain the severity score of the protection rules associated with that security group. This score could be a value from 0 to 1, where 0 represents no protection and 1 represents the highest protection level. Convert this severity score into a defense strength coefficient, `Defense_factor`. Since higher defense strength results in a lower probability of successful attack, `Defense_factor` is inversely proportional to the transition probability. `Defense_factor` can be defined as 1 minus the severity score, or an exponential decay function can be used. Finally, the transition probability `Final_prob` after defense decay is calculated as: `Final_prob` equals `Adjusted_prob` multiplied by `Defense_factor`.

[0086] Step S1478: Normalize the transition probabilities of all outgoing edges originating from the currently active infected node to ensure that the sum of the transition probabilities of all outgoing edges is a fixed constant.

[0087] For all outgoing edges of Node_current, after calculations in steps S1475 to S1477, each edge obtains a final transition probability Final_prob_i. Since these probability values ​​are calculated independently under different conditions, their sum is not necessarily equal to 1. To make it a valid probability distribution, normalization is required. First, the sum of Final_prob_i for all outgoing edges is calculated and denoted as Sum_probs. Then, for each outgoing edge, its normalized transition probability Normalized_prob_i is equal to Final_prob_i divided by Sum_probs. After normalization, the sum of the transition probabilities of all edges originating from Node_current equals 1.

[0088] Step S1479: Based on the normalized transition probability distribution, the roulette wheel selection algorithm is used to select the next node to be traversed. The selected node is marked as a new active infected node, and the edge and time step of this traversal are recorded.

[0089] Based on the normalized transition probability distribution obtained in step S1478, the roulette wheel selection algorithm is used to determine which node to traverse to next. The principle is to generate a random number between 0 and 1, and then, according to the cumulative probability distribution, select the node pointed to by the first edge whose cumulative probability is greater than that random number. This selected node becomes the new active infected node, and its state is marked as "infected". Simultaneously, the edges traversed in this traversal and the current time step number are recorded, for example, step 1.

[0090] Step S14710: On the new active infected node, repeat the process of calculating the transfer probability, normalizing and selecting the next node based on the lateral movement inference vector, the privilege escalation inference vector and the node security protection strength, until the preset maximum number of steps is reached or the node reaches a termination node with no outgoing edges.

[0091] Using the newly marked active infected node from step S1479 as the current node, repeat steps S1475 to S1479 to calculate the transition probability from that node and select the next node. This process is repeated cyclically, forming a continuous walking path. There are two conditions for the loop to terminate: first, the current number of steps reaches the preset maximum simulation step count, for example, a maximum of 10 steps; second, the current active infected node has no outgoing edges, meaning it cannot transition to any other node, and the path terminates naturally. When either termination condition is met, the random walk simulation ends.

[0092] Step S14711: Repeat the independent random walk simulation multiple times. Each simulation starts from the initial infected node, but the node selection at each step is carried out independently based on the transition probability distribution calculated in the current step, and finally a set of multiple random walk paths is obtained.

[0093] Because node selection during a random walk relies on random numbers, the result of a single simulation is random. To obtain statistically stable projection results, multiple independent simulations need to be performed. Each simulation starts from the same initial infected node, Node_init, and strictly follows steps S1471 to S14710, but the random number seed is different for each step in each simulation, resulting in different generated paths. For example, 1000 independent random walk simulations can be performed. The paths generated by all simulations constitute a set of random walk paths, covering various diffusion paths that an attacker might take.

[0094] Step S148: During the random walk simulation, the transition probability is dynamically adjusted according to the security protection strength in the node attribute information, and the sequence of nodes visited during the random walk simulation and the corresponding visit time steps are recorded.

[0095] In the multiple random walk simulations in step S147, for each walk, upon reaching a node, the node's identifier and the corresponding step number are recorded. For each independent simulation, a sequence is generated, namely the node visit sequence and a corresponding step sequence. For example, the node visit sequence for a simulation might be Node_init, Node_A, Node_B, ..., with corresponding visit time step sequences of 0, 1, 2, ... All node visit sequences and step sequences from all simulations are stored for subsequent analysis.

[0096] Step S149: Based on the sequence of nodes visited, analyze the threat propagation path pattern in the cloud network and identify key springboard nodes and sets of high-value target nodes.

[0097] Step S1491: Collect the set of visited node sequences generated by multiple random walk simulations, extract all graph nodes appearing in all node sequences, and construct a node occurrence frequency statistics table.

[0098] First, summarize all simulated node access sequences recorded in step S148. Iterate through each node in each sequence and count the total number of times each node identifier appears across all sequences. For example, node Node_X appears 500 times in 1000 simulations. Compile these statistical results into a table, which is the node frequency statistics table.

[0099] Step S1492: Calculate the total number of times each graph node appears in the set of node sequences, divide the total number of appearances by the total number of random walk simulations, and obtain the global access frequency of the graph node.

[0100] Based on the statistics table in step S1491, for each node, its total occurrences are divided by the total number of simulations, for example, 1000 times, to obtain a ratio, which is used as the global access frequency of that node. This global access frequency reflects the likelihood that the node will be accessed by an attacker throughout the simulation. The higher the frequency, the more critical the node is in the threat propagation path.

[0101] Step S1493: Analyze the structure of the node sequence, extract the frequently occurring consecutive node pairs in all node sequences, that is, the sequential combination of visiting one node followed by visiting the next node, and count the number of consecutive occurrences of each node pair in all node sequences.

[0102] The entire node visit sequence is traversed again, this time focusing on the relationships between adjacent nodes. For each sequence, every pair of adjacent nodes is scanned. For example, if the node sequence is Node_A, Node_B, Node_C, then the node pairs (Node_A, Node_B) and (Node_B, Node_C) are recorded. The total number of occurrences of each distinct node pair across all sequences is counted. For example, the node pair (Node_A, Node_B) appears a total of 300 times in 1000 simulations.

[0103] Step S1494: Based on the consecutive occurrence count of the node pairs, construct a node transition directed graph, where the nodes are cloud resource graph nodes and the weight of the edges is the consecutive occurrence count of the corresponding node pairs.

[0104] Using all graph nodes in the cloud environment as nodes, and each node pair counted in step S1493 as a directed edge, the first node in the node pair points to the second node, and the total number of occurrences of the node pair is used as the weight of this directed edge. This constructs a new directed graph, called the node transition directed graph. This node transition directed graph reflects the statistical patterns of attackers' transitions in the cloud environment; the larger the weight of an edge, the more common the transition path.

[0105] Step S1495: Run the community detection algorithm on the node transfer directed graph to divide the nodes into several communities. The nodes within each community transfer frequently, while the nodes outside the community transfer sparsely.

[0106] On the node transfer directed graph constructed in step S1494, a community detection algorithm, such as the Leuven method, is applied. This algorithm divides the nodes in the graph into different communities by optimizing the modularity index. The result of this division is that the edge weights between nodes within the same community are usually higher, indicating frequent transfers; while the edge weights between nodes in different communities are lower, indicating sparse transfers. These communities may correspond to different functional areas, different subnets, or different security domains in the cloud environment.

[0107] Step S1496: Identify nodes that connect different communities. These nodes frequently appear in the node sequences of different communities and mark them as candidate key stepping stone nodes.

[0108] Analyze the community structure defined in step S1495 to identify nodes that are connected to multiple communities with high-weight edges. These nodes are typically hubs for cross-community migrations; attackers must pass through them to move from one community to another. This can be determined by examining the number of communities each node's neighbors belong to. If a node's neighbors are distributed across multiple different communities, it is likely a key point for cross-community migrations. Mark these nodes as candidate key stepping stone nodes.

[0109] Step S1497: For each candidate key stepping stone node, calculate its betweenness centrality, which is defined as the proportion of the number of shortest paths of all node pairs that pass through the candidate key stepping stone node to the total number of shortest paths.

[0110] For each candidate critical stepping stone node marked in step S1496, its betweenness centrality is calculated on the original cloud network topology graph, i.e., the graph structure constructed in step S1471. The betweenness centrality is calculated as follows: for all pairs of nodes in the graph, find all shortest paths between each pair. Then, count how many of these shortest paths pass through the current candidate node. Finally, divide the number of shortest paths passing through that node by the total number of shortest paths across all node pairs; the result is the betweenness centrality of that node. This metric measures the importance of the node in the overall network connectivity.

[0111] Step S1498: Combine the global access frequency and betweenness centrality of the candidate key stepping stone nodes, perform a weighted summation of the two to obtain the keyness score of the stepping stone, select the candidate key stepping stone nodes whose keyness scores exceed the preset threshold, and determine them as the final key stepping stone nodes.

[0112] For each candidate critical springboard node, its global access frequency calculated in step S1492 is denoted as Freq_global, and its betweenness centrality calculated in step S1497 is denoted as Bet_centrality. These two values ​​are weighted and summed using a preset weighting coefficient, beta, to obtain the springboard criticality score, Score_chokepoint. The calculation logic is: Score_chokepoint equals beta multiplied by Freq_global plus one (within parentheses) minus beta multiplied by Bet_centrality. The value of beta is between 0 and 1, used to balance the weights of statistical frequency and topological importance. Then, this score is compared with a preset threshold, Threshold_chokepoint. Candidate nodes with scores higher than this threshold are determined as the final critical springboard nodes.

[0113] Step S1499: Query the business importance level and data sensitivity level of the cloud resource instance corresponding to each graph node from the cloud resource configuration management database, and mark the graph nodes corresponding to cloud resource instances whose business importance level is higher than the preset importance level threshold and whose data sensitivity level is higher than the preset sensitivity level threshold as high-value target nodes.

[0114] By querying the cloud platform's resource management database, metadata for the cloud resource instance represented by each graph node is obtained. This metadata includes the business importance level, pre-marked by business operations personnel (e.g., core business, edge business, testing business, quantified as numerical values ​​1, 2, 3, etc.). It also includes the data sensitivity level, such as top secret, confidential, internal, public, also quantified numerically. An importance level threshold and a sensitivity level threshold are set. If a node's business importance level is greater than or equal to the importance level threshold, and its data sensitivity level is greater than or equal to the sensitivity level threshold, then the node is marked as a high-value target node. All these marked nodes constitute the set of high-value target nodes.

[0115] Step S14910: Filter high-value target nodes that have been visited at least once in the node sequence set to form a high-value target node set. For each node in the high-value target node set, calculate its average first visit time step from the initial infected node.

[0116] Based on the set of high-value target nodes marked in step S1499, and combined with the node access sequence recorded in step S148, high-value target nodes that have been visited in at least one random walk simulation are further selected, forming the final set of high-value target nodes of concern. For each node in this set, all random walk paths containing that node are traversed, and the number of steps taken when the node is first visited in each path is found. Then, the average of these first-visit steps is calculated to obtain the average first-visit time steps for that node. This metric quantifies the expected time required for the threat to spread to critical targets.

[0117] Step S1410: Based on the access time step, divide the threat evolution into stages, and finally output the threat evolution situation projection results, which include diffusion path patterns, key springboard nodes, high-value target node sets, and threat evolution stage divisions.

[0118] Step S1410-1: Extract the access time step sequence generated by a single random walk simulation, wherein the access time step sequence records the number of simulated steps visited by each node on the walk path.

[0119] From the detailed data recorded in step S148, for each random walk simulation, extract its corresponding access time step sequence. This sequence is a list, where each element is a tuple (node ​​identifier, access step count). For example, the sequence for a certain simulation might be (Node_init, 0), (Node_A, 1), (Node_B, 2), ...

[0120] Step S1410-2: Perform statistical analysis on all the access time steps obtained from multiple random walk simulations, and calculate the average access time step for each visited graph node. The average access time step is the average of the access time steps of the node in all random walk paths that include it.

[0121] Summarize the visit time steps for all nodes in all random walk simulations. For each visited node, collect the number of steps taken to visit that node across all paths containing it. Then, calculate the arithmetic mean of these steps as the average visit time steps for that node. For example, if node Node_Y is visited in 50 paths with visit steps of 2, 3, 2, 4, ..., then the average of these steps is Mean_step_Y.

[0122] Step S1410-3: Sort all visited graph nodes in ascending order of their average access time steps, and generate an ascending sequence list of nodes in ascending order of their average access time steps.

[0123] For the average access time step of each node calculated in step S1410-2, sort all nodes in ascending order of their values. The nodes at the top of the list are those that were reached by attackers earliest on average, and the nodes at the bottom are those that were reached latest. This ascending sequence list visually illustrates the temporal order of threat spread.

[0124] Step S1410-4: Divide the ascending sequence list into three stages. The time step threshold of the first stage is a first preset ratio of the total number of simulation steps, and the time step threshold of the second stage is a second preset ratio of the total number of simulation steps.

[0125] Set the total number of simulation steps, for example, a maximum of 10 steps (Max_step). Set the first preset ratio to 30% and the second preset ratio to 70%. Then, the first stage time step threshold T1 is equal to Max_step multiplied by 0.3, which is 3 steps. The second stage time step threshold T2 is equal to Max_step multiplied by 0.7, which is 7 steps. These two thresholds divide the entire timeline into three consecutive intervals: 0 to T1 is the first stage, T1 to T2 is the second stage, and above T2 is the third stage.

[0126] Step S1410-5: Classify all nodes whose average access time step is less than the threshold of the first stage time step as nodes in the initial penetration stage.

[0127] Based on the ascending sequence list generated in step S1410-3, all nodes with an average access time step of less than T1 (i.e., 3 steps) are extracted and classified into a category called the initial penetration stage nodes. These nodes represent the resources that attackers are most likely to compromise first in the early stages of the intrusion.

[0128] Step S1410-6: Classify all nodes whose average access time step is greater than or equal to the first stage time step threshold and less than the second stage time step threshold as nodes in the lateral movement stage.

[0129] All nodes with an average access time greater than or equal to T1 (3 steps) and less than T2 (7 steps) are classified as nodes in the lateral movement phase. These nodes represent resources that attackers may compromise during lateral expansion and exploration within the cloud network.

[0130] Step S1410-7: From the nodes whose average access time step is greater than or equal to the second stage time step threshold, select the nodes that belong to the high-value target node set and classify the nodes as final attack stage nodes.

[0131] For all nodes with an average access time greater than or equal to T2 (7 steps), first filter out those nodes that also belong to the high-value target node set determined in step S14910. These nodes are then classified as final attack phase nodes, representing the core targets that the attacker may ultimately target in the later stages of the attack.

[0132] Step S1410-8: For other nodes whose average access time step is greater than or equal to the second stage time step threshold but do not belong to the high-value target node set, classify them as extensions of the lateral movement stage nodes.

[0133] For other nodes whose average access time steps are greater than or equal to T2 (7 steps) but are not high-value target nodes, they can be regarded as an extension of the lateral movement phase. That is, before reaching the final target, the attacker may still be active on some non-core resources.

[0134] Step S1410-9: Integrate the results of multiple random walk simulations, and for each graph node, count the frequency at which it is classified into the initial penetration stage, the lateral movement stage, and the final attack stage, and take the stage with the highest frequency as the final stage label for that graph node.

[0135] Since node phase division is based on its average access time step, which is a statistical value and may fluctuate, a more robust phase label can be obtained by backtracking the results of all individual simulations. For each node, the number of times it is classified into each of the three phases is counted across all simulation paths containing it. For example, if node Node_Z is classified as the initial penetration phase in 500 paths, the lateral movement phase in 300 paths, and the final attack phase in 200 paths, then the phase with the most occurrences, i.e., the initial penetration phase, is taken as the final phase label for node Node_Z.

[0136] Step S1410-10: Based on the final stage labels of all graph nodes, reconstruct the threat propagation path pattern in the cloud network topology.

[0137] By combining the node transfer directed graph constructed in step S1494 with the final stage label of each node, a typical path pattern of threat diffusion can be depicted. For example, starting from all nodes labeled "initial penetration stage", the flow proceeds along the edges with higher weights in the transfer directed graph to nodes labeled "lateral movement stage", and finally to nodes labeled "final attack stage". This typical path constitutes the threat diffusion path pattern.

[0138] Step S1410-11: The key springboard nodes, the set of high-value target nodes, the ascending sequence list of nodes according to the average access time step, the final stage label of each graph node and the diffusion path pattern are encapsulated in a structured manner to generate the threat evolution situation inference results.

[0139] Finally, the list of key springboard nodes determined in step S1498, the set of high-value target nodes determined in step S14910, the ascending sequence list of nodes generated in step S1410-3 according to average access time steps, the final stage label of each graph node determined in step S1410-9, and the diffusion path pattern reconstructed in step S1410-10—all this information is organized and encapsulated according to a predefined data format. This encapsulated data package is the threat evolution situation projection result corresponding to a security event correlation chain. This threat evolution situation projection result not only predicts the possible development direction of the threat but also quantifies the key nodes and stages.

[0140] Step S150: Based on the threat evolution scenario projection results, call the application programming interface of the cloud computing management platform to generate cloud-native adaptive protection instructions that match the threat evolution stage. The cloud-native adaptive protection instructions include micro-segmentation policies for cloud workloads, access control rules for cloud network traffic, and dynamic authentication policies for cloud identity credentials. The cloud-native adaptive protection instructions are then sent to the corresponding cloud security execution nodes.

[0141] Step S151: Analyze the threat evolution situation simulation results and extract the threat evolution stage division information and key stepping stone node information contained therein.

[0142] Receive the threat evolution situation simulation result data packet output in step S1410-11. Parse this data packet, first extracting global information about the threat evolution stages, namely the final stage label of each graph node and the stage division threshold. Simultaneously, extract the list of key springboard nodes; this information will serve as the basis for subsequently generating differentiated protection instructions.

[0143] Step S152: If the threat evolution stage is the initial penetration stage, generate a cloud workload micro-isolation strategy for the initial infected node and its adjacent nodes, and block all outgoing connection attempts related to the target cloud resource type and port indicated by the lateral movement inference vector in the threat evolution situation inference results.

[0144] For example, step S1521: Extract the initial penetration stage node list from the threat evolution situation simulation results. The initial penetration stage node list includes the initial infected node and its directly adjacent nodes in the cloud network topology.

[0145] Based on the definition in step S1410-5 and the analysis in step S151, all nodes labeled "initial penetration stage" in the final stage are extracted from the simulation results to form a list. This list naturally includes the initially infected nodes as well as those adjacent nodes with very short average access times that may be affected early on.

[0146] Step S1522: Query the cloud resource management system to obtain the cloud resource instance identifier, physical host address, and virtualization technology type used by each node in the initial penetration phase node list.

[0147] For each node in the list in step S1521, detailed deployment information is obtained by calling the query interface of the cloud resource management system based on the node identifier. This includes the unique identifier of the resource instance within the cloud platform; the network address or hostname of the physical host machine where the instance is currently running; and the virtualization technology type of the instance, such as a hardware-assisted full virtualization virtual machine or an operating system-level virtualization container.

[0148] Step S1523: Select the corresponding lightweight security agent installation package according to the virtualization technology type.

[0149] Pre-installed security agent installation packages are provided for different virtualization environments. For virtual machine environments, a security agent installation package based on kernel module injection is prepared, which contains a signed kernel module file and a user-space control program. For container environments, a security agent container image based on sidecar container injection is prepared, which contains the agent program and its dependent libraries.

[0150] Step S1524: Construct a security agent initialization configuration file, which includes agent running mode, redirection rules and blocking rules.

[0151] Construct a configuration file in a structured data exchange format, such as JSON or YAML. Set the "Run Mode" field in the configuration file to "Force Redirection". The "Redirection Rule" field specifies a rule to redirect all network traffic from transport layer protocols and above (layers 4 to 7) to the local user-space protocol stack for processing via the virtual network function. The "Blocking Rule" field is initialized to an empty list.

[0152] Step S1525: Analyze the lateral movement inference vector from the threat evolution situation inference results, extract the cloud resource type and port combination with a probability exceeding the set threshold from the lateral movement inference vector, convert each combination into a blocking rule, and fill it into the blocking rule list of the security agent initialization configuration file.

[0153] Re-analyze the simulation results and extract the lateral movement simulation vector generated in step S144. Traverse the probability distributions of cloud resource types and ports within this vector, identifying resource type and port combinations where both probability values ​​exceed a preset threshold, such as 0.5. For each such combination, generate a blocking rule. Each blocking rule contains three fields: the "Target Resource Type" field is set to the specified resource type, the "Target Port" field is set to the specified port number, and the "Action" field is set to "Drop". Add these rules one by one to the "Blocking Rule" list of the configuration file constructed in step S1524.

[0154] Step S1526: Through the virtualization management interface of the cloud computing management platform, distribute the lightweight security agent installation package and the security agent initialization configuration file to each node in the initial penetration phase node list.

[0155] The virtualization management interface provided by the cloud computing management platform is invoked. For example, for virtual machines, this might be through the interface for injecting files via VNC or a serial console, or through a service installed in the guest operating system via an agent; for containers, it is through the API of the container orchestration platform. The installation package selected in step S1523 and the updated configuration file in step S1525 are sent together to the specified storage location on the target node.

[0156] Step S1527: In a virtual machine environment, use the virtualization management interface to inject the security agent kernel module into the operating system kernel of the target virtual machine and load the security agent initialization configuration file.

[0157] For virtual machines, the kernel module file of the security agent is loaded into the kernel space of the target virtual machine through the virtualization management interface, such as the guest introspection or injection function provided by the host machine's hypervisor. Then, the user-mode control program is started. This program reads the distributed configuration file and applies network traffic redirection rules to the kernel's network protocol stack according to the configuration, thereby activating the security agent.

[0158] Step S1528: In the container environment, use the sidecar injection function of the container orchestration platform to package the security agent into a sidecar container, deploy it in the same container group as the business container, share the network namespace, and load the security agent initialization configuration file.

[0159] For containers, a sidecar container is added by modifying the container group deployment description file, such as the Pod definition in Kubernetes. This sidecar container uses the security proxy container image selected in step S1523. The sidecar container is configured to share the same network namespace as the business container. After the sidecar container starts, it automatically loads the mounted configuration file and, through network hooks or traffic redirection techniques within the network namespace, begins to intercept and process all traffic entering and leaving the business container, thereby completing the implantation and activation of the security proxy.

[0160] Step S1529: After the security agent is activated, immediately intercept all outgoing network connection requests from the node, parse the target address and port of each connection request, and match them with the blocking rule list.

[0161] Once the security proxy is activated, its kernel module or user-space data plane takes over all outbound network connections initiated by processes on the node. For each new connection request, the proxy first resolves its target Internet Protocol address and port number. Then, it iterates through the blocking rule list configured in step S1525.

[0162] Step S15210: If the target resource type of the connection request matches any rule in the blocking rule list, the security agent will directly discard the data packet of the connection request and generate a security log record.

[0163] If the resolved target port number, and a reverse lookup reveals the cloud resource type corresponding to that target address, perfectly matches a rule in the blocking rule list, the security proxy immediately discards the synchronization data packet of the connection request at the underlying level, preventing the three-way handshake from establishing. Simultaneously, a structured security log record is generated. This security log record contains the following fields: the timestamp of the event, derived from the host machine's clock; the source Internet Protocol address and port of the initiating connection; the target Internet Protocol address and port of the blocked connection; and the unique identifier of the matched blocking rule.

[0164] Step S15211: If the connection request does not match any blocking rules, the security proxy allows the connection request to pass, but all subsequent packets still need to undergo deep packet inspection by the user-space protocol stack.

[0165] If a connection request does not match any blocking rules, the security proxy allows it to pass, but all subsequent packets on that connection, including application-layer data, are redirected to the deep packet inspection engine in the user-space protocol stack. This deep packet inspection engine maintains an attack signature database, such as a set of regular expression rules. The engine performs pattern matching scans on the application-layer payload of each packet. If a matching attack signature is found, the connection is immediately reset, and an alarm is logged.

[0166] Step S15212: Periodically check the security agent's running status and rule matching logs to confirm whether the micro-segmentation policy is being executed correctly, and dynamically adjust the policy by updating the blocking rule list in the security agent's initialization configuration file according to changes in the threat evolution.

[0167] Continuously monitor the heartbeat reports from the security agent to confirm that the agent process and kernel modules are running. Periodically retrieve the blocking and detection logs generated by the security agent and compare them with the expected policies for auditing. If the threat evolution scenario changes, such as the prediction of new high-risk resource types and port combinations, the blocking rule list in the configuration file can be updated by re-executing steps S1525 to S1528 to achieve dynamic adjustment of the micro-segmentation policy.

[0168] Step S153: If the threat evolution stage is the lateral movement stage, then cloud network traffic access control rules for key jump node are generated. The cloud network traffic access control rules are implemented by calling the software-defined network controller interface of the cloud platform.

[0169] For example, step S1531: Extract the list of key springboard nodes and the set of high-value target nodes from the threat evolution situation simulation results.

[0170] Based on the analysis in step S151, the list of key stepping stone nodes determined in step S1498 and the set of high-value target nodes determined in step S14910 are extracted from the simulation results.

[0171] Step S1532: Query the cloud resource management system to obtain the Internet Protocol address and Media Access Control address of the virtual network interface corresponding to each node in the list of key jump board nodes, as well as the virtual subnet identifier to which each node belongs.

[0172] For each node in the list of critical jump node nodes, query the virtual network interface card information associated with that node through the network service interface of the cloud resource management system. Obtain the primary Internet Protocol address, media access control address, and unique identifier of the virtual private cloud subnet to which the interface card belongs.

[0173] Step S1533: Query the cloud resource management system to obtain the Internet Protocol address and Media Access Control address of the virtual network interface corresponding to each node in the high-value target node set.

[0174] Similarly, for each node in the set of high-value target nodes, query its associated virtual network interface card information, obtain its Internet Protocol address, and may also need to obtain the Media Access Control address for more refined filtering.

[0175] Step S1534: Construct access control list entries for the lateral movement phase.

[0176] Construct a set of access control list entries to implement traffic control at the virtual switch level. The entries use the logic of "if certain conditions are matched, then perform an action".

[0177] Step S1534-1: Set the source Internet Protocol address range to the Internet Protocol address of the critical jump node, set the target Internet Protocol address range to the Internet Protocol addresses of all nodes in the high-value target node set, and use address list matching; set the protocol type to all transport layer protocols; set both the source port range and the target port range to all ports; set the action to deny.

[0178] First, construct the core blocking entry. Set the source address condition to match the specific Internet Protocol (IP) address of the critical hop node. Set the destination address condition to a list of addresses containing the IP addresses of all nodes in the high-value target node set. Set the protocol type field to "All," meaning that both Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) will be matched. Set both the source and destination port ranges to "All." The action for this entry is "Reject," meaning any packet matching this entry should be dropped immediately.

[0179] Step S1534-2: Construct an additional access control list entry that allows management traffic to pass through. The source Internet Protocol address range of this access control list entry is set to the Internet Protocol address of the security operation and maintenance management node, the target Internet Protocol address range is set to the Internet Protocol address of the node in the high-value target node set, the protocol type and port range are set to all, and the action is set to allow.

[0180] To prevent normal operational activities from being mistakenly blocked, an exception entry needs to be created. The source address of this exception entry is set to the Internet Protocol (IP) address range used by the security operations and maintenance management node. The destination address is also set to a list of addresses from a set of high-value target nodes. Both the protocol and port are set to all. The action of this entry is set to "Allow". In the evaluation order of the access control list, this allow rule must have higher priority than the aforementioned deny rule to ensure that management traffic can pass normally.

[0181] Step S1535: Determine whether there is network overlap between the list of key springboard nodes and the set of high-value target nodes.

[0182] Check if the virtual subnet identifier of the critical jump node is the same as that of any high-value target node. If they are the same, it means that the critical jump node and the high-value target node are located in the same virtual subnet.

[0183] Step S1535-1: If network overlap exists, for the overlapping virtual subnets, access control list entries in both the uplink and downlink directions need to be added to the virtual switch of the virtual subnet.

[0184] When both are located in the same subnet, an attacker may have already gained control of the critical jump node, and may further control other nodes within the subnet, or even use the compromised high-value target node to launch attacks on other systems. Therefore, protection needs to be bidirectional. In addition to restricting uplink traffic from the critical jump node to the high-value target node, it is also necessary to restrict downlink traffic from the high-value target node to the critical jump node to prevent attackers from performing lateral jumps within the subnet. Therefore, bidirectional traffic direction needs to be configured for both rules on the virtual switch associated with the subnet.

[0185] Step S1535-2: If there is no network overlap, simply add an uplink access control list entry to the virtual switch of the subnet where the critical jump node is located.

[0186] If the two are not in the same subnet, then traffic must pass through the virtual switch of the subnet where the critical jump node is located to leave the subnet. Therefore, it is only necessary to configure an uplink access control list for outbound traffic on the virtual switch of that subnet.

[0187] Step S1536: Send a policy configuration request to the software-defined network controller through the application programming interface of the software-defined network controller provided by the cloud computing management platform.

[0188] The access control list entries constructed in step S1534, along with the effective location and direction determined in step S1535, are encapsulated into a standard-format policy configuration request. This policy configuration request includes a unique identifier for the target virtual switch, a list of access control list entries to be added, and a priority value for each entry. This request is then sent out by calling the RESTful application programming interface exposed by the software-defined network controller.

[0189] Step S1537: After receiving the policy configuration request, the software-defined network controller verifies the legality of the policy configuration request, compiles the access control list entries into flow table rules of the underlying switching devices, and sends them to the corresponding physical or virtual switches.

[0190] Upon receiving a request, the software-defined network controller first performs a validity check, including verifying the requester's permissions, the correctness of the entry format, and the existence of the specified target switch. If the verification is successful, the controller compiles the high-level access control list entry into flow table rules that can be recognized by the underlying switch hardware or software, such as open flow rules. Then, the controller distributes these flow table rules to the specified physical or virtual switches via the southbound interface protocol and installs them into the switch's forwarding engine.

[0191] Step S1538: Monitor the configuration results returned by the software-defined network controller to confirm whether the access control list entries have been successfully issued and are effective. Also, periodically collect traffic statistics from the virtual switches to verify whether the deny rules for critical jump board nodes have matching traffic counts, and whether the rules allowing management traffic are working correctly.

[0192] After processing the request, the controller returns a response containing the operation's status, such as success or failure, and detailed error information. Analyzing this response confirms whether the policy was successfully implemented. Furthermore, the controller can periodically query the virtual switch's traffic statistics to observe whether there are matching packet counts for deny rules targeting critical jumper nodes, and whether rules allowing management traffic are functioning correctly, thereby verifying the actual effectiveness of the policy.

[0193] Step S154: If the threat evolution stage is the final attack stage, a dynamic authentication policy for cloud identity credentials is generated for nodes in the set of high-value target nodes. The dynamic authentication policy for cloud identity credentials is implemented by integrating cloud identity and access management services. Specifically, it temporarily increases the multi-factor authentication level required to access nodes in the set of high-value target nodes and injects an additional behavioral biometric verification step into the access session.

[0194] When the threat evolution stage is determined to be the final attack stage, it means that attackers may be about to or have already attempted to access core assets. At this point, the highest level of protection for the aforementioned core assets is activated. First, nodes in the set of high-value target nodes are identified. Then, the application programming interface of the cloud platform's cloud identity and access management service is invoked. For the aforementioned target nodes, their access policies are temporarily modified. Specifically, the multi-factor authentication level required to access these nodes is upgraded from the default password-only to requiring a password plus a hardware token or biometric authentication. Simultaneously, the cloud identity and access management service is configured to inject an additional behavioral biometric verification step into the user's access session, such as a Secure Shell protocol or remote desktop protocol session. This behavioral biometric verification step requires the user to complete verification of specific mouse movement patterns or keyboard typing rhythm patterns during operation. These behavioral feature templates are pre-collected and stored by legitimate operations and maintenance personnel. The system continuously verifies the identity of the current operator by comparing the similarity between the real-time behavioral features and the templates, preventing attackers from using bots or scripts for automated sabotage after obtaining credentials.

[0195] Step S155: Integrate the micro-segmentation policies, access control rules, and dynamic authentication policies generated for different stages of threat evolution, and group them according to the scope of cloud resources where the policies take effect and the policy type to form a set of policy instructions.

[0196] The cloud workload micro-segmentation policies generated in step S152, such as the proxy installation configuration and blocking rule list for nodes in the initial penetration phase; the cloud network traffic access control rules generated in step S153, such as the software-defined network access control list entries for key jump node nodes; and the cloud identity credential dynamic authentication policies generated in step S154, such as changes to identity and access management policies for high-value target nodes, are uniformly summarized. These policies are then logically grouped according to their effective resource scope, such as by node, by subnet, by the entire cloud account, and by policy type, such as workload security, network security, and identity security. After grouping, a structured set of policy instructions is formed, which contains multiple policy instructions.

[0197] Step S156: Generate a unique transaction identifier for each policy instruction in the policy instruction set, and mark the expected effective time and automatic expiration time of the policy instruction.

[0198] To ensure the atomicity and traceability of policy issuance, a globally unique identifier, such as a universally unique identifier (UUID), is generated for each individual policy instruction in the policy instruction set—e.g., a security agent configuration file, an access control list entry, or an identity and access management policy modification operation. Simultaneously, based on time estimates from threat evolution scenario simulations, each instruction is marked with an expected effective time (e.g., immediate effective time) and an automatic expiration time. The expiration time can be calculated based on the average first access time step and the current time, ensuring that protective measures take effect before a threat may occur and are automatically removed after the threat has passed, avoiding long-term impact on normal business operations.

[0199] Step S157: Call the application programming interface of the cloud computing management platform to submit the policy instruction set in batches to the security policy orchestration engine of the cloud computing management platform in the form of transaction requests.

[0200] A batch transaction request is constructed, encapsulating all instructions in the policy instruction set formed in step S155, as well as the transaction identifier, effective time, and expiration time of each instruction generated in step S156. This batch transaction request is submitted by calling the application programming interface of the security policy orchestration engine of the cloud computing management platform. The security policy orchestration engine is responsible for coordinating different underlying services, such as virtualization management, software-defined network control, and identity and access management, to jointly complete this transaction.

[0201] Step S158: Monitor the execution feedback of the cloud computing management platform on the policy instruction set. The execution feedback includes confirmation of successful policy issuance, rollback of policy issuance failure, and notification that the policy has taken effect.

[0202] After submitting a transaction request, the system continuously monitors the execution status feedback returned by the security policy orchestration engine. For each policy instruction, the engine reports whether its issuance process was successful. If all instructions are successfully issued and confirmed, the engine returns an overall successful transaction commit confirmation. If one or more instructions fail to be issued, the engine automatically triggers a rollback operation based on the atomicity requirements of transactions. This involves attempting to undo all successfully issued instructions within the same transaction and returning a failure feedback containing the reason for the failure and a list of rolled-back instructions. Furthermore, for successfully issued instructions, when they reach their expected effective time and actually take effect on the target execution node, the execution node sends a "policy has taken effect" notification to the engine, which then forwards the notification to the situational awareness system.

[0203] Step S159: Based on the execution feedback, if the policy issuance fails, a rollback operation is performed according to the transaction identifier to cancel all policy instructions issued within the corresponding transaction and record the failure log.

[0204] If a policy issuance failure feedback is received in step S158, the feedback is immediately parsed to obtain the corresponding transaction identifier. Then, based on the transaction identifier, the previously submitted instruction set is queried, and a rollback instruction set is generated. This rollback instruction set contains actions that are the opposite of the original instruction operations, such as deleting a newly added access control list entry or restoring the identity and access management policy before the modification. The rollback instructions are also issued through the security policy orchestration engine to restore the system state to the state before the policy was attempted to be implemented. At the same time, the entire failure event, including the transaction identifier, failure instructions, and failure reason, is recorded in detail in the persistent failure log for subsequent manual analysis and troubleshooting.

[0205] Step S1510: If the policy is successfully issued and takes effect, the policy instruction set, the corresponding transaction identifier and the effective status are packaged to form the final cloud-native adaptive protection instruction transaction package, which is then issued to the cloud security execution node pointed to by the policy through a secure channel.

[0206] If the policy is successfully issued and a notification confirming its effectiveness is received, the system packages the set of policy instructions corresponding to this response, their transaction identifiers, and the current status (e.g., "effective") into a final transaction packet. This packet is then sent to all relevant cloud security execution nodes via a separate secure channel, such as a bidirectional transport layer encrypted message queue. These execution nodes include: host machines or containers with deployed security agents, which need to know the latest micro-segmentation rules; software-defined network switches, which need to confirm that flow table rules have been installed; and cloud identity and access management service endpoints, which need to confirm that the policy has been switched. In this way, all execution nodes obtain the complete context of this adaptive protection, enabling them to coordinate or report execution details when necessary. This completes the closed loop from situational awareness to the generation and issuance of adaptive protection instructions.

[0207] In one exemplary embodiment, a cloud-based network security situation awareness system is provided. This system can be a terminal, server, etc., and its internal structure diagram can be as follows: Figure 2As shown, this cloud-based network security situational awareness system includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, near-field communication, or other technologies. When the computer program is executed by the processor, it implements a cloud-based network security situational awareness method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, or a button, trackball, or touchpad set on the shell of a cloud-based network security situation awareness system, or an external keyboard, touchpad, or mouse, etc.

[0208] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A cloud computing-based network security situation awareness method, characterized in that, The method includes: Receive raw security event streams sent by security probe nodes deployed at the edge of the cloud network. The raw security event streams consist of multiple security event units carrying timestamps. Each security event unit includes the event source address, the event destination address, the event protocol type, and the event payload content. The original security event stream is subjected to security event context association reconstruction processing, which associates and combines discrete security event units with potential association logic in the original security event stream to generate a security event association chain set consisting of multiple security event association chains; The security threat feature extraction and fusion process is performed on the security event association chain set. The internal event interaction mode features and external cloud environment coupling features of each security event association chain are extracted, and the internal event interaction mode features and external cloud environment coupling features are fused based on their complementarity to generate a fused threat feature vector corresponding to each security event association chain. The fused threat feature vector corresponding to each security event association chain is input into a pre-constructed threat evolution situation inference model. The threat evolution situation inference model simulates the lateral movement and privilege escalation path of attackers in the cloud environment, infers the potential diffusion direction and evolution stage of security threats in the cloud network topology, and generates the threat evolution situation inference result corresponding to each security event association chain. Based on the threat evolution scenario projection results, the application programming interface of the cloud computing management platform is invoked to generate cloud-native adaptive protection instructions that match the threat evolution stage. The cloud-native adaptive protection instructions are then sent to the corresponding cloud security execution nodes. The cloud-native adaptive protection instructions include micro-segmentation policies for cloud workloads, access control rules for cloud network traffic, and dynamic authentication policies for cloud identity credentials.

2. The cloud computing-based network security situation awareness method according to claim 1, characterized in that, The step of performing security event context association reconstruction processing on the original security event stream involves associating and combining discrete security event units with potential association logic in the original security event stream to generate a set of security event association chains consisting of multiple security event association chains, including: The original security event flow is subjected to network segment aggregation analysis of event source address and event target address, and the mask matching degree of the network segment to which the event source address belongs and the mask matching degree of the network segment to which the event target address belongs are calculated for any two security event units. Based on the mask matching degree, identify security event units whose source addresses belong to the same internal subnet and whose target addresses point to the same external service address, and mark the security event units as potential related event groups. The timestamp markers within the potential associated event group are serialized and sorted to generate a sequence of security event units in chronological order. The event protocol type conversion probability of adjacent security event units in the security event unit sequence is calculated. The event protocol type conversion probability is obtained based on the frequency statistics of conversion between different protocol types in historical event sequences. Based on the event protocol type conversion probability, determine whether there is an event sequence segment in the security event unit sequence that converts from a low-privilege detection protocol to a high-privilege control protocol; Extract event sequence fragments with protocol conversion, analyze the event payload content of each security event unit in the event sequence fragment, and identify whether the same attack tool fingerprint or the same command and control instructions exist in the event payload content; Security event unit sequence fragments with the same attack tool fingerprint or the same command and control instructions are merged to form an initial security event association chain candidate set. The temporal density coherence score of each candidate chain in the candidate set of security event association chains is calculated. The temporal density coherence score is obtained by evaluating the uniformity of the timestamp intervals of security event units within the candidate chain. The more uniform the timestamp intervals, the higher the score. Calculate the semantic payload coherence score for each candidate chain in the candidate set of security event association chains. The semantic payload coherence score is represented by the average cosine similarity between vectors of the event payload content of all security event units in the candidate chain after being encoded by a natural language processing model. The temporal density coherence score and the semantic payload coherence score are weighted and fused to obtain the comprehensive association confidence of each candidate chain. The candidate chains are then filtered according to a preset comprehensive association confidence threshold. Candidate chains with a comprehensive association confidence higher than the comprehensive association confidence threshold are output as the final security event association chains. All the final security event association chains constitute the security event association chain set.

3. The cloud computing-based network security situation awareness method according to claim 1, characterized in that, The process of performing security threat feature extraction and fusion on the set of security event association chains involves extracting the internal event interaction pattern features and external cloud environment coupling features of each security event association chain, and fusing them based on the complementarity of the internal event interaction pattern features and external cloud environment coupling features to generate a fused threat feature vector corresponding to each security event association chain, including: Analyze each security event association chain, extract the event protocol type sequence of all security event units in the chain, perform one-hot encoding on the event protocol type sequence, and generate a protocol type one-hot encoded vector; The one-hot encoded vector of the protocol type is processed by sliding window convolution to extract the local transfer patterns of the protocol type sequence under different time windows. The feature map obtained after convolution is max pooled to generate the protocol transfer pattern feature vector. Extract the timestamp sequence of each security event association chain, calculate the time interval sequence between adjacent security event units, perform discrete Fourier transform on the time interval sequence, extract the amplitude of the main frequency component of the time interval sequence in the frequency domain, and generate the attack rhythm frequency domain feature vector. Obtain the cloud resource identifiers involved in each security event chain, including the image identifier of the virtual machine, the workload identifier of the container, and the instance identifier of the cloud database; Based on the cloud resource identifier, query the cloud resource configuration management database to obtain the security baseline configuration information and historical vulnerability disclosure records of the corresponding cloud resource, and generate a cloud resource security context feature vector. Obtain the source address and destination address of each security event association chain, query the cloud network topology graph, calculate the shortest network path hop count between the source address and destination address in the topology graph and the set of network device types traversed by the path, and generate a network topology reachability feature vector; The protocol transfer mode feature vector, attack rhythm frequency domain feature vector, cloud resource security context feature vector, and network topology reachability feature vector are concatenated to form an initial concatenated feature vector. Construct a feature interaction layer with a multi-head attention mechanism, input the initial spliced ​​feature vector into the feature interaction layer, calculate the internal interaction attention weight between the protocol transfer mode feature vector and the attack rhythm frequency domain feature vector, and at the same time calculate the external interaction attention weight between the cloud resource security context feature vector and the network topology reachability feature vector. The protocol transfer mode feature vector and the attack rhythm frequency domain feature vector are weighted and summed according to the internal interaction attention weight to generate internal event interaction mode features; the cloud resource security context feature vector and the network topology reachability feature vector are weighted and summed according to the external interaction attention weight to generate external cloud environment coupling features. The internal event interaction pattern features and the external cloud environment coupling features are input into the feature fusion gating unit. The feature fusion gating unit calculates the fusion gating coefficients of the internal event interaction pattern features and the external cloud environment coupling features based on a learnable weight matrix. The fusion gating coefficients are used to perform weighted fusion of the internal event interaction pattern features and the external cloud environment coupling features, and finally outputs the fused threat feature vector.

4. The cloud computing-based network security situation awareness method according to claim 1, characterized in that, The process involves inputting the fused threat feature vector corresponding to each security event chain into a pre-constructed threat evolution scenario model. This model simulates the lateral movement and privilege escalation paths of attackers in the cloud environment, predicts the potential spread direction and evolution stages of security threats within the cloud network topology, and generates threat evolution scenario prediction results for each security event chain, including: An input layer is constructed to build a threat evolution situation inference model. The input layer receives the fused threat feature vector and performs linear transformation and nonlinear activation processing on the fused threat feature vector to generate initial hidden state features. The initial hidden state features are input into the sequence memory module of the threat evolution situation inference model. The sequence memory module adopts a gated cyclic unit structure to simulate the evolution process of threat features in the time dimension, iteratively update the hidden state features, and generate a hidden state feature sequence containing temporal dependencies. Extract the hidden state features of the last time step from the hidden state feature sequence, and use them as the state summary features of the current threat evolution; The state summary features are input into the lateral movement inference branch of the threat evolution situation inference model. The lateral movement inference branch consists of multiple fully connected layers. Based on the state summary features, the target cloud resource type and corresponding network service port that the attacker may attempt to move laterally are predicted, and a lateral movement inference vector is generated. The state summary features are input into the privilege escalation inference branch of the threat evolution situation inference model. The privilege escalation inference branch is composed of multiple fully connected layers. Based on the state summary features, the attacker's current privileges and the privilege escalation techniques that may be attempted next are predicted, and a privilege escalation inference vector is generated. Obtain a real-time topology snapshot of the current cloud environment, which includes network connection relationships and node attribute information between all active cloud resource nodes; The lateral movement inference vector, the privilege escalation inference vector, and the topology snapshot are input together into the graph diffusion simulation module of the threat evolution situation inference model. The graph diffusion simulation module abstracts the cloud environment into a graph structure, where nodes represent cloud resources and edges represent network connections. The attacker's current inferred location is taken as the initial infected node, and the lateral movement inference vector and the privilege escalation inference vector are used as the basis for the transition probability between nodes. Random walk simulation is performed on the graph structure. During the random walk simulation, the transition probability is dynamically adjusted according to the security protection strength in the node attribute information, and the sequence of nodes visited during the random walk simulation and the corresponding visit time step are recorded. Based on the sequence of nodes visited, the propagation path pattern of threats in the cloud network is analyzed, and key springboard nodes and sets of high-value target nodes are identified. Based on the access time step, the threat evolution stages are divided, and the final output includes the threat evolution situation projection results, which include the diffusion path pattern, key springboard nodes, high-value target node set, and threat evolution stage division.

5. The cloud computing-based network security situation awareness method according to claim 4, characterized in that, The graph diffusion simulation module, which inputs the lateral movement inference vector, the privilege escalation inference vector, and the topology snapshot into the threat evolution situation inference model, abstracts the cloud environment as a graph structure, where nodes represent cloud resources and edges represent network connections. It uses the attacker's current inferred location as the initial infected node and the lateral movement inference vector and privilege escalation inference vector as the transition probability basis between nodes. It then performs a random walk simulation on the graph structure, including: Graph structure modeling is performed on the topology snapshot, each cloud resource instance is abstracted as a graph node, the reachable network connection between cloud resource instances is abstracted as a directed edge, and each graph node is assigned an attribute vector, which includes cloud resource type, open port list, security group identifier and number of historical vulnerabilities; Map the attacker's current inferred location to the corresponding graph node in the graph structure, mark the graph node as the initial infected node, and set the initial infected state of the initial infected node to active; The lateral movement inference vector is analyzed. The lateral movement inference vector is a probability distribution that represents the joint probability of the attacker's preferred next-hop target cloud resource type and network service port. The privilege escalation deduction vector is analyzed. The privilege escalation deduction vector is a probability distribution, which represents the probability distribution of the privilege escalation techniques that the attacker may use next. The basic transition probability is calculated for each directed edge in the graph structure. The basic transition probability is obtained by multiplying the cloud resource type of the target node by the probability of the corresponding resource type in the lateral movement inference vector, and then multiplying it by the matching degree between the open port of the target node and the probability of the corresponding port in the lateral movement inference vector. The basic transfer probability is corrected based on the difference in permission levels between the source node and the target node and the permission upgrade inference vector. If the transfer is from a low-permission node to a high-permission node, the probability value of the corresponding technical means in the permission upgrade inference vector is multiplied as the correction coefficient. If the permission levels are the same or reduced, the correction coefficient is set to a fixed constant. The security protection strength factor of the node is invoked, the strictness of the protection rules associated with the security group identifier of the target node is queried, and the strictness is quantified into a protection strength coefficient. The protection strength coefficient is inversely proportional to the transition probability. The protection strength coefficient is used to attenuate the corrected transition probability. The transition probabilities of all outgoing edges originating from the currently active infected node are normalized to ensure that the sum of the transition probabilities of all outgoing edges is a fixed constant. Based on the normalized transition probability distribution, the roulette wheel selection algorithm is used to select the next node to be traversed. The selected node is marked as a new active infected node, and the edge and time step of this traversal are recorded. On a new active infected node, the process of calculating the transfer probability, normalizing and selecting the next node based on the lateral movement inference vector, the privilege escalation inference vector and the node security protection strength is repeated until the preset maximum number of steps is reached or the node reaches a terminal node without outgoing edges. Finally, a random walk path starting from the initial infected node is generated, and one random walk simulation is completed. Repeatedly execute multiple independent random walk simulations. Each simulation starts from the initial infected node, but the node selection at each step is performed independently based on the transition probability distribution calculated in the current step, ultimately resulting in a set of multiple random walk paths.

6. The cloud computing-based network security situation awareness method according to claim 4, characterized in that, Based on the visited node sequence, the threat propagation path pattern in the cloud network is analyzed to identify key springboard nodes and a set of high-value target nodes, including: Collect the set of visited node sequences generated by multiple random walk simulations, extract all graph nodes appearing in all node sequences, and construct a node occurrence frequency statistics table; Calculate the total number of times each graph node appears in the set of node sequences, divide the total number of appearances by the total number of random walk simulations, and obtain the global access frequency of the graph node. Analyze the structure of the node sequence, extract the frequently occurring consecutive node pairs in all node sequences, that is, the sequential combination of visiting one node followed by visiting the next node, and count the number of consecutive occurrences of each node pair in all node sequences. Based on the consecutive occurrence count of the node pairs, a node transition directed graph is constructed, where the nodes are cloud resource graph nodes and the weight of the edges is the consecutive occurrence count of the corresponding node pairs. The community detection algorithm is run on the directed graph of node transfers to divide the nodes into several communities. The nodes within each community transfer frequently, while the nodes outside the community transfer sparsely. Identify nodes that connect different communities, and mark these nodes as candidate key stepping stone nodes, as they frequently appear in the node sequences of different communities. For each candidate key stepping stone node, calculate its betweenness centrality, which is defined as the proportion of the number of shortest paths among all node pairs that pass through the candidate key stepping stone node to the total number of shortest paths. Combining the global access frequency and betweenness centrality of candidate key jump nodes, the two are weighted and summed to obtain the jump node criticality score. Candidate key jump nodes whose jump node criticality scores exceed a preset threshold are selected and determined as the final key jump nodes. Query the cloud resource configuration management database to find the business importance level and data sensitivity level of the cloud resource instance corresponding to each graph node, and mark the graph nodes corresponding to cloud resource instances whose business importance level is higher than the preset importance level threshold and whose data sensitivity level is higher than the preset sensitivity level threshold as high-value target nodes; High-value target nodes that have been visited at least once in the node sequence set are selected to form a high-value target node set. For each node in the high-value target node set, the average first-visit time step from the initial infected node is calculated. The average first-visit time step is represented by the average number of steps from the initial infected node to the node in all random walk paths that visit the node, and is used to quantify the expected speed at which the threat spreads to the critical target.

7. The cloud computing-based network security situation awareness method according to claim 4, characterized in that, The process involves dividing the threat evolution into stages based on the access time step, and ultimately outputting a threat evolution situation projection result that includes diffusion path patterns, key springboard nodes, a set of high-value target nodes, and the division of threat evolution stages. Extract the access time step sequence generated by a single random walk simulation, wherein the access time step sequence records the number of simulated steps visited by each node on the walk path; Statistical analysis is performed on all the access time steps obtained from multiple random walk simulations to calculate the average access time step for each visited graph node. The average access time step is the average of the access time steps of the node in all random walk paths that include it. Sort all visited graph nodes in ascending order of their average access time steps, and generate an ascending sequence list of nodes in ascending order of their average access time steps. The ascending sequence list is divided into three stages. The time step threshold of the first stage is a first preset ratio of the total number of simulation steps, and the time step threshold of the second stage is a second preset ratio of the total number of simulation steps, wherein the first preset ratio is less than the second preset ratio. All nodes whose average access time step is less than the first phase time step threshold are classified as initial penetration phase nodes. All nodes whose average access time step is greater than or equal to the first stage time step threshold and less than the second stage time step threshold are classified as nodes in the lateral movement stage. From the nodes whose average access time step is greater than or equal to the second phase time step threshold, nodes belonging to the high-value target node set are selected and classified as final attack phase nodes. For other nodes whose average access time step is greater than or equal to the second stage time step threshold but do not belong to the high-value target node set, they are classified as extensions of the lateral movement stage nodes. By integrating the results of multiple random walk simulations, for each graph node, the frequency of its classification into the initial penetration stage, the lateral movement stage, and the final attack stage is counted, and the stage with the highest frequency is used as the final stage label for that graph node. Based on the final stage labels of all graph nodes, the diffusion path pattern of the threat in the cloud network topology is reconstructed. The diffusion path pattern describes the typical path of the threat from the initial penetration stage node, through the lateral movement stage node, and finally to the final attack stage node. The key springboard nodes, the set of high-value target nodes, the ascending sequence list of nodes according to the average access time step, the final stage label of each graph node, and the diffusion path pattern are structurally encapsulated to generate the threat evolution situation inference results.

8. The cloud computing-based network security situation awareness method according to claim 1, characterized in that, The step of invoking the application programming interface of the cloud computing management platform based on the threat evolution scenario projection results to generate cloud-native adaptive protection instructions that match the threat evolution stage, and then distributing the cloud-native adaptive protection instructions to the corresponding cloud security execution nodes, includes: Analyze the threat evolution situation projection results and extract the threat evolution stage division information and key stepping stone node information contained therein; If the threat evolution stage is the initial penetration stage, a cloud workload micro-isolation strategy is generated for the initial infected node and its adjacent nodes, and all outbound connection attempts related to the target cloud resource type and port indicated by the lateral movement inference vector in the threat evolution situation simulation result are blocked. The cloud workload micro-isolation strategy includes embedding a lightweight security agent in the host virtual machine or container of the node. The security agent redirects all network traffic of the node to the user-space protocol stack for deep packet inspection. If the threat evolution stage is the lateral movement stage, cloud network traffic access control rules are generated for the critical jump node. The cloud network traffic access control rules are implemented by calling the software-defined network controller interface of the cloud platform. Specifically, an access control list entry is added to the virtual switch of the subnet where the critical jump node is located. This access control list entry denies all transport layer protocol packets from the Internet Protocol address of the critical jump node that are targeted at the Internet Protocol addresses of nodes in the set of high-value target nodes, while allowing management traffic from the security operation and maintenance management node to pass through. If the threat evolution stage is the final attack stage, a dynamic authentication policy for cloud identity credentials is generated for nodes in the set of high-value target nodes. The dynamic authentication policy for cloud identity credentials is implemented by integrating cloud identity and access management services. Specifically, it temporarily increases the multi-factor authentication level required to access nodes in the set of high-value target nodes and injects an additional behavioral biometric verification step into the access session. The behavioral biometrics include mouse movement trajectory patterns and keyboard typing rhythm patterns. Integrate micro-segmentation policies, access control rules, and dynamic authentication policies generated for different stages of threat evolution, and group them according to the scope of cloud resources where the policies take effect and the type of policies to form a set of policy instructions; Generate a unique transaction identifier for each policy instruction in the policy instruction set, and mark the expected effective time and automatic expiration time of the policy instruction; Call the application programming interface of the cloud computing management platform to submit the set of policy instructions in batches to the security policy orchestration engine of the cloud computing management platform in the form of transaction requests; The monitoring cloud computing management platform provides execution feedback on the set of policy instructions. The execution feedback includes confirmation of successful policy issuance, rollback of policy issuance failure, and notification that the policy has taken effect. Based on the execution feedback, if the policy issuance fails, a rollback operation is performed according to the transaction identifier to cancel all policy instructions issued within the corresponding transaction and record the failure log. If the policy is successfully issued and takes effect, the policy instruction set, the corresponding transaction identifier, and the effective status are packaged into a final cloud-native adaptive protection instruction transaction package, which is then issued to the cloud security execution node pointed to by the policy through a secure channel. The cloud security execution node includes a host security agent, a software-defined network switch, and a cloud identity and access management service endpoint.

9. A cloud computing-based network security situation awareness system, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the cloud-based network security situation awareness method according to any one of claims 1 to 8 by executing the machine-executable instructions.

10. A computer program product, characterized in that, The computer program product includes machine-executable instructions stored in a computer-readable storage medium. The processor of the cloud-based network security situation awareness system reads the machine-executable instructions from the computer-readable storage medium and executes the machine-executable instructions, causing the cloud-based network security situation awareness system to perform the cloud-based network security situation awareness method according to any one of claims 1 to 8.

Images