A security detection and assessment method and device for software-defined satellite networks

Abstract

The present invention discloses a security detection and assessment method and device for software-defined satellite networks, wherein the method comprises: constructing an SDSN security threat model, including a simulated SDSN environment and malicious applications, malicious switches, and malicious hosts; determining various network topology changes of the SDSN environment; determining a penetration path according to the security threat model and the network topology changes; constructing multiple test cases according to the penetration path, wherein the simulated attack types include denial of service, information leakage, protocol abuse, man-in-the-middle attack, policy evasion, storage pollution, and message passing attack; and performing security detection and assessment of the SDSN environment using the test cases, thereby more comprehensively and systematically detecting and defending against complex and diverse security threats existing in the software-defined satellite network.

Description

Technical Field

[0001] The present invention belongs to the field of Software Defined Satellite Network (SDSN), and in particular relates to a security detection and assessment method and device for a software defined satellite network. Background Art

[0002] With the rapid growth of global communications demand and the deployment of large-scale low-Earth orbit (LEO) satellite constellations, satellite-ground converged networks have become a core development direction for future network architectures. Following the research conclusions of the standards organization 3GPP, future 6G networks may deploy some, or even all, core network functions on satellites. Traditional satellite networks, lacking flexibility and efficient management capabilities, struggle to cope with increasingly complex network environments and diverse service demands. Satellite networks inherently support multiple types of command operations, primarily categorized as control and data transmission modes. This aligns with the separation of control and data planes in SDN (Software Defined Networking), promising the migration of relevant SDN technologies from terrestrial networks to satellite networks, providing them with powerful flexibility and dynamic configuration capabilities.

[0003] However, in terrestrial networks, the centralized nature of SDN control planes has exposed potentially serious vulnerabilities. Once an attacker successfully compromises or compromises an SDN controller, they could seize control of the entire network, leading to a range of security issues, from sensitive data leaks to complete network service disruption. Attackers could even maliciously modify flow tables to redirect or interrupt critical network traffic, posing even broader security risks. Furthermore, while northbound and southbound interfaces in SDN architectures can improve network management and control efficiency, they can also pose security risks if improperly designed. The high configurability of SDN networks, while providing convenience, also increases security vulnerabilities caused by misconfiguration. Furthermore, SDN's layered architecture (application, control, and data layers) introduces new attack surfaces, allowing attackers to exploit weaknesses in inter-layer interfaces and protocols to launch cross-layer attacks. While these security challenges are widely recognized, current research on how to effectively detect and mitigate these threats remains significantly limited. These shortcomings are particularly acute in software-defined satellite networks.

[0004] Software-defined satellite networks (SDSNs) are an emerging satellite communications network architecture that leverages software-defined networking and network function virtualization (NFV) technologies to achieve more efficient, flexible, and intelligent satellite communications and network management. SDSN not only inherits the security challenges of SDN in terrestrial networks, but also exacerbates the complexity of SDN issues due to its unique network environment.

[0005] First, the high latency and limited bandwidth of satellite networks make management information and instructions from SDN controllers more susceptible to delays and packet loss. Traditional detection frameworks struggle to maintain effectiveness in this environment, increasing the blindness of the detection process. Second, the multi-layered network architecture of SDSN, including low-orbit, medium-orbit, and geostationary satellites, and the diverse node types, further complicate the manifestations and paths of abnormal behavior, making it difficult for existing detection frameworks to fully capture and identify these abnormal behaviors. Finally, the dynamic topology of satellite networks causes existing detection frameworks to lag in responding to actual attack paths and patterns.

[0006] Therefore, in the SDSN environment, in order to effectively detect and defend against these complex and diverse security threats, a more systematic and targeted security testing method is urgently needed. Summary of the Invention

[0007] In order to solve the above problems existing in the prior art, the present invention provides a security detection and assessment method and device for software-defined satellite networks.

[0008] The technical problem to be solved by the present invention is achieved through the following technical solutions:

[0009] A security detection and assessment method for software-defined satellite networks, comprising:

[0010] Constructing an SDSN security threat model; the SDSN security threat model includes a simulated SDSN environment and malicious applications, malicious switches, and malicious hosts inserted in the SDSN environment;

[0011] Determine various network topology changes that may occur in the SDSN environment;

[0012] Determine a penetration path based on the SDSN security threat model and the various network topology changes; the penetration path includes a penetration path from the application to the SDN controller, from the application to the switch, from the switch to the SDN controller, from the host to the SDN controller, and from the host to the switch;

[0013] Constructing multiple test cases for simulating attacks based on the penetration path; the attack types simulated by the multiple test cases include denial of service, information leakage, protocol abuse, man-in-the-middle attack, policy evasion, storage pollution and messaging attack;

[0014] The multiple test cases are used to perform security detection and evaluation on the SDSN environment.

[0015] Optionally, the message delivery attack includes: message discard, message replay, message delay and message tampering.

[0016] Optionally, after performing security detection and assessment on the SDSN environment using the multiple test cases, the method further includes:

[0017] Collect feedback information; the feedback information includes: test environment information, network connectivity test results, network performance test results and system anomalies;

[0018] Adjusting the test strategy based on the feedback information; the test strategy is used to guide the generation of test cases;

[0019] Continue security testing and assessment according to the adjusted testing strategy.

[0020] Optionally, the test strategy adjustment includes: adjusting the priority of the test strategy, and / or generating a new test strategy.

[0021] Optionally, the system abnormality includes: OpenFlow error message, flow table abnormality and resource exhaustion.

[0022] Optionally, a test case for simulating the message passing attack is formulated in the following manner:

[0023] Build corresponding message templates according to OpenFlow message types;

[0024] For each message template, a set of test cases for simulating the message transmission attack is obtained by filling normal values, boundary values ​​and abnormal values ​​into the message fields of the message template.

[0025] The present invention also provides a security detection and assessment device for a software-defined satellite network, comprising:

[0026] A first building module is used to build an SDSN security threat model; the SDSN security threat model includes a simulated SDSN environment and malicious applications, malicious switches, and malicious hosts inserted in the SDSN environment;

[0027] A first determining module is used to determine various network topology changes that may occur in the SDSN environment;

[0028] A second determination module is configured to determine a penetration path based on the SDSN security threat model and the various network topology changes; the penetration path includes a penetration path from the application to the SDN controller, from the application to the switch, from the switch to the SDN controller, from the host to the SDN controller, and from the host to the switch;

[0029] A second building module is used to build multiple test cases for simulating attacks based on the penetration path; the attack types simulated by the multiple test cases include denial of service, information leakage, protocol abuse, man-in-the-middle attack, policy evasion, storage pollution and messaging attack;

[0030] The detection and evaluation module is used to perform security detection and evaluation on the SDSN environment using the multiple test cases.

[0031] Optionally, the message delivery attack includes: message discard, message replay, message delay and message tampering.

[0032] Optionally, the device further comprises: a feedback module and an adjustment module;

[0033] The feedback module is used to collect feedback information after the detection and evaluation module is triggered; the feedback information includes: test environment information, network connectivity test results, network performance test results and system anomalies;

[0034] The adjustment module is used to adjust the test strategy according to the feedback information; the test strategy is used to guide the generation of test cases;

[0035] The detection and evaluation module is further used to continue security detection and evaluation according to the adjusted test strategy.

[0036] Optionally, the test strategy adjustment includes: adjusting the priority of the test strategy, and / or generating a new test strategy.

[0037] The security detection and assessment method for software-defined satellite networks (SDSNs) proposed in this paper uses three dimensions: attacker behavior (attack type), dynamic topology changes, and message transmission. This method collaboratively formulates a testing strategy, simulating diverse attack scenarios in real satellite networks. Furthermore, it constrains penetration paths during testing, guiding the generation of test strategies and test cases and preventing state explosion. This method effectively detects and protects against complex and diverse security threats in SDSN environments, providing a more systematic and targeted approach. This enables SDSNs to more effectively address the frequent changes in network topology and the complex cross-domain collaboration requirements within satellite networks, promoting satellite-to-ground network integration.

[0038] The present invention will be further described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 This is a flow chart of a security detection and assessment method for a software-defined satellite network provided by an embodiment of the present invention;

[0040] Figure 2 FIG shows the SDSN security threat model of an embodiment of the present invention;

[0041] Figure 3 The basic content of the test strategy of the embodiment of the present invention is shown in FIG;

[0042] Figure 4 FIG. 4 exemplarily shows some types of OpenFlow messages;

[0043] Figure 5 The program code of a test strategy example is shown in FIG.

[0044] Figure 6 This is the technical concept flow of the security detection and assessment method for software-defined satellite networks provided by an embodiment of the present invention;

[0045] Figure 7 The program code of the ARP attack test strategy is shown as an example;

[0046] Figure 8 The program code of the DDoS (Distributed Denial of Service) attack test strategy is shown in FIG. DETAILED DESCRIPTION

[0047] During the implementation of this invention, the inventors discovered that existing security detection frameworks primarily focus on specific attack surfaces and attack paths, lacking comprehensiveness and systematicity. First, many security detection frameworks, such as ProxyFuzz and FlowFuzz, employ simple packet randomization strategies in fuzz testing of southbound interface protocols, which can only detect basic vulnerabilities in packet parsers and lack the ability to detect deeper logical vulnerabilities, making it difficult to detect deeper logical vulnerabilities and complex attack paths. This approach is limited by the lack of a feedback mechanism for policy variations, resulting in a blind testing process and difficulty adapting to the dynamic nature of satellite networks. Second, other security detection frameworks, such as AudiSDN and BEADS (see "Beads: Automated Attack Discovery in OpenFlow-based SDN Systems"), while attempting to detect abnormal behavior caused by malicious hosts and switches, fail to fully consider the diverse anomalies that actually exist in networks, such as cross-layer attacks caused by improper interactions between the application layer and the controller. This lack of comprehensive detection of abnormal behavior makes the frameworks difficult to adapt to the complex threat landscape in satellite networks. Finally, although the Delta security detection framework tests the SDN system as a whole, its fuzz testing strategy relies too much on control flow sequence randomization and numerical randomization, and fails to fully consider the changes in message format and network topology, which is particularly insufficient in SDSN with dynamically changing topology.

[0048] SDSN has highly centralized control logic and dynamically programmable network configuration capabilities, making traditional security defense mechanisms difficult to directly apply. To enable more comprehensive and systematic detection and defense against the complex and diverse security threats present in software-defined satellite networks, embodiments of the present invention provide a security detection and assessment method for software-defined satellite networks. This method can provide a comprehensive security analysis framework for SDSN, improve the security and reliability of SDSN deployment, and provide an effective solution to the multi-layered security challenges in SDSN. The present invention is further described in detail below with reference to specific embodiments, but the embodiments of the present invention are not limited thereto.

[0049] like Figure 1 As shown, the security detection and assessment method for a software-defined satellite network provided by an embodiment of the present invention includes the following steps:

[0050] S10. Construct an SDSN security threat model; the SDSN security threat model includes a simulated SDSN environment and malicious applications, malicious switches, and malicious hosts installed in the SDSN environment.

[0051] Specifically, such as Figure 2 As shown in Figure 3, the SDSN security threat model explicitly places the SDN controller at the center and embeds several key components in the SDSN environment: malicious applications at the application layer, malicious switches at the infrastructure layer, and malicious hosts that initiate attacks.

[0052] Different from the traditional network threat model, the SDSN security threat model in the embodiment of the present invention focuses on the security issues brought about by the centralized control characteristics and open programming interfaces of the SDSN environment, emphasizing that each key component may become a starting point for attackers to exploit.

[0053] Malicious applications can interact with SDN controllers and send deceptive or malicious commands to modify network traffic routing or create false network policies, thereby influencing the SDN controller's decision-making process or deceiving other network devices. Malicious switches controlled by attackers can be used to redirect, block, modify, or monitor network traffic, thereby impacting the SDN controller. Malicious hosts can be used to send malicious traffic, affecting the network topology or causing resource exhaustion on switches and controllers. It is understood that the edge service master station in SDSN can not only run specific business logic and control algorithms, but also participate in network communication and send and receive data. If an attacker controls it to send malicious traffic, the edge service master station can be considered a malicious host.

[0054] S20. Determine various network topology changes that may occur in the SDSN environment.

[0055] It is understandable that the network topology of SDSN changes dynamically, and dynamically changing network topologies may introduce new attack surfaces, such as internal attacks launched through newly added malicious nodes or continued access to the network through deleted nodes. Therefore, by dynamically planning the initial settings of the SDSN network topology and the changes that may occur during actual operation, we simulate the various network topology changes that may occur in the SDSN environment caused by the dynamic adjustment of network slice management and service requirements in practice, so as to discover as many network topologies that may be exploited by attackers as possible, thereby using a flexible test environment to simulate the complexity of the SDSN environment and conduct a comprehensive security assessment.

[0056] S30. Determine the penetration path based on the SDSN security threat model and various network topology changes; the penetration path includes the penetration path from the application to the SDN controller, from the application to the switch, from the switch to the SDN controller, from the host to the SDN controller, and from the host to the switch.

[0057] Specifically, the inventor first analyzed the potential attack source from the attacker's behavior level. Figure 2 The SDSN security threat model described above identifies diverse attack behaviors encompassing host actions, switch actions, and applications, as shown in Table 1. Hosts simulate malicious behaviors, such as sending malicious traffic and ARP (Address Resolution Protocol) spoofing, through random payload injection, specific payload injection, and packet injection. Switches simulate attacks, such as illegal forwarding and flow table tampering, by injecting packets into the SDN controller, adjacent switches, and hosts. Applications simulate attacker behavior by writing and running malicious programs to generate and process specific events. These actions collectively constitute the most basic attack behaviors. By simulating these behaviors, the response and defense capabilities of SDSN-based networks against various attacks can be tested.

[0058] Table 1

[0059]

[0060] Based on Table 1 and the various network topology changes that may occur in the SDSN environment, we can identify the attacker's penetration paths in the SDSN and analyze the possible attack types that the attacker may take under each penetration path. The results are shown in Table 2:

[0061] Table 2

[0062]

[0063] In Table 1, FLOW_MOD is a message type in the OpenFlow protocol used to add, modify, or delete flow table entries in a switch. By sending FLOW_MOD messages, the SDN controller can dynamically control data flow. FLOW_MOD flooding occurs when an attacker sends a large number of FLOW_MOD messages to a switch, flooding the switch's flow table. This flooding causes the flow table to overflow or overwrite valid flow rules, preventing legitimate data flows from being processed properly, severely degrading network performance, or even causing network paralysis. A flow table is a data structure used in network devices to store and manage packet forwarding rules. It determines the forwarding path and processing method for packets based on specific packet characteristics (such as source address, destination address, and protocol type). The flow table is a core component of SDSN, enabling flexible network control and efficient management. The PACKET_IN message is an OpenFlow message type that indicates that a switch cannot process a received packet based on its own flow table. The READ_STATE message is used by the controller to collect various switch information, including configuration and statistics. Malicious payload injection refers to forged or maliciously designed OpenFlow messages injected through malicious switches, including malformed OpenFlow packets, injection of abnormal protocol behavior, and message flows with excessive payload.

[0064] S40. Construct multiple test cases for simulating attacks based on the penetration path; the attack types simulated by the multiple test cases include denial of service, information leakage, protocol abuse, man-in-the-middle attack, policy evasion, storage pollution and messaging attack.

[0065] Specifically, denial of service refers to a situation where a controller or switch cannot be used or its performance is significantly degraded due to a malicious attack. Information leakage refers to an attacker obtaining sensitive data by monitoring and recording traffic, identifying and investigating the target network through network probing, and preparing for subsequent attacks. Protocol abuse refers to an attacker maliciously using the protocol to disrupt the communication between the controller and other applications, or injecting harmful payloads into the control packet. A man-in-the-middle attack refers to an attacker using malicious applications, malicious switches, or malicious hosts to place themselves between two network nodes through deception and other means, and to view, modify, or segment the communication between nodes without being noticed. Policy evasion refers to a malicious application or malicious host violating security policies, including the policies and configurations of the control plane and the forwarding behavior of the data plane. Storage pollution refers to an attacker injecting malicious data to pollute network storage, thereby disrupting the decision-making process of the controller. For the above attack types, Table 3 shows the specific attack methods and attack paths:

[0066] Table 3

[0067]

[0068] It can be understood that according to the attack methods and attack paths shown in Table 3, a test strategy is formed through program coding, and the test strategy is used to guide the generation of test cases. Specifically, by executing the program coding of the test strategy, an openflow message packet for simulating the attack is formed, thereby obtaining a series of test cases in the form of openflow message packets, thereby simulating denial of service, information leakage, protocol abuse, man-in-the-middle attack, policy evasion, and storage pollution under various penetration paths, and thereby testing and evaluating the security of SDSN.

[0069] Figure 3 The basic content of the test strategy of the embodiment of the present invention is shown in FIG. Figure 5 The following example illustrates the program code for a test strategy example, in which a malicious switch performs actions or returns information different from those requested by the controller. "topo" specifies the path to the network topology configuration file. "switch" defines the switch's behavior. When switch 1 receives a Barrier_Reply message from controller 0, it has a 50% probability of discarding the message. A Barrier_Reply is a message type in the OpenFlow protocol that responds to a Barrier_Request message. When a controller sends a Barrier_Request message to a switch, the switch must process all messages and instructions received before the request and then send a Barrier_Reply message to the controller, notifying it that it has processed all previous messages and instructions. This mechanism ensures the order of messages and instructions between the controller and the switch. For example, a controller can first send a flow table modification instruction and then a Barrier_Request message. When the controller receives the Barrier_Reply message, it knows that the flow table modification instruction has been processed. "host" and "app" define the behavior of the host and application, respectively. In this test case, the host and application do not execute commands.

[0070] also, Figure 7 The program code of the ARP attack test strategy is shown as an example; Figure 8 The program code of the DDoS (Distributed Denial of Service) attack test strategy is shown in FIG.

[0071] The attacks shown in Table 3 all simulate attacks that exist in the internal operation of SDSN itself. Different from the attacks shown in Table 3, the message passing attack simulates attacks outside the internal operation of SDSN. It takes into account the message passing mechanism in network communication and simulates attack behaviors such as message discard, message replay, message delay, and message tampering through message passing strategies to evaluate the response capability of SDSN in the face of complex attack scenarios.

[0072] A message-passing attack is an attack that compromises system security by transmitting malicious or tampered data. This attack targets network communication mechanisms, triggering system security vulnerabilities by sending or tampering with messages, thereby achieving the attacker's malicious intent. For example, in an SDSN environment, due to the open nature of the links, every data packet in the network may be interfered with or lost by physical signals. Even if the packet is legitimate traffic, the loss can still cause errors or anomalies.

[0073] In this embodiment of the present invention, the purpose of developing test cases for message passing attacks is to simulate complex real-world network attack scenarios by manipulating OpenFlow message passing between network devices. Table 4 shows the specific attack scenarios and their test objectives for four different types of message passing attacks.

[0074] Table 4

[0075]

[0076] It can be understood that according to the attack methods shown in Table 4, a test strategy is formed through program coding, and a series of test cases are obtained by executing the test strategy, so that message delivery attacks such as message discard, message replay, message delay and message tampering are executed with specified probability or random probability, and the security of SDSN is tested and evaluated.

[0077] Specifically, test cases for simulating messaging attacks can be formulated as follows:

[0078] (1) Construct corresponding message templates according to OpenFlow message types;

[0079] (2) For each message template, a set of test cases for simulating message delivery attacks is obtained by filling the message fields of the message template with normal values, boundary values, and abnormal values.

[0080] Figure 4The following example shows some types of OpenFlow messages. A message template is defined for each type of OpenFlow message. Based on the constructed message template, test cases are filled or mutated according to the specific semantics of the message fields. The following three filling methods are used for the value of each field:

[0081] I. Normal Value: The value expected to be received under normal operation. By testing each field with its normal value, verify the system's behavior under normal conditions and ensure that basic functionality is not compromised.

[0082] II. Boundary Values: Boundary values ​​are the edges of an input range, such as the maximum and minimum values ​​of a numeric field. Boundary value testing is used to identify errors that may occur when handling boundary conditions, such as overflow, underflow, or incorrect judgment of boundary conditions.

[0083] III. Outliers: Values ​​that should not normally appear in a particular field. These include data type mismatches, such as entering a string in an integer field, or values ​​outside the field's normal operating range. By testing fields with outliers, you can assess the system's ability to handle unexpected or erroneous input, thereby uncovering potential exception handling or error handling vulnerabilities.

[0084] It should be noted that random mutations of complete messages can also simulate message-passing attacks, but this results in wasted resources and low testing efficiency. Therefore, to improve testing efficiency and construct effective test cases, the present invention analyzes the OpenFlow message type structure and the specific requirements of each field in detail. For each message type, a clear message template is defined based on its structure.

[0085] In summary, step S40 comprehensively considers the behavioral level of potential attack sources, the network topology change level, and the message transmission change level to develop a series of test cases, which can comprehensively simulate and implement malicious interactions between components and maximize the discovery and evaluation of potential security vulnerabilities in the system.

[0086] S50. Use the above multiple test cases to perform security testing and evaluation on the SDSN environment.

[0087] Specifically, each test case is executed to conduct security detection and evaluation of the SDSN environment based on the execution effect of the test case. For example, confirm whether the test is successful or not. If it fails, what is the reason for the failure, such as abnormal network status, error message and device crash; confirm network performance indicators during the test, such as throughput, delay, packet loss rate, etc., and confirm whether the network connectivity is normal. In this way, it is possible to determine whether there are any abnormalities in the SDSN environment and to identify whether the abnormalities are caused by insufficient security of SDSN itself. If it can be determined that the abnormalities are caused by insufficient security of SDSN itself, it means that the written test case has effectively detected the security deficiencies of SDSN. Therefore, by executing various test cases, the security detection and evaluation of the SDSN environment is achieved.

[0088] The security detection and assessment method for software-defined satellite networks (SDSNs) provided by this embodiment uses three dimensions: attacker behavior (attack type), dynamic topology changes, and message transmission. This method collaboratively formulates a testing strategy, simulating diverse attack scenarios in real satellite networks. Furthermore, penetration paths are constrained during the testing process, guiding the generation of test strategies and test cases and preventing state explosion. This method effectively detects and protects against complex and diverse security threats in SDSN environments, providing a more systematic and targeted approach. This enables SDSNs to more effectively address the frequent changes in network topology and the complex cross-domain collaboration requirements within satellite networks, promoting satellite-ground network integration.

[0089] In addition, after performing security detection and evaluation on the SDSN environment using multiple test cases, the method of the embodiment of the present invention may further include:

[0090] (1) Collect feedback information; the feedback information includes: test environment information, network connectivity test results, network performance test results and system anomalies;

[0091] The network connectivity test results can indicate whether there are network reachability issues. Specifically, network reachability refers to the ability of data packets to be transmitted from the source node to the destination node. If a network reachability issue occurs during the test, such as a path error, a black hole, or incorrect application of security policies, it indicates that the test policy for certain penetration paths has caused network segmentation or service unavailability. This abnormal indicator can be associated with paths including host-to-controller, host-to-switch, and switch-to-controller.

[0092] System anomalies include: OpenFlow error messages, flow table anomalies, and resource exhaustion. These three indicators of system anomalies are closely related to the penetration path and can effectively identify potential risks in network resource configuration, topology changes, and message transmission.

[0093] Regarding OpenFlow error messages: When an OpenFlow switch or controller fails to parse an OpenFlow message or when the message indicates an invalid or unsupported option, an error message is sent. These error messages directly reflect errors in the controller or switch processing malicious messages from various sources. By monitoring these error messages, you can quickly identify abnormal control messages sent by malicious applications or hosts and their impact on the controller. This abnormality indicator can be associated with paths including application-to-controller, switch-to-controller, and host-to-controller. Therefore, when executing test cases related to these paths, pay attention to OpenFlow error messages.

[0094] Regarding flow table anomalies: The flow table defines how the switch processes packets. If testing the policy results in unusual changes to the flow table, such as the addition of invalid rules, incorrect priorities, or rule tampering, this may indicate that the policy is affecting the normal functioning of the network.

[0095] Regarding resource exhaustion: In an SDSN environment, the performance of the controller is critical to the performance of the entire network. If the test strategy leads to excessive use of controller or switch resources, such as an abnormal increase in CPU or memory utilization, it may indicate a denial of service attack or other forms of malicious behavior. Therefore, before executing the test case, it is necessary to perform several rounds of baseline tests on memory utilization. After the test is completed, the average performance index of the baseline test is calculated and saved as the baseline. In this way, during the subsequent execution of the test case, by monitoring resource usage and comparing it with the baseline, it can help identify test cases that cause resource exhaustion. In actual testing, the abnormal indicator of resource exhaustion can be associated with paths including application to controller, switch to controller, and host to controller. Therefore, when executing test cases related to these paths, you can pay attention to the abnormal indicator of resource exhaustion.

[0096] (2) Adjust the test strategy based on feedback information;

[0097] The test strategy adjustment includes: adjusting the priority of the test strategy, and / or generating a new test strategy.

[0098] For example, if a specific type of OpenFlow message or specific network behavior causes a test failure or abnormal information (not caused by improper test case writing), the priority of the relevant test strategy in the test strategy queue is increased. Prioritization ensures that the testing process focuses on the test strategies with higher risks.

[0099] For example, if a test strategy causes an unknown behavior (not due to improper test case writing), a new test strategy can be generated by adjusting test parameters and conditions to further explore the cause of the unknown behavior. If the feedback information indicates that the test conditions did not trigger any anomalies, it means that the attack simulated by the test strategy is ineffective against SDSN and is not sufficient to test the security vulnerabilities in SDSN. In this case, similar cases can be adjusted or deleted from the test strategy queue to make the test more focused and efficient.

[0100] (3) Continue security testing and evaluation based on the adjusted test strategy.

[0101] Specifically, by executing the program code of the adjusted test strategy, new test cases are obtained, so that the security detection and evaluation of the SDSN environment can be continued based on the new test cases.

[0102] This feedback-driven testing strategy adjustment ensures continuous optimization of the testing process, more effectively identifying potential security issues. This allows for more precise identification of effective testing strategies that cause network anomalies, reduces testing resources and time, and gradually increases test coverage. Existing SDN security testing frameworks, however, lack feedback mechanisms, resulting in blind testing and difficulty in quickly and comprehensively assessing network security.

[0103] In summary, the security detection and assessment method for software-defined satellite networks provided by the embodiments of the present invention focuses on the characteristics of the SDSN environment and comprehensively considers the highly dynamic nature of the network, complex interactive relationships, and potential security threats. Figure 6First, based on the SDSN security threat model and penetration paths, the present embodiment develops diverse attack simulation strategies targeting applications, controllers, switches, and hosts. This strategy fully accounts for the high mobility and dynamic topology changes of SDSN devices, ensuring that the test environment closely resembles real-world network conditions. Secondly, the present embodiment analyzes OpenFlow protocol message types and field semantics in detail, establishes structured message templates, and combines the normal, boundary, and abnormal values ​​of fields to generate efficient and targeted test cases. By systematically considering field combinations and dependencies, the comprehensiveness and effectiveness of the test strategy are ensured. Furthermore, a set of system anomaly detection metrics is established, including OpenFlow error messages, network status changes, network reachability, and resource usage. Performance baseline testing establishes baseline metrics, monitors resource usage, and identifies potential attack behaviors. Finally, the present embodiment dynamically adjusts the test strategy based on a feedback-driven approach, prioritizing it to focus on high-risk strategies and generating new test strategies to explore unknown behaviors. This method analyzes and classifies attacks across layers from the perspective of penetration paths, making security testing not only more comprehensive and systematic, but also more targeted and practical. By combining the threat model, dynamic network topology changes, and message delivery strategies, it is possible to simulate diverse attack scenarios. Based on penetration path constraints, test strategy generation is guided to avoid state explosion. Ultimately, test strategy adjustment is achieved through feedback, improving test effectiveness and accuracy. This approach ensures comprehensiveness and practicality of testing, providing an effective security solution for SDSN.

[0104] Inspired by the method of the embodiment of the present invention, other application scenarios combined with SDN can also refer to the method of the embodiment of the present invention for security detection and evaluation.

[0105] Based on the same inventive concept, an embodiment of the present invention further provides a security detection and assessment device for a software-defined satellite network, comprising:

[0106] A first building module is used to build an SDSN security threat model; the SDSN security threat model includes a simulated SDSN environment and malicious applications, malicious switches, and malicious hosts inserted in the SDSN environment;

[0107] A first determining module is used to determine various network topology changes that may occur in the SDSN environment;

[0108] A second determination module is configured to determine a penetration path based on the SDSN security threat model and the various network topology changes; the penetration path includes a penetration path from the application to the SDN controller, from the application to the switch, from the switch to the SDN controller, from the host to the SDN controller, and from the host to the switch;

[0109] A second building module is used to build multiple test cases for simulating attacks based on the penetration path; the attack types simulated by the multiple test cases include denial of service, information leakage, protocol abuse, man-in-the-middle attack, policy evasion, storage pollution and messaging attack;

[0110] The detection and evaluation module is used to perform security detection and evaluation on the SDSN environment using the multiple test cases.

[0111] Optionally, the message delivery attack includes: message discard, message replay, message delay and message tampering.

[0112] Optionally, the device further comprises: a feedback module and an adjustment module;

[0113] The feedback module is used to collect feedback information after the detection and evaluation module is triggered; the feedback information includes: test environment information, network connectivity test results, network performance test results and system anomalies;

[0114] The adjustment module is used to adjust the test strategy according to the feedback information;

[0115] The detection and evaluation module is further used to continue security detection and evaluation according to the adjusted test strategy.

[0116] Optionally, the test strategy adjustment includes: adjusting the priority of the test cases, and / or generating new test cases.

[0117] Optionally, the test strategy adjustment includes: adjusting the priority of the test cases, and / or generating new test cases.

[0118] Optionally, the system abnormality includes: OpenFlow error message, flow table abnormality and resource exhaustion.

[0119] Optionally, a test case for simulating the message passing attack is formulated in the following manner:

[0120] Build corresponding message templates according to OpenFlow message types;

[0121] For each message template, a set of test cases for simulating the message transmission attack is obtained by filling normal values, boundary values ​​and abnormal values ​​into the message fields of the message template.

[0122] The apparatus provided by the present invention may be a software product, and the various modules included in the apparatus may be program modules within the software product. The testing software may provide a debugging interface through which testers can formulate and adjust the various test cases and indicators indicating system anomalies described above. The testing software may also provide an output module to output the test case execution results to the tester.

[0123] It should be noted that, for the device / electronic device / storage medium / computer program product embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and relevant details can be found in the partial description of the method embodiments.

[0124] It should be noted that the terms "first," "second," and the like are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure.

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

[0126] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings and the disclosed content. In the description of the present invention, the word "comprising" does not exclude other components or steps, "one" or "a" does not exclude multiple situations, and "multiple" means two or more, unless otherwise clearly and specifically limited. In addition, certain measures are recorded in different embodiments, but this does not mean that these measures cannot be combined to produce good results.

[0127] The above is a further detailed description of the present invention in conjunction with specific preferred embodiments, and the specific implementation of the present invention should not be considered to be limited to these descriptions. For those skilled in the art of the present invention, without departing from the concept of the present invention, several simple deductions or substitutions can be made, which should be considered to fall within the scope of protection of the present invention.

Claims

1. A security detection and assessment method for software-defined satellite networks, characterized in that: include: Constructing an SDSN security threat model; the SDSN security threat model includes a simulated SDSN environment and malicious applications, malicious switches, and malicious hosts inserted in the SDSN environment; Determine various network topology changes that may occur in the SDSN environment; Determine a penetration path based on the SDSN security threat model and the various network topology changes; the penetration path includes a penetration path from the application to the SDN controller, from the application to the switch, from the switch to the SDN controller, from the host to the SDN controller, and from the host to the switch; Constructing multiple test cases for simulating attacks based on the penetration path; the attack types simulated by the multiple test cases include denial of service, information leakage, protocol abuse, man-in-the-middle attack, policy evasion, storage pollution and messaging attack; The multiple test cases are used to perform security detection and evaluation on the SDSN environment.

2. The security detection and assessment method for software-defined satellite networks according to claim 1, characterized in that: The message delivery attacks include: message discard, message replay, message delay and message tampering.

3. The security detection and assessment method for software-defined satellite networks according to claim 1, characterized in that: After performing security detection and evaluation on the SDSN environment using the plurality of test cases, the method further includes: Collect feedback information; the feedback information includes: test environment information, network connectivity test results, network performance test results and system anomalies; Adjusting the test strategy based on the feedback information; the test strategy is used to guide the generation of test cases; Continue security testing and assessment according to the adjusted testing strategy.

4. The security detection and assessment method for software-defined satellite networks according to claim 3, characterized in that: The test strategy adjustment includes: adjusting the priority of the test strategy, and / or generating a new test strategy.

5. The security detection and assessment method for software-defined satellite networks according to claim 3, characterized in that: The system anomalies include: OpenFlow error messages, flow table anomalies, and resource exhaustion.

6. The security detection and assessment method for software-defined satellite networks according to claim 3, characterized in that: The test case used to simulate the messaging attack was developed in the following way: Build corresponding message templates according to OpenFlow message types; For each message template, a set of test cases for simulating the message transmission attack is obtained by filling normal values, boundary values ​​and abnormal values ​​into the message fields of the message template.

7. A security detection and assessment device for software-defined satellite networks, characterized in that: include: A first building module is used to build an SDSN security threat model; the SDSN security threat model includes a simulated SDSN environment and malicious applications, malicious switches, and malicious hosts inserted in the SDSN environment; A first determining module is used to determine various network topology changes that may occur in the SDSN environment; A second determination module is configured to determine a penetration path based on the SDSN security threat model and the various network topology changes; the penetration path includes a penetration path from the application to the SDN controller, from the application to the switch, from the switch to the SDN controller, from the host to the SDN controller, and from the host to the switch; A second building module is used to build multiple test cases for simulating attacks based on the penetration path; the attack types simulated by the multiple test cases include denial of service, information leakage, protocol abuse, man-in-the-middle attack, policy evasion, storage pollution and messaging attack; The detection and evaluation module is used to perform security detection and evaluation on the SDSN environment using the multiple test cases.

8. The security detection and assessment device for software-defined satellite networks according to claim 7, characterized in that: The message delivery attacks include: message discard, message replay, message delay and message tampering.

9. The security detection and assessment device for software-defined satellite networks according to claim 7, characterized in that: The device further comprises: a feedback module and an adjustment module; The feedback module is used to collect feedback information after the detection and evaluation module is triggered; the feedback information includes: test environment information, network connectivity test results, network performance test results and system anomalies; The adjustment module is used to adjust the test strategy according to the feedback information; the test strategy is used to guide the generation of test cases; The detection and evaluation module is further used to continue security detection and evaluation according to the adjusted test strategy.

10. The security detection and assessment device for software-defined satellite networks according to claim 9, characterized in that: The test strategy adjustment includes: adjusting the priority of the test strategy, and / or generating a new test strategy.

Images