SDN behavior modeling and anomaly detection method and device based on event context

Abstract

The present application relates to an SDN behavior modeling and anomaly detection method and device based on event context, wherein the method includes: extracting the control logic and data dependency of the SDN controller, and obtaining the instrumentation information of the target key operation based on the control logic and data dependency; performing code instrumentation when the SDN controller is started; receiving network activity information sent by the instrumentation point, and generating an SDN network audit log based on the network activity information; reconstructing the controller execution trace from the SDN network audit log, extracting the SDN network behavior graph and path information; detecting abnormal behavior based on the context of events in the SDN network behavior path information, and generating network anomaly information provided to network operation and maintenance personnel. The embodiment of the present application can reconstruct the network behavior graph from the SDN network audit log, realize abnormal behavior analysis based on the SDN network event context, reduce the dependence of network abnormal behavior identification on manual analysis, and effectively assist in anomaly detection, root cause diagnosis and defense decision-making.

Description

Technical Field

[0001] The present application relates to the fields of computer, communication and information security technology, and in particular to an event context-based SDN behavior modeling and anomaly detection method and device. Background Art

[0002] SDN (Software Defined Networking) was originally designed to separate the control and forwarding functions in traditional network routing systems and provide network programmability. The openness and flexibility of SDN have brought new possibilities in optimizing network resource utilization, supporting virtualization, and accelerating technology updates. It has created unprecedented opportunities for network development and has received widespread attention from academia and industry. SDN-related concepts and technologies have been applied in many fields such as data center networks, wireless LANs, cloud computing, and network virtualization.

[0003] In related technologies, SDN networks may be vulnerable to security threats from untrusted data plane hosts or switches, untrusted control plane applications, controller vulnerabilities, inter-plane communication vulnerabilities, etc. The complexity of SDN control logic and network behavior makes network anomaly detection and source tracing challenging.

[0004] Related technologies typically reconstruct the execution trace of the SDN control plane based on knowledge of control logic and data flows, and design query algorithms to trace the source of specific network anomalies. However, facing multi-layer and multi-source SDN network attacks, automated anomaly identification and behavior interpretation based on cross-plane SDN network behavior models remains an important research direction. Summary of the Invention

[0005] The present application provides an event context-based SDN behavior modeling and anomaly detection method and device to solve the burden of the audit process of SDN network anomalies in related technologies relying on operation and maintenance personnel to manually identify abnormal behaviors in the traceability map. It provides automated suspicious event extraction, identification, and description, assists in quickly identifying and explaining abnormal behaviors, and improves audit efficiency.

[0006] In a first aspect, an embodiment of the present application provides an SDN behavior modeling and anomaly detection method based on event context, comprising the following steps: extracting the control logic and data dependencies of the SDN controller, and obtaining the instrumentation information of the target key operation according to the control logic and the data dependencies; performing code instrumentation when the SDN controller is started according to the instrumentation information of the target key operation; receiving network activity information sent by the instrumentation point, and generating an SDN network audit log according to the network activity information; reconstructing the controller execution trace from the SDN network audit log, and extracting the SDN network behavior graph and path information; detecting abnormal behavior according to the context of the event in the SDN network behavior path information, and generating network anomaly information provided to network operation and maintenance personnel.

[0007] Optionally, in one embodiment of the present application, the extracting of the control logic and data dependencies of the SDN controller and obtaining the instrumentation information of the target key operation based on the control logic and the data dependencies include: identifying the control logic and data dependencies in the SDN controller program; identifying the inter-module method calls and message passing operations in the SDN controller and the key network status variables maintained in the SDN controller and the read and write operations on the variables; and generating auxiliary information of the instrumentation points of the target key operation.

[0008] Optionally, in one embodiment of the present application, reconstructing the controller execution trace from the SDN network audit log and extracting the SDN network behavior graph and path information includes: reconstructing the controller execution trace based on the SDN audit log, including the function-level call graph and key data flow information of the control plane to generate the SDN network behavior graph; generating path information from the SDN network behavior graph.

[0009] Optionally, in one embodiment of the present application, before detecting abnormal behavior based on the context of events in the SDN network behavior path information, it also includes: using an encoder-decoder model to learn network behavior patterns, extracting path information in normal network behavior graphs for model training, and using the trained model to calculate the prediction error of the network behavior path to be detected, wherein the prediction error is calculated using cross entropy.

[0010] Optionally, in one embodiment of the present application, detecting abnormal behavior according to the context of the event in the SDN network behavior path information includes: evaluating the abnormality degree of the network behavior based on the prediction error.

[0011] The second aspect of the present application provides an SDN behavior modeling and anomaly detection device based on event context, including: an acquisition module, used to extract the control logic and data dependencies of the SDN controller, and obtain the insertion information of the target key operation based on the control logic and the data dependencies; an insertion module, used to perform code insertion when the SDN controller is started according to the insertion information of the target key operation; a receiving module, used to receive network activity information sent by the insertion point, and generate an SDN network audit log based on the network activity information; an extraction module, used to reconstruct the controller execution trace from the SDN network audit log, and extract the SDN network behavior graph and path information; and a generation module, used to detect abnormal behavior according to the context of the event in the SDN network behavior path information, and generate network anomaly information provided to network operation and maintenance personnel.

[0012] Optionally, in one embodiment of the present application, the acquisition module includes: a first parsing unit, used to identify control logic and data dependencies in the SDN controller program; an identification unit, used to identify inter-module method calls and message passing operations in the SDN controller and key network status variables maintained in the SDN controller and read and write operations on the variables; a first generation unit, used to generate insertion point auxiliary information of the target key operation.

[0013] Optionally, in one embodiment of the present application, the extraction module includes: a second parsing unit, used to reconstruct the controller execution trace based on the SDN audit log, including the function-level call graph and key data flow information of the control plane, to generate the SDN network behavior graph; a second generation unit, used to generate path information from the SDN network behavior graph.

[0014] Optionally, in one embodiment of the present application, it also includes: a calculation module, which is used to use an encoder-decoder model to learn the network behavior pattern before detecting abnormal behavior based on the context of the event in the SDN network behavior path information, extract the path information in the normal network behavior graph for model training, and use the trained model to calculate the prediction error of the network behavior path to be detected, wherein the prediction error is calculated using cross entropy.

[0015] Optionally, in one embodiment of the present application, the generating module includes: an evaluating unit, configured to evaluate the abnormality degree of the network behavior based on the prediction error.

[0016] An embodiment of the third aspect of the present application provides an electronic device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the event context-based SDN behavior modeling and anomaly detection method as described in the above embodiment.

[0017] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-mentioned event context-based SDN behavior modeling and anomaly detection method.

[0018] The embodiments of this application can reconstruct network behavior graphs from SDN network audit logs and perform abnormal behavior analysis based on the contextual information of SDN network events, reducing the reliance on manual analysis for identifying abnormal network behavior and effectively assisting in anomaly detection, root cause diagnosis, and defense decision-making. This solves the burden of SDN network anomaly audits in related technologies, which rely on operations and maintenance personnel to manually identify abnormal behaviors in traceability graphs. The application provides automated extraction, identification, and description of suspicious events, assisting in the rapid identification and interpretation of abnormal behaviors and improving audit efficiency.

[0019] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0021] Figure 1 Flowchart of an SDN behavior modeling and anomaly detection method based on event context provided according to an embodiment of the present application;

[0022] Figure 2 Schematic diagram of the principle of an SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application;

[0023] Figure 3a Schematic diagram of the principle of an SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application;

[0024] Figure 3b This is a partially enlarged diagram of a principle schematic diagram of an SDN behavior modeling and anomaly detection method based on event context according to an embodiment of the present application;

[0025] Figure 3c This is another partially enlarged diagram of the principle schematic diagram of the SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application;

[0026] Figure 3d This is another partially enlarged diagram of the principle schematic diagram of the SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application;

[0027] Figure 4a Schematic diagram of the principle of an SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application;

[0028] Figure 4b This is another partially enlarged diagram of the principle schematic diagram of the SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application;

[0029] Figure 4c This is another partially enlarged diagram of the principle schematic diagram of the SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application;

[0030] Figure 5 Schematic diagram of the principle of an SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application;

[0031] Figure 6 Schematic diagram of a block diagram of an SDN behavior modeling and anomaly detection device based on event context according to an embodiment of the present application;

[0032] Figure 7 A schematic diagram of the structure of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0033] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0034] The following describes the SDN behavior modeling and anomaly detection method, device, electronic device and storage medium based on event context of the embodiment of the present application with reference to the accompanying drawings. In view of the fact that SDN networks may be subject to security threats from untrusted data plane hosts or switches, untrusted control plane applications, controller vulnerabilities, inter-plane communication vulnerabilities, etc. in actual applications, and at the same time, the complexity of SDN control logic and network behavior makes network anomaly detection and traceability analysis challenging, the present application provides an SDN behavior modeling and anomaly detection method based on event context, in which the network behavior graph can be reconstructed from the SDN network audit log, and abnormal behavior analysis can be achieved based on the context information of SDN network events, effectively assisting in anomaly detection, root cause diagnosis and defense decision-making. As a result, the burden of the audit process of SDN network anomalies in the related technology relying on the operation and maintenance personnel to manually identify abnormal behaviors in the traceability graph is solved, and automated suspicious event extraction, identification and description are provided to assist in the rapid identification and explanation of abnormal behaviors, thereby improving audit efficiency.

[0035] Specifically, Figure 1 A flow chart of an SDN behavior modeling and anomaly detection method based on event context provided in an embodiment of the present application.

[0036] like Figure 1 As shown, the event context-based SDN behavior modeling and anomaly detection method includes the following steps:

[0037] In step S101 , the control logic and data dependency of the SDN controller are extracted, and the instrumentation information of the target key operation is obtained according to the control logic and data dependency.

[0038] In some embodiments, the SDN controller static analysis module extracts the SDN controller control logic and data dependencies through static analysis tools, uses the control flow analysis component to construct a global control flow graph, identifies key network state variables maintained in the SDN controller, represents the SDN controller program behavior as inter-module method calls and message passing and key state variable reading and writing, and generates auxiliary information of the insertion points of the above key operations.

[0039] Furthermore, embodiments of the present application can use static analysis to extract the control logic and data dependencies of the SDN controller. For example, for the JAVA-based controller Floodlight, the Soot static analysis tool can be used to convert the controller source code into bytecode, perform context-independent data flow analysis within the process and generate a method summary. Based on the method summary, the control flow graph within the method of the SDN controller program is generated, and the read and write operations of key variables are identified. By extracting the call graph between methods, a global control flow graph can be constructed.

[0040] The embodiments of the present application can extract the control logic and data dependencies of the SDN controller, and obtain the instrumentation information of the target key operations based on the control logic and data dependencies, thereby guiding the instrumentation operation, reducing the storage overhead caused by generating network activity logs, and ensuring that key information describing network behavior is recorded in the log.

[0041] Optionally, in one embodiment of the present application, the control logic and data dependencies of the SDN controller are extracted, and the instrumentation information of the target key operation is obtained based on the control logic and data dependencies, including: identifying the control logic and data dependencies in the SDN controller program; identifying the method calls and message passing operations between modules in the SDN controller and the key network status variables maintained in the SDN controller and the read and write operations on the variables; generating auxiliary information of the instrumentation points of the target key operation.

[0042] In some cases, the embodiments of the present application can statically analyze the SDN controller program, use the control flow analysis component to implement the construction of a global control flow graph, identify the key network state variables maintained in the SDN controller, and identify the control logic and data dependencies in the SDN controller program, and generate auxiliary information of the insertion points of the target key operations through the inter-module method calls and message passing operations in the SDN controller and the key network state variables maintained in the SDN controller and the read and write operations on the variables.

[0043] Among them, the embodiment of the present application can use static analysis to extract the control logic and data dependencies of the SDN controller. For example, for the JAVA language-based controller Floodlight, the Soot static analysis tool can be used to convert the controller source code into bytecode, perform context-independent data flow analysis within the process and generate a method summary, generate the method control flow graph within the SDN controller program based on the method summary, identify the read and write operations of key variables, and construct a global control flow graph by extracting the call graph between methods.

[0044] Specifically, the SDN controller code will be converted into Jimple intermediate representation by Soot, involving 15 core instructions. The program control flow graph is generated by analyzing the composition of statement units. By analyzing the assignment and reference relationships between variables, the data flow from fields, parameters to fields, parameters and return values ​​within the method is recorded to obtain the program's data flow summary. At the same time, the statement unit's call to the method and the read and write operations on the class member variables are identified, simplifying the control flow graph into an execution flowchart of four basic operations: call, read, write, and start.

[0045] The embodiments of the present application can identify key network status variables maintained in the SDN controller, and identify the control logic and data dependencies in the SDN controller program. Through the inter-module method calls and message passing operations in the SDN controller and the key network status variables maintained in the SDN controller and the read and write operations on the variables, auxiliary information of the insertion points of the target key operations is generated, taking into account the participation of multiple parties such as hosts, switches, controllers, and applications, to achieve multi-dimensional status monitoring and integration.

[0046] In step S102 , code instrumentation is performed when the SDN controller is started according to the instrumentation information of the target key operation.

[0047] It is understandable that the embodiment of the present application can use the SDN controller code instrumentation module to perform code instrumentation when the controller is started according to the instrumentation information.

[0048] Specifically, the embodiment of the present application can perform instrumentation when the SDN controller is started according to the instrumentation information of the target key operation, and use code instrumentation to monitor the execution of the controller core services and applications. The code instrumentation module inserts hooks into key operations based on the static analysis results to send network activity information to the log collection module during program operation.

[0049] The embodiment of the present application can perform code instrumentation when the SDN controller is started according to the instrumentation information of the target key operation, thereby further ensuring that key network activity information is collected during runtime to generate audit logs, realize suspicious network behavior detection based on logs, and automatically extract, identify, and describe network anomalies.

[0050] In step S103, network activity information sent by the insertion point is received, and an SDN network audit log is generated according to the network activity information.

[0051] It is understandable that the embodiment of the present application can receive network activity information sent by the insertion point through the SDN network log collection module to generate an audit log.

[0052] As a possible implementation method, the embodiment of the present application can receive network activity information sent by the instrumentation point and generate an SDN network audit log based on the network activity information. The code instrumentation module inserts hooks in key operations based on the static analysis results to send the network activity information to the log collection module during the program running process. The collected logs include the timestamp, thread ID, operation type (call, read, write, start, etc.) of the key network activities, the calling method name, the called method name, the name of the variable being read and written, the virtual address of the variable being read and written, the detailed field information of the storage being read and written, and the key category object information being passed, such as switch objects, port objects, device objects, link objects, etc.

[0053] The embodiment of the present application can receive network activity information sent by the insertion point and generate an SDN network audit log based on the network activity information, thereby realizing log-based detection of suspicious network behavior, reducing the dependence of SDN network log analysis and attack tracing on expert knowledge and manual processing, and improving audit efficiency.

[0054] In step S104, the controller execution trace is reconstructed from the SDN network audit log, and the SDN network behavior graph and path information are extracted.

[0055] It is understandable that the SDN network audit log in the embodiment of the present application can be reconstructed into a behavior graph in the SDN network behavior reconstruction and path extraction module.

[0056] In some cases, in the SDN network behavior reconstruction and path extraction module in the embodiments of the present application, the audit log is reconstructed into a behavior graph:

[0057] G={U1,U2,…,U N ,E inter}=(V,E intra ,E inter )

[0058] Among them, U i (i=1,..,N) represents the subgraph corresponding to the i-th execution unit.

[0059] Furthermore, V represents five types of entity nodes (as shown in Table 1), including:

[0060] T V ={method,event,data,thread,attribute}

[0061] There are five types of nodes: "Method", "Event", "Data Entity", "Thread" and "Property". intra The edges representing the relationships between nodes in the seven types of execution units (as shown in Table 2) all have timestamp information. The specific types include:

[0062]

[0063] That is, the edges within the seven execution units of "call", "dispatch", "receive", "write", "read", "property" and "run". inter The edges between execution units represent the relationship between nodes and are used to indicate whether the same attributes and data entities in different execution units are associated.

[0064] Furthermore, for the construction of network behavior graphs, the operations of different execution units are divided by the execution unit starting points obtained through static analysis, and the execution units are associated through the read and write operations of key network state variables and important network entity characteristics (such as switch ports), so as to further automatically extract, identify and describe network abnormal behaviors, reduce the dependence of SDN network log analysis and attack tracing on expert knowledge and manual processing, and improve audit efficiency.

[0065] In one embodiment of the present application, controller execution tracing is reconstructed from SDN network audit logs, and SDN network behavior graphs and path information are extracted, including: reconstructing controller execution tracing according to SDN audit logs, including function-level call graphs and key data flow information of the control plane to generate an SDN network behavior graph; generating path information from the SDN network behavior graph.

[0066] It is understandable that for network behavior modeling, code instrumentation is used to monitor the execution of controller core services and applications, collect SDN network runtime information, reconstruct the control plane execution trace based on the SDN audit log, including the function-level call graph and key data flow information of the control plane, and generate a network behavior map.

[0067] Specifically, in the SDN network behavior reconstruction and path extraction module in the embodiment of the present application, the audit log is reconstructed into a behavior graph:

[0068] G={U1,U2,…,U N ,E inter}=(V,E intra ,E inter )

[0069] Among them, U i (i=1,..,N) represents the subgraph corresponding to the i-th execution unit.

[0070] Furthermore, V represents five types of entity nodes, including:

[0071] T V ={method,event,data,thread,attribute}

[0072] There are five types of nodes: "Method", "Event", "Data Entity", "Thread" and "Property". intra The edges representing the relationships between nodes in the seven types of execution units (as shown in Table 2) all have timestamp information. The specific types include:

[0073]

[0074] That is, the edges within the seven execution units of "call", "dispatch", "receive", "write", "read", "property" and "run". inter The edges between execution units represent the relationship between nodes and are used to indicate whether the same attributes and data entities in different execution units are associated.

[0075] The embodiments of the present application can generate an SDN network behavior graph, and by correlating the status information of each network layer, effectively assist in explaining multi-source, cross-plane SDN network behavior.

[0076] In step S105, abnormal behavior is detected according to the context of the event in the SDN network behavior path information, and network abnormality information is generated and provided to network operation and maintenance personnel.

[0077] It is understandable that the embodiments of the present application can detect abnormal behavior according to the context of events in the SDN network behavior path information through the anomaly detection module.

[0078] Among them, for the anomaly detection module, the embodiment of the present application adopts an encoder-decoder model to learn network behavior patterns, extract path information from the normal network behavior graph for model training, and the path involves key operations of multiple execution units.

[0079] Furthermore, for the anomaly detection module, the path information is converted into an m-sequence of length in, is a node or edge in the path, i is a sequence index, k=1,…,n is the execution unit index to which the node or edge belongs; the encoder-decoder model is based on As output, is the expected output, that is, using the behavioral semantics of the first n-1 execution units in the time series as context to predict the behavior of the nth execution unit.

[0080] The embodiments of the present application can detect abnormal behaviors based on the context of events in the SDN network behavior path information, generate network anomaly information provided to network operation and maintenance personnel, assist analysts in discovering the root cause of the problem and taking further defensive measures, thereby further reducing the dependence of network abnormal behavior identification on manual analysis, and effectively assisting in anomaly detection, root cause diagnosis and defensive decision-making.

[0081] Among them, in one embodiment of the present application, before detecting abnormal behavior based on the context of events in the SDN network behavior path information, it also includes: using an encoder-decoder model to learn network behavior patterns, extracting path information in the normal network behavior graph for model training, and using the trained model to calculate the prediction error of the network behavior path to be detected, wherein the prediction error is calculated using cross entropy.

[0082] In some embodiments, before detecting abnormal behavior based on the context of events in the SDN network behavior path information, an encoder-decoder model can be used to learn the network behavior pattern, and the path information in the normal network behavior graph can be extracted for model training, so that the trained model can be used to calculate the prediction error of the network behavior path to be detected. The prediction error of the model can be calculated using cross entropy, and the model can be trained with the goal of minimizing the prediction error.

[0083] In other embodiments, the prediction error of the model can be calculated using cross entropy, with the goal of minimizing the prediction error. The prediction result g is The predicted vector sequence and the true value r are The error between the embedding vector sequences is expressed as:

[0084]

[0085] in, Represents the probability of the word vector of the jth element in the prediction sequence being distributed in the i-th dimension.

[0086] The embodiments of the present application can use the trained model to calculate the prediction error of the network behavior path to be detected, where the prediction error is calculated using cross entropy, so as to further perform SDN network anomaly diagnosis and detection, effectively assisting anomaly detection, root cause diagnosis and defense decision-making.

[0087] Optionally, in one embodiment of the present application, detecting abnormal behavior according to the context of events in the SDN network behavior path information includes: evaluating the abnormality degree of the network behavior based on the prediction error.

[0088] It can be understood that the embodiments of the present application can use prediction errors to evaluate the degree of abnormality of network behavior. Paths with errors higher than a given threshold will be considered suspicious paths. The system will provide network operation and maintenance personnel with analyzable descriptions of abnormal network behavior based on the suspicious paths, such as specific hosts, flow rules, and controller processing processes, to assist security analysts in making decisions on defense plans.

[0089] In some embodiments, the prediction error of the model can be calculated using cross entropy, with the goal of minimizing the prediction error. The model is trained for a given input. The prediction result g is The predicted vector sequence and the true value r are The error between the embedding vector sequences is expressed as:

[0090]

[0091] in, Represents the probability of the word vector of the jth element in the prediction sequence being distributed in the i-th dimension.

[0092] Furthermore, using the prediction error ε predict The system assesses the degree of abnormality in network behavior. Paths with errors above a threshold are considered suspicious paths. Based on the suspicious paths, the system provides network operations personnel with analyzable descriptions of abnormal network behavior, such as specific hosts, flow rules, and controller processing, to assist security analysts in making decisions on defense solutions.

[0093] The embodiments of the present application can evaluate the degree of abnormality of network behavior based on the prediction error, thereby automatically extracting, identifying, and describing abnormal network behavior, reducing the dependence of SDN network log analysis and attack tracing on expert knowledge and manual processing, and improving audit efficiency.

[0094] Specifically, combined Figures 2 to 5As shown, a schematic diagram of the principle of the SDN behavior modeling and anomaly detection method based on event context in an embodiment of the present application is described in detail with a specific embodiment.

[0095] in, Figure 3a FIG. 1 is a schematic diagram illustrating a method for SDN behavior modeling and anomaly detection based on event context according to an embodiment of the present application. Figure 3b 、 Figure 3c and Figure 3d They are Figure 3a A partial enlarged view of Figure 4a FIG. 1 is a schematic diagram illustrating a method for SDN behavior modeling and anomaly detection based on event context according to an embodiment of the present application. Figure 4b and Figure 4c They are Figure 4a A partial enlarged view of .

[0096] like Figure 2 As shown, the embodiment of the present application may include: an SDN controller static analysis module, an SDN network log collection module, an SDN network behavior reconstruction and path extraction module, and an SDN anomaly detection module.

[0097] Specifically, in an embodiment of the present application, controller behavior modeling can be first performed through static analysis. The SDN controller static analysis module extracts the control logic and data dependencies of the SDN controller through static analysis tools, and assists in locating code insertion points. The SDN controller code insertion module collects runtime information by installing hooks to the SDN controller; secondly, through SDN network log collection and behavior reconstruction, the SDN network log collection module receives runtime network information through the application running in the SDN controller and generates a network audit log. The SDN network behavior reconstruction and path extraction module reconstructs the controller execution trace from the SDN network audit log and extracts the SDN network behavior graph and path information; thirdly, SDN anomaly detection is performed. The SDN anomaly detection module includes an encoder-decoder model trained using a normal behavior path dataset to evaluate the suspicious degree of the behavior path to be detected, provide anomaly information to analysts, and list a list of suspicious behaviors.

[0098] like Figure 3a As shown, Figure 3b This is a partially enlarged diagram of a principle diagram of an SDN behavior modeling and anomaly detection method based on event context according to an embodiment of the present application. Figure 3c This is another partially enlarged diagram of the principle schematic diagram of the SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application. Figure 3dThis is another partially enlarged diagram of the principle diagram of the SDN behavior modeling and anomaly detection method based on event context according to an embodiment of the present application. Static analysis can be used to extract the control logic and data dependencies of the SDN controller. Taking the JAVA language-based controller Floodlight as an example, the Soot static analysis tool can be used to convert the controller source code into bytecode, perform context-independent data flow analysis within the process and generate a method summary. Based on the method summary, the control flow graph within the method of the SDN controller program is generated, and the read and write operations of key variables are identified. By extracting the call graph between methods, a global control flow graph can be constructed.

[0099] Specifically, the SDN controller code will be converted into Jimple intermediate representation by Soot, involving 15 core instructions. The program control flow graph is generated by analyzing the composition of statement units. By analyzing the assignment and reference relationships between variables, the data flow from fields, parameters to fields, parameters and return values ​​within the method is recorded to obtain the program's data flow summary. At the same time, the statement unit's call to the method and the read and write operations on the class member variables are identified, simplifying the control flow graph into an execution flowchart of four basic operations: call, read, write, and start.

[0100] For example, the addRule() method in the access control application of the Floodlight controller, which adds access control rules, contains a control flow graph that includes method calls and field read and write operations, which are connected in sequence according to the execution order, and control nodes are added to represent jumps in the program.

[0101] The code instrumentation module in the embodiment of the present application inserts hooks into key operations based on the static analysis results to send network activity information to the log collection module during program execution. The collected logs include the timestamp, thread ID, operation type (call, read, write, start, etc.) of the key network activities, the name of the calling method, the name of the called method, the name of the variable being read and written, the virtual address of the variable being read and written, the detailed field information of the storage being read and written, and the key category object information being passed (such as switch objects, port objects, device objects, link objects, etc.).

[0102] Among them, the start operation is the starting point of the execution unit in the SDN controller program. For example, the controller starts processing the uplink message received from the switch. The starting method of the start operation can be obtained through static analysis. The code instrumentation module will install a hook before the start method starts to execute. When the method is about to be executed, the log generation module in the controller will record the start operation information sent by the hook. The network behavior reconstruction module divides the thread operation sequence according to the start operation to obtain N independent execution units.

[0103] Next, you can Figure 4aThe SDN behavior modeling and anomaly detection method based on event context in the embodiment of the present application is further elaborated in detail, wherein: Figure 4b This is another partially enlarged diagram of the principle schematic diagram of the SDN behavior modeling and anomaly detection method based on event context according to one embodiment of the present application. Figure 4c This is another partially enlarged diagram of the principle schematic diagram of the SDN behavior modeling and anomaly detection method based on event context according to an embodiment of the present application.

[0104] like Figure 4a As shown in the figure, the SDN network behavior reconstruction and path extraction module reconstructs the audit log into a behavior graph:

[0105] G={U1,U2,…,U N ,E inter}=(V,E intra ,E inter )

[0106] Among them, U i (i=1,..,N) represents the subgraph corresponding to the i-th execution unit.

[0107] Furthermore, V represents five types of entity nodes (as shown in Table 1), including:

[0108] T V ={method,event,data,thread,attribute}

[0109] In the embodiments of the present application, "method" refers to a processing method in an SDN controller program, including a class name and a method name. "Event" refers to a message transmitted between different modules in the controller. For example, when a host management module detects a new host, it dispatches a host addition event (DEVICE_ADDED) to a module that monitors the event (e.g., an access control module, a firewall module, etc.). "Data" refers to a data object instance used to store key network status information in the SDN controller, such as an instance of a host (HOST), a switch (SWITCH), a link (LINK), and other objects. "Thread" refers to a thread in the controller, represented by a thread ID. The thread IDs in different execution units need to be distinguished. "Attribute" refers mainly to the attributes of the event, that is, the information contained in the event transmitted between modules, such as the MAC address and IP address of the device contained in the DEVICE_ADDED event. Table 1 is a table of behavior graph node types:

[0110] Table 1

[0111] Node Type describe method Processing method in the controller, including class name and method name event Messages passed between different modules data Data object instance storing key network status information thread Thread ID attribute Such as switch DPID, port number, MAC address, IP address, etc.

[0112] Among them, E intra The edges representing the relationships between nodes in the seven types of execution units (as shown in Table 2) all have timestamp information. The specific types include:

[0113]

[0114] "Call" refers to the edge from the calling method node to the called method node, indicating the calling relationship. "Dispatch" refers to the edge from the method node that dispatches the event to the dispatched event node. "Receive" refers to the edge from the monitored event node to the method node that monitors the event. "Write" refers to the edge from the method node that performs the write operation to the data entity node being written. "Read" refers to the edge from the data entity node being read to the method node that performs the read operation. "Attribute" refers to the edge from the event node to the attribute node it contains. "Run" refers to the edge from the thread node to the method node it runs. Table 2 is a table of behavior graph edge types:

[0115] Table 2

[0116] Edge Type describe call Calling method → ​​called method dispatch Method that dispatches an event → the event being dispatched receive Monitored event → Method for monitoring event write Method → ​​Data Entity readBy Data entity → method hasAttribute Event → Property run Thread → Method

[0117] Among them, E inter Represents the edge between execution units that represents the relationship between nodes. It is used to indicate whether to associate the same attributes and data entities in different execution units. For example, if two execution units read and write the same data object instance, there is an inter edge between the corresponding data entity nodes.

[0118] Furthermore, structured text is used to represent the elements in the execution unit subgraph. For example, the data entity node "deviceMap#85617803#3" will be structured as "deviceMap<*>". According to the structured execution unit subgraph, the subgraph pattern set P can be obtained.

[0119] Furthermore, the frequent operations in the network behavior are identified through the Maximum Common Subgraph (MCS) of all execution units belonging to the same pattern, and the behavior graph is compressed according to the characteristics of MCS to reduce the noise caused by frequent operations and more accurately distinguish normal and abnormal behaviors. Specifically, for each execution unit subgraph pattern p i ∈P, all belonging to pattern p i The execution unit subgraph of The largest common subgraph of Expressed as:

[0120]

[0121] For any execution unit subgraph Either side of If e meets the following conditions, it will be deleted:

[0122]

[0123] Among them, s(·) is the structured representation function, N e Refers to the number of times e is observed in the global behavior graph G, N E Refers to the internal edge of the execution unit in the global behavior graph G (E intra ), δ e is a frequency threshold set artificially, that is, for the edges belonging to the largest common subgraph after structured representation, the frequency of occurrence is higher than the threshold δ e The operations will be regarded as the operations frequently executed by the controller, which contribute little to the explanation of behavioral semantics and need to be deleted.

[0124] Furthermore, the slave execution unit point to The edge e ab ∈E inter , if e ab Delete it if the following conditions are met:

[0125]

[0126] in, Refers to pattern p b The total number of execution unit subgraphs, N U Refers to the total number of all execution unit subgraphs, δ u The frequency threshold is artificially set, that is, the edges between nodes tend to point to execution units that appear less frequently. Compared with frequently appearing execution units, uncommon execution units contribute more to the semantics of complex network behaviors involving multiple units.

[0127] Furthermore, in the SDN network behavior reconstruction and path extraction module, a variety of methods can be used to generate fixed-length paths contained in the behavior graph, such as random walks; the type of the path start or end node can also be specified, for example, using a specific attribute node or a network state variable node as the starting point. Specifically, it can be set to start from the data entity node or a specific type of attribute node (such as a switch port attribute node, an IP address attribute node, etc.) in the behavior graph, and search for a path of a certain length in the global behavior graph G. The path information can be represented as a triple (v i ,e ij ,v j ) (where e ij Represented by node vi Points to node v j The order of the triples in the sequence depends on the edge e ij The timestamp attribute of the

[0128] Next, if Figure 5 As shown: In the embodiment of the present application, for the anomaly detection module, the path information can be converted into an m-sequence of length in is a node or edge in the path, i is a sequence index, k=1,…,n is the execution unit index to which the node or edge belongs; the encoder-decoder model is based on As output, is the expected output, that is, using the behavioral semantics of the first n-1 execution units in the time series as context to predict the behavior of the nth execution unit.

[0129] When converting path information into a sequence, the embodiment of the present application can pre-embed the data entity nodes and attribute nodes, retaining only the context information of the node in the path, and mapping the node name to a combination of its data type (such as HOST, SWITCH, LINK, etc.) or attribute type (such as MAC, IP, SWITCH_PORT) and the serial number of the node in the order of appearance in the time sequence in the path.

[0130] Furthermore, when converting path information into a sequence, the length of the sequence is compressed by deleting edges of specific types. For example, by deleting run-type edges in the path, a large number of thread operations are omitted, while important event dispatching and monitoring, method calls, and data entity read and write operations are retained. Specifically, a path information sequence obtained from the log obtained by the Floodlight controller instrumentation indicates that two messages from the same switch port triggered the host device addition operation and the forwarding destination device information search operation. Table 3 is an example of a path information sequence:

[0131] Table 3

[0132]

[0133] In the embodiment of the present application, one-hot encoding can be used to embed the elements (tokens) in the sequence, that is, for the list W consisting of all tokens, W = [w1, w2, ..., w d ], where w i ∈W(i=1,…,d)The embedded vector is [0,…,1,…,0] d , where the i-th item is 1 and the rest are 0, and d is the dimension of the word vector obtained by embedding.

[0134] Furthermore, the embodiment of the present application uses the cross entropy to calculate the prediction error of the model, and trains the model with the goal of minimizing the prediction error. The model is used to calculate the prediction error of the model for a given input. The prediction result g is The predicted vector sequence and the true value r are The error between the embedding vector sequences is expressed as:

[0135]

[0136] in, Represents the probability of the word vector of the jth token in the prediction sequence being distributed in the i-th dimension, ε predict It is expressed as the prediction error to evaluate the abnormality of network behavior, d is the dimension of the word vector obtained by embedding, if the jth string in the true value r is w t ∈w, then In addition, the softmax function can be used to normalize the prediction result g to ensure the stability of the training process.

[0137] Furthermore, the embodiment of the present application can use the prediction error ε predict The system assesses the degree of abnormality in network behavior. Paths with errors above a threshold are considered suspicious paths. Based on the suspicious paths, the system provides network operations personnel with analyzable descriptions of abnormal network behavior, such as specific hosts, flow rules, and controller processing, to assist security analysts in making decisions on defense solutions.

[0138] The embodiments of the present application can identify suspicious network behaviors by detecting the semantics of abnormal behaviors, automatically extract, identify, and describe abnormal network behaviors, reduce the dependence of SDN network log analysis and attack tracing on expert knowledge and manual processing, improve audit efficiency, and at the same time expand rule-based anomaly detection methods that rely on expert knowledge.

[0139] The event-context-based SDN behavior modeling and anomaly detection method proposed in this application embodiment can reconstruct network behavior graphs from SDN network audit logs, enabling abnormal behavior analysis based on the contextual information of SDN network events. This reduces the reliance on manual analysis for identifying abnormal network behavior, effectively assisting in anomaly detection, root cause diagnosis, and defense decision-making. This resolves the burden of SDN network anomaly auditing, which relies on operations personnel manually identifying abnormal behavior in traceability graphs, as is often the case in related technologies.

[0140] Next, an SDN behavior modeling and anomaly detection device based on event context according to an embodiment of the present application will be described with reference to the accompanying drawings.

[0141] Figure 6Schematic diagram of an SDN behavior modeling and anomaly detection device based on event context according to an embodiment of the present application.

[0142] like Figure 6 As shown, the event context-based SDN behavior modeling and anomaly detection device 10 includes: an acquisition module 100 , an instrumentation module 200 , a receiving module 300 , an extraction module 400 and a generation module 500 .

[0143] Specifically, the acquisition module 100 is used to extract the control logic and data dependency of the SDN controller, and acquire the instrumentation information of the target key operation according to the control logic and data dependency.

[0144] The instrumentation module 200 is used to perform code instrumentation when the SDN controller is started according to the instrumentation information of the target key operation.

[0145] The receiving module 300 is configured to receive network activity information sent by the insertion point and generate an SDN network audit log based on the network activity information.

[0146] The extraction module 400 is used to reconstruct the controller execution trace from the SDN network audit log and extract the SDN network behavior graph and path information.

[0147] The generation module 500 is used to detect abnormal behavior according to the context of events in the SDN network behavior path information, and generate network abnormality information provided to network operation and maintenance personnel.

[0148] Optionally, in one embodiment of the present application, the acquisition module 100 includes: a first parsing unit, a recognition unit and a first generation unit.

[0149] The first parsing unit is used to identify the control logic and data dependency in the SDN controller program;

[0150] An identification unit, used to identify inter-module method calls and message passing operations in the SDN controller, key network state variables maintained in the SDN controller, and read and write operations on the variables;

[0151] The first generating unit is configured to generate auxiliary information of an instrumentation point of a target key operation.

[0152] Optionally, in one embodiment of the present application, the extraction module 400 includes: a second parsing unit and a second generating unit.

[0153] The second parsing unit is used to reconstruct the controller execution trace based on the SDN audit log, including the function-level call graph and key data flow information of the control plane, so as to generate the SDN network behavior graph;

[0154] The second generating unit is used to generate path information from the SDN network behavior graph.

[0155] Optionally, in one embodiment of the present application, the event context-based SDN behavior modeling and anomaly detection device 10 further includes: a calculation module.

[0156] Among them, the calculation module is used to use the encoder-decoder model to learn the network behavior pattern before detecting abnormal behavior based on the context of events in the SDN network behavior path information, extract the path information in the normal network behavior graph for model training, and use the trained model to calculate the prediction error of the network behavior path to be detected, where the prediction error is calculated using cross entropy.

[0157] Optionally, in one embodiment of the present application, the generation module includes: an evaluation unit.

[0158] The evaluation unit is used to evaluate the abnormality of network behavior based on the prediction error.

[0159] It should be noted that the above explanation of the embodiment of the SDN behavior modeling and anomaly detection method based on event context is also applicable to the SDN behavior modeling and anomaly detection device based on event context of this embodiment, and will not be repeated here.

[0160] The event-context-based SDN behavior modeling and anomaly detection device proposed in the embodiments of this application can reconstruct network behavior graphs from SDN network audit logs, implement abnormal behavior analysis based on the contextual information of SDN network events, reduce the reliance on manual analysis for identifying network abnormal behavior, and effectively assist in anomaly detection, root cause diagnosis, and defense decision-making. This solves the burden of SDN network anomaly auditing in related technologies, which relies on operations and maintenance personnel to manually identify abnormal behavior in traceability graphs. It provides automated suspicious event extraction, identification, and description, assists in quickly identifying and explaining abnormal behavior, and improves audit efficiency.

[0161] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include:

[0162] Memory 701 , processor 702 , and computer programs stored in the memory 701 and executable on the processor 702 .

[0163] When the processor 702 executes the program, the event context-based SDN behavior modeling and anomaly detection method provided in the above embodiment is implemented.

[0164] Furthermore, the electronic device further includes:

[0165] The communication interface 703 is used for communication between the memory 701 and the processor 702 .

[0166] The memory 701 is used to store computer programs that can be run on the processor 702 .

[0167] The memory 701 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0168] If the memory 701, processor 702, and communication interface 703 are implemented independently, the communication interface 703, memory 701, and processor 702 can be interconnected via a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 7 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0169] Optionally, in a specific implementation, if the memory 701, the processor 702 and the communication interface 703 are integrated on a chip, the memory 701, the processor 702 and the communication interface 703 can communicate with each other through an internal interface.

[0170] The processor 702 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0171] This embodiment further provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, the above-mentioned SDN behavior modeling and anomaly detection method based on event context is implemented.

[0172] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and features of different embodiments or examples without contradiction.

[0173] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Thus, a feature specified as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of this application, "N" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0174] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing a custom logical function or process step, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may be performed in a different order than shown or discussed, including performing functions in a substantially simultaneous manner or in a reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application pertain.

[0175] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection with one or N wires (electronic devices), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program can be obtained electronically by optically scanning the paper or other medium and then editing, interpreting or processing it in other suitable ways as necessary, and then storing it in a computer memory.

[0176] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiment, the N steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used to implement: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0177] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0178] In addition, the functional units in the various embodiments of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into a module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0179] The storage medium mentioned above may be a read-only memory, a magnetic disk, or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application. Persons skilled in the art may make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present application.

Claims

1. An SDN behavior modeling and anomaly detection method based on event context, characterized in that: The following steps are involved: Extracting the control logic and data dependency of the SDN controller, and obtaining instrumentation information of the target key operation based on the control logic and the data dependency; Performing code instrumentation when the SDN controller is started according to the instrumentation information of the target key operation; Receive network activity information sent by the insertion point and generate an SDN network audit log based on the network activity information; Reconstructing controller execution traces from the SDN network audit logs to extract SDN network behavior graphs and path information; as well as Detect abnormal behavior based on the context of events in the SDN network behavior path information, and generate network abnormality information for network operation and maintenance personnel; Before detecting abnormal behavior according to the context of the event in the SDN network behavior path information, the method further includes: An encoder-decoder model is used to learn network behavior patterns, and path information in normal network behavior graphs is extracted for model training. The trained model is then used to calculate the prediction error of the network behavior path to be detected, where the prediction error is calculated using cross entropy.

2. The method according to claim 1, characterized in that The extracting the control logic and data dependency of the SDN controller, and obtaining the instrumentation information of the target key operation according to the control logic and the data dependency, includes: Identifying control logic and data dependencies in the SDN controller program; Identify inter-module method calls and message passing operations in the SDN controller and key network state variables maintained in the SDN controller and read and write operations on the variables; Generate instrumentation point auxiliary information for the target key operation.

3. The method according to claim 1, characterized in that The reconstructing controller execution trace from the SDN network audit log and extracting SDN network behavior graph and path information includes: Reconstructing the controller execution trace based on the SDN audit log, including the function-level call graph and key data flow information of the control plane, to generate the SDN network behavior graph; Generate path information from SDN network behavior graph.

4. The method according to claim 1, wherein The detecting abnormal behavior according to the context of the event in the SDN network behavior path information includes: The abnormality degree of the network behavior is evaluated based on the prediction error.

5. An SDN behavior modeling and anomaly detection device based on event context, characterized in that: include: An acquisition module is used to extract the control logic and data dependency of the SDN controller, and obtain the instrumentation information of the target key operation based on the control logic and the data dependency; An instrumentation module, configured to perform code instrumentation when the SDN controller is started according to the instrumentation information of the target key operation; A receiving module is used to receive network activity information sent by the insertion point and generate an SDN network audit log based on the network activity information; An extraction module, configured to reconstruct controller execution traces from the SDN network audit logs and extract SDN network behavior graphs and path information; as well as The generation module is used to detect abnormal behavior according to the context of the event in the SDN network behavior path information, and generate network abnormality information provided to network operation and maintenance personnel.

6. The device according to claim 5, characterized in that The acquisition module includes: A first parsing unit, configured to identify control logic and data dependencies in the SDN controller program; an identification unit, configured to identify inter-module method calls and message passing operations in the SDN controller, key network state variables maintained in the SDN controller, and read and write operations on the variables; The first generating unit is configured to generate the instrumentation point auxiliary information of the target key operation.

7. The device according to claim 5, characterized in that The extraction module includes: a second parsing unit, configured to reconstruct controller execution traces based on the SDN audit logs, including a function-level call graph and key data flow information of the control plane, to generate the SDN network behavior graph; The second generating unit is used to generate path information from the SDN network behavior graph.

8. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the SDN behavior modeling and anomaly detection method based on event context according to any one of claims 1 to 4.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the SDN behavior modeling and anomaly detection method based on event context as described in any one of claims 1 to 4.

Images