Verification method and device of network security equipment, and electronic equipment

Abstract

The invention provides a verification method of network security equipment, and relates to the technical field of computer software, in particular to the technical field of security verification of network security, traffic detection and network traffic analysis. According to the specific implementation scheme, an attack request script and an attack response script are generated according to alarm data of network security equipment, and the attack response script is sent to an attack response simulator; an attack request is constructed based on the attack request script, the attack request is sent to an attack response simulator, and the attack response simulator is configured to receive the attack request, perform matching with the received attack response script according to the attack request, construct an attack response according to a matching result and return the attack response; obtaining attack simulation time sequence data according to the received attack request and the received attack response; and verifying the validity of the network security equipment based on the alarm data and the attack simulation time sequence data.

Description

Technical Field

[0001] This disclosure relates to the field of computer software technology, and in particular to the field of security verification in network security, traffic detection, and network traffic analysis. Background Technology

[0002] In the field of cybersecurity, there is an urgent need to verify the security effectiveness of cybersecurity devices, such as Network Traffic Analysis (NTA) devices. Traditional Breach and Attack Simulation (BAS) systems rely on static, generic attack scripts, which are difficult to adapt to real dynamic threats and have detection blind spots. Verification of NTA devices simply judges the monitoring of attack requests, lacks an assessment of the effectiveness of traffic detection, and cannot verify the security effectiveness of NTA devices. Summary of the Invention

[0003] This disclosure provides a page generation method, apparatus, and electronic device for solving at least one of the above-mentioned technical problems.

[0004] According to one aspect of this disclosure, a method for verifying a network security device is provided, wherein the method includes:

[0005] Based on the alarm data from network security devices, attack request scripts and attack response scripts are generated, and the attack response scripts are sent to the attack response simulator.

[0006] An attack request is constructed based on the attack request script and sent to the attack response simulator. The attack response simulator is configured to receive the attack request, match the attack request with the received attack response script, construct an attack response based on the matching result, and return it.

[0007] Based on the received attack request and attack response, attack simulation time series data is obtained;

[0008] The effectiveness of the network security device is verified based on the alarm data and the attack simulation time series data.

[0009] According to another aspect of this disclosure, a method for verifying a network security device is provided, wherein the method includes:

[0010] Receive an attack request sent by an attack response requester, match the attack request with the received attack response script, construct an attack response based on the matching result, and send it to the attack response requester.

[0011] The attack request is generated using the method described above; the attack response requester is configured to receive the attack request and verify the validity of the network security device according to the method described above.

[0012] According to another aspect of this disclosure, a verification apparatus for a network security device is provided, wherein the apparatus includes:

[0013] The script generation module is used to generate attack request scripts and attack response scripts based on alarm data from network security devices, and send the attack response scripts to the attack response simulator.

[0014] A request generation module is used to construct an attack request based on the attack request script and send the attack request to the attack response simulator, wherein the attack response simulator is configured to receive the attack request, match the attack request with the received attack response script, construct an attack response based on the matching result, and return it.

[0015] The timing construction module is used to obtain attack simulation timing data based on the received attack request and the attack response;

[0016] The security verification module is used to verify the effectiveness of the network security device based on the alarm data and the attack simulation time series data.

[0017] According to another aspect of this disclosure, a verification apparatus for a network security device is provided, wherein the apparatus includes:

[0018] The attack response module is used to receive attack requests sent by the attack response requester, match the attack requests with the received attack response scripts, construct an attack response based on the matching results, and send it to the attack response requester.

[0019] The attack request is generated according to the method described above; the attack response requester is configured to receive the attack request and verify the validity of the network security device according to the method described above.

[0020] According to another aspect of this disclosure, an electronic device is provided, comprising:

[0021] At least one processor; and

[0022] A memory communicatively connected to the at least one processor; wherein,

[0023] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the above-described method.

[0024] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method described above.

[0025] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method described above.

[0026] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0027] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0028] Figure 1 This is an architecture diagram of the application of the method disclosed herein;

[0029] Figure 2 This is a flowchart illustrating a verification method for a network security device provided in the first embodiment of this disclosure;

[0030] Figure 3 This is a flowchart of S101;

[0031] Figure 4 This is a flowchart of S102;

[0032] Figure 5 This is a flowchart illustrating a verification method for a network security device provided in the second embodiment of this disclosure;

[0033] Figure 6 This is a schematic diagram of the structure of a verification device for a network security device according to a third embodiment of the present disclosure;

[0034] Figure 7 This is a schematic diagram of the structure of a verification device for a network security device according to the fourth embodiment of this disclosure;

[0035] Figure 8 This is a block diagram of an electronic device used to implement the methods of the embodiments of this disclosure. Detailed Implementation

[0036] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0037] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0038] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0039] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0040] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0041] The verification method for network security devices according to this disclosure can be executed by electronic devices such as terminal devices or servers. Terminal devices can be in-vehicle devices, user equipment (UE), mobile devices, user terminals, terminals, cellular phones, cordless phones, personal digital assistants (PDAs), handheld devices, computing devices, in-vehicle devices, wearable devices, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the verification method for network security devices provided in this disclosure can be executed by a server.

[0042] See Figure 1 , Figure 1 This is an architecture diagram illustrating the application of the method disclosed herein. In fact, the attack request simulator is deployed on a network endpoint, which can be called the production network; the attack request responder is deployed on a network endpoint, which can be called the external network. The attack request simulator may include one or more attack request simulator bodies, a script generation module, and a probing verification module. The attack request responder may also include one or more attack request responders; this is not limited here.

[0043] In the first disclosed embodiment, participants Figure 2 , Figure 2 This diagram illustrates a flowchart of a verification method for a network security device according to a first embodiment of this disclosure. The method is applied to one side of an attack request simulator and includes:

[0044] S101. Generate an attack request script and an attack response script based on the alarm data from the network security device, and send the attack response script to the attack response simulator.

[0045] Network security devices refer to specialized equipment deployed at network communication nodes to analyze network traffic and detect threats, such as NTA devices. NTA devices collect network data packets in real time, analyze traffic characteristics such as protocol type, request path, and payload content, and identify malicious behavior by combining these with preset detection rules. Malicious behavior includes remote control commands, vulnerability exploitation, and data leakage. The devices generate alarm data to record key information about the attack event, including attack time, attack behavior characteristics, attack type, and involved network addresses, thereby ensuring network security.

[0046] An attack script is a set of instructions dynamically generated based on alarm data from network security devices, used to simulate real attack interactions and drive the attack simulation process.

[0047] The attack request script records the behavior of the attack initiator (i.e., the attack request simulator). It may include at least one of the following: request method, target address, header, and attack characteristics. Of course, it may also include other content, which is not limited here. The attack request script is used to guide the attack request simulator to construct attack requests that conform to the characteristics of real attacks.

[0048] Attack response script: Records the feedback from the attack target (i.e., the attack response simulator). It may include at least one of the following: attack request matching conditions, attack response content, and attack type. Of course, it may also include other content, which is not limited here. The attack response script is used to guide the attack response simulator to return response data consistent with the real attack scenario.

[0049] The attack request simulator first retrieves alert data generated by network security devices in response to detected malicious activity. This alert data can be up-to-date or retrieved according to a set time period. The alert data may contain characteristics of real attack events, such as malicious sample download addresses, attack payload fragments, and interaction protocols. Based on the protocol session characteristics in the alert data, attack request scripts and attack response scripts are dynamically generated. Once generated, the attack response script is sent to the attack response simulator, ensuring that both ends simulate the attack based on the script rules.

[0050] S102. Construct an attack request based on the attack request script and send the attack request to the attack response simulator. The attack response simulator is configured to receive the attack request, match the attack request with the received attack response script, construct the attack response based on the matching result, and return it.

[0051] The attack request simulator constructs attack requests that match attack characteristics based on the content of the attack request script, such as malicious requests simulating remote control tools or trigger packets for vulnerability exploitation, and sends the attack requests to the attack response simulator. Upon receiving the request, the attack response simulator matches it against a pre-synchronized attack response script. This matching process includes checking whether the attack request matches the input configuration items corresponding to the attack request matching conditions. If a match is successful (i.e., a hit), an attack response is constructed according to the attack response content in the attack response script and returned to the attack request simulator, thus replaying the request-response interaction in a real attack.

[0052] S103. Based on the received attack requests and attack responses, obtain the attack simulation timing data.

[0053] Attack simulation time-series data is a structured record of the interaction between attack requests and responses, used to quantitatively describe the execution of attack simulations. It may include at least one of the following: script name, attack request internet protocol address, target address of the attack response simulator, unique traffic identifier, attack request sending time, error code, and the number of attack requests sent per minute. Other content may also be included, without limitation. Attack simulation time-series data allows tracing the timeline of each attack simulation, the direction of attack traffic, and the execution status (i.e., the status corresponding to the error code), providing a basis for subsequent verification of the effectiveness of network security devices.

[0054] S104. Verify the effectiveness of network security devices based on alarm data and attack simulation time-series data.

[0055] The attack request simulator correlates and analyzes the generated attack simulation time-series data with the alarm data of network security devices. By comparing the two, it determines whether the network security devices have accurately captured and identified the simulated attack traffic, thereby achieving an assessment of the security effectiveness of the network security devices.

[0056] Specifically, S101 can be executed by the script generation module, S102 and S103 are executed by the attack request simulator body and interact with the attack request responder, and S104 can be executed by the dial-up verification module.

[0057] The method disclosed herein adaptively generates attack request scripts and attack response scripts based on network security device alarm data. The alarm data contains real network attack characteristics, and the scripts generated based on this data can accurately replicate the actual attack behavior logic in the current network environment, dynamically adapting to real-time threat scenarios. For example, the scripts generated by this disclosure will include request headers and attack characteristics of traffic from the real alarm data. Compared to related technologies that use static pre-set scripts, this method allows attack simulations to more closely resemble real network attack and defense situations. It provides a highly realistic and dynamically updated test benchmark for subsequent attack simulations and network security device effectiveness verification based on this script, and can adapt to various network environments. This effectively solves the problem that traditional static scripts cannot cope with changing attack forms, improving the accuracy and comprehensiveness of verifying the detection capabilities of network security devices. Furthermore, by comparing the attack simulation time-series data generated from the script with the real alarm data of the network security device, the effectiveness of the network security device in capturing attack traffic can be verified, enabling more effective detection of the network device's traffic effectiveness.

[0058] It should be noted that in some cases, the method provided in Implementation Example 1 is applied to an attack request simulator; the attack request simulator and the attack response simulator are deployed in different networks. In this method, the attack request simulator and the attack response simulator are deployed in different network environments, such as the attack request simulator being deployed on a production network and the attack response simulator being deployed on an external network. This cross-network deployment method can reproduce the network characteristics of attack sources and targets belonging to different networks in real network attacks. By simulating the cross-network interaction process of the production network initiating an attack request to the external network and the external network returning a response, the network security equipment's ability to detect cross-network boundary traffic can be effectively tested, including the coverage of traffic through complex network paths such as routing and firewall filtering, as well as the effectiveness of identifying cross-network attack characteristics. Compared with traditional attack simulation in a single network environment, where the requesting and responding ends of the attack action are deployed in the same network environment, cross-network deployment can expose network blind spots of the device in network boundary protection, cross-network segment traffic parsing, etc., ensuring that the verification results are more in line with the actual network attack and defense situation, thereby making the attack simulation and security verification results more accurate.

[0059] It should be noted that in some cases, the attack request simulator includes multiple distributed deployments; similarly, the attack response simulator also includes multiple distributed deployments. In other cases, both the attack request simulator and the attack response simulator employ a distributed deployment mode, meaning the attack request simulator contains multiple nodes deployed in different production network regions, while the attack response simulator contains multiple nodes deployed in different external network environments. This two-end distributed deployment architecture can simulate complex attack scenarios involving multiple sources and multiple targets. For example, attack request simulators on different production network segments can launch parallel attacks against attack response simulators in different external network regions, or the same attack script can be executed synchronously across multiple simulators. Its benefits are twofold: firstly, it significantly increases the scale and coverage of attack simulations, comprehensively verifying the detection capabilities of network security devices against distributed attacks and cross-regional collaborative attacks, avoiding the limitations of single-node simulation; secondly, by executing attack tasks in parallel across multiple nodes, it can simulate the actual pressure of concurrent traffic in a real network, testing the stability and detection efficiency of devices under high load, while supporting differentiated verification needs for different attack types and network scenarios. This makes the final effectiveness evaluation results more comprehensive and closer to actual network defense scenarios, providing a more accurate and diverse verification environment for network security devices.

[0060] See in some examples Figure 3 , Figure 3 The flowchart of S101 is shown; S101 includes:

[0061] S1011. Based on alarm data, obtain the protocol session characteristics of the attack traffic.

[0062] Protocol session features refer to the technical elements extracted from communication traffic that can completely reconstruct a network interaction behavior. Protocol session features may include at least one of the following: network layer features, such as source Internet Protocol (IP) address, destination Internet Protocol address, communication protocol type, etc.; transport layer features, such as source port number, destination port number, transmission control protocol status flags, raw payload byte stream, etc.; application layer features, such as request method, resource path, header fields, request / response body content, etc.; behavioral layer features, such as timing relationship, interaction logic, protocol behavior fingerprint, etc. Of course, other features may also be included, which are not limited here.

[0063] In some examples, S1011 includes:

[0064] Step 1: Decode and splice the alarm data to obtain the malicious sample download address. Download the malicious sample in the security sandbox according to the malicious sample download address, run the malicious sample and capture attack traffic to generate a malicious sample sampling packet.

[0065] This process involves parsing the payload field in the alarm to reconstruct the malicious sample download link. The malicious sample is then downloaded and run in the isolated environment of a security sandbox, capturing its attack traffic to generate malicious sample packets. Hardware virtualization technology can be used to ensure environmental isolation and prevent samples from contaminating the production network.

[0066] Step 2: Analyze the malicious sample packet to obtain protocol session characteristics, and generate attack request scripts and attack response scripts based on the protocol session characteristics.

[0067] Extract protocol session features from malicious sample packets, such as network layer: source / destination IP address; transport layer: port number, TCP flags, raw payload byte stream; application layer: HTTP request method (GET / POST), resource path (URI), header fields, etc.; behavior layer: multi-round interaction patterns, such as "heartbeat request → command response" cycle, etc., without limitation. See below for specific methods of generating attack request / response scripts.

[0068] S1012. Generate an attack request script based on the protocol session characteristics.

[0069] In some examples, attack request scripts can support multiple formats, such as at least one of Hypertext Transfer Protocol (HTTP) attack request scripts and Transmission Control Protocol (TCP) attack request scripts, and of course, other formats may also be included, which are not limited here.

[0070] In the case of an HTTP attack request playbook, S1012 includes:

[0071] Based on the protocol session characteristics, generate an HTTP attack request script that includes at least one of the following: request method, target address, headers, and attack characteristics.

[0072] Among them, the request method can be extracted from the application layer features; the target address: that is, the target address of the attack request, can be converted from the destination IP at the network layer (such as Host:xxxxx.com); attack features: can be obtained from the behavior layer.

[0073] In the case of a TCP attack request script, S1012 includes:

[0074] Based on the protocol session characteristics, generate a TCP attack request script that includes at least one of the source address, destination address, and original payload byte stream.

[0075] Among them, the source address (port) can be extracted from the transport layer features; the destination address (port) is the target address of the attack request, which in some cases can be fixed as the address of the attack response simulator; the raw payload byte stream can be the raw data of the payload field of the transport layer.

[0076] S1013. Generate an attack response script based on the protocol session characteristics.

[0077] In some examples, S1013 includes:

[0078] Based on the characteristics of the protocol session, generate an attack response script that includes at least one of the following: attack request matching conditions, attack response content, and attack type.

[0079] The attack response script can include attack response scripts based on text-based protocols or attack response scripts based on binary stream format (Hex Stream).

[0080] The attack request matching criteria include input configuration items, which define the rules for triggering a response. These are typically characteristic identifiers in the attack request, such as a specific path in a Hypertext Transfer Protocol (HTTP) request or a characteristic byte sequence in a Transmission Control Protocol (TCP) payload. For example, if the attack request contains the string "vshell", then the corresponding response will be triggered.

[0081] Among them, the attack response script for text-based protocols can be defined as string matching rules; the attack response script for binary stream formats can be defined as byte stream features.

[0082] The attack response content (output) defines the specific data returned after a successful match. It can be in text format, such as the Hypertext Transfer Protocol response header and body, or in binary stream format, such as the raw byte response of the Transmission Control Protocol. The content can include feedback characteristics of the target end in a real attack, such as system information of the compromised host, encrypted command execution results, etc.

[0083] Among them, the attack response script for text-based protocols can return a readable string; the attack response script for binary stream format can return raw bytes.

[0084] Attack type identifier indicates the attack category corresponding to the response, helping the attack response simulator to quickly identify and load the corresponding response strategy.

[0085] See in some examples Figure 4 , Figure 4 The flowchart of S102 is shown; in S102, an attack request is constructed based on the attack request script and sent to the attack response simulator, including:

[0086] S1021. Generate a unique traffic identifier corresponding to the attack request script and embed it into the attack request.

[0087] This step is used to construct attack requests based on attack request scripts and send them to the attack response simulator. The unique traffic identifier is used as a traffic marker to make the traffic of the attack simulation traceable. In each environment, the traffic flow and sending / receiving status can be known based on the unique traffic identifier.

[0088] For example, a unique traffic identifier can be embedded in an attack request in the following ways:

[0089] HTTP attack request script: Insert custom header field X-Tag; TCP attack request script: Append to the end of the payload byte stream.

[0090] The unique traffic identifier corresponding to the attack request script is generated in the following way:

[0091] A unique traffic identifier is obtained by performing a hash operation based on the script name, the IP address of the attack request, and the target address of the attack response simulator.

[0092] For example, the script name, the IP address of the attack request, and the target address of the attack response simulator are hashed using the Message Digest Algorithm Version 5 (MD5) to generate a 32-bit hexadecimal string as a unique traffic identifier.

[0093] It should be noted that the term "script name" mentioned in this disclosure can refer to the name of an attack script in general, including the name of the attack request script and / or the name of the attack response script, and the two script names can be the same.

[0094] S1022. Replace the target address in the attack request with the address of the corresponding attack response simulator.

[0095] Replace the original target address in the attack request script, i.e. the target address contained in the alarm data, with the actual deployment address of the attack response simulator to ensure the effectiveness of the attack interaction link.

[0096] S1023. Send the attack request to the attack response simulator.

[0097] The processed attack request is sent to the attack response simulator. The attack request, after being embedded with a unique traffic identifier and having its target address replaced, possesses the protocol characteristics, target information, and unique identifier of a real attack. Upon sending, it triggers the matching and response logic of the attack response simulator. It should be noted that after the attack response simulator identifies that the request matches the attack response script's matching conditions, the generated attack response will also include this unique traffic identifier, forming a complete tagging association across the request-response chain.

[0098] It should be noted that in some examples, the attack response simulator constructs an attack response containing a unique traffic identifier when the attack request is hit.

[0099] It should be noted that the unique traffic identifier is the core technical element for achieving a closed loop of attack simulation and detection verification in this disclosure. First, a traceable identifier is established in the mixed traffic through a cryptographically strong unique identifier, serving as a deterministic correlation channel between simulated attack requests and alarm data. For example, when a network security device detects an alarm containing a unique traffic identifier of xxxx, it can be confirmed as a valid event triggered in this test, eliminating interference from real attack traffic. Second, the unique traffic identifier enables traffic coverage blind spot diagnosis. If the attack request simulator records successful transmission (e.g., error code = 0), but there is no corresponding marker value in the alarm data, it directly exposes the network security device's traffic collection defects. For example, if the unique traffic identifier exists in the simulated time-series data but is missing in the alarm data in a certain test, the capture timeliness of the network security device can be located. Finally, the unique traffic identifier can be used for detection policy failure analysis. When an alarm contains a marker value but does not match the expected device detection rules, it can be determined as a detection policy configuration vulnerability. Thus, the coarse-grained verification of "whether it was detected" in traditional BAS is upgraded to fine-grained diagnosis of "which rule detected it and with what precision".

[0100]

[0101] Exemplary Unique Traffic Identifier Table 1-1

[0102] In some examples, S103 includes:

[0103] Based on the attack requests and attack responses, construct attack simulation time-series data containing at least one of the following: script name, attack request IP address, target address of the attack response simulator, unique traffic identifier, attack request sending time, error code, and number of attack requests sent per minute.

[0104] This step is used to structurally record the interaction process between attack requests and responses, generating attack simulation time-series data to provide traceable original evidence for subsequent verification. This data is constructed based on the actual situation of attack request sending and response receiving, and may, for example, include the following key information:

[0105] Basic information, such as the script name of the attack script, identifies the type of attack being simulated; the IP address of the attack request simulator, records the location of the attack initiator; the target address of the attack response simulator, records the location of the attack target, used to clarify the network location of the attack scenario;

[0106] Tracking identifier: a unique traffic identifier that serves as a unique marker for each attack interaction, spanning the entire request and response chain;

[0107] Timing and status information: including the attack request sending time, with adjustable precision; error codes, such as "0" for normal interaction, "1" for response simulator unreachable, and "2" for attack request sending failure, used to record abnormal interaction situations; the number of attack requests sent per minute, used to reflect the attack frequency and simulate the traffic pressure of a real attack.

[0108] By integrating this information, the attack simulation time-series data forms a log of the attack simulation process, clearly showing the initiator, target, time point, execution status, and traffic scale of the attack, laying the foundation for subsequent correlation analysis with alarm data from network security devices.

[0109]

[0110] Exemplary attack simulation timing data table 1-2

[0111] In some examples, prior to S104, the method also includes:

[0112] S100. Generate device detection rules based on alarm data, and / or generate dial-up verification rules based on alarm data.

[0113] S100 can be executed at any step before S104, and there is no limitation here.

[0114] The device detection rules include at least a rule number and rule details; the test verification rules include at least a mapping table between script names and rule numbers, which is used to associate attack request scripts, attack response scripts and corresponding device detection rules during verification.

[0115] Device detection rules are generated based on alarm data from network security devices. Threat characteristics (such as malicious domains and abnormal ports) are extracted from the alarm data and standardized. The rules include at least a rule number and rule details. For example, rule details include detecting HTTP requests with Cobalt Strike characteristics to clarify the attack characteristics that the device should be hit. The rules may also include traffic verification rules and detection policy verification rules, which are then distributed to network security devices.

[0116] The testing and verification rules establish a correlation between attack scripts and device detection rules. Specifically, this includes a mapping table between script names and rule numbers. For example, the attack request script 'CobaltStrikeHTTP' corresponds to the device detection rule number '2xxxx', ensuring that the attack scenario and the corresponding detection standard can be accurately matched during verification.

[0117]

[0118] Exemplary Equipment Testing Rules Table 1-3

[0119] For example, the testing and verification steps may include:

[0120] Based on the rule number list in the test verification rules, verify whether the alarm data of the network traffic analysis device contains the expected rule number;

[0121] If the alarm data does not match the expected rule number, the detection strategy is deemed to be ineffective.

[0122] If the alarm data does not contain traffic marker values, it is determined to be a traffic coverage blind spot.

[0123] In some examples, S104 includes:

[0124] S1041. Construct retrieval rules based on equipment detection rules;

[0125] Based on the device detection rules generated by S100, retrieval rules are constructed for retrieving network security device alarm data. The retrieval rules need to integrate the logic of the device detection rules with the tracking identifiers of the attack simulation, such as the rule number in the alarm data minus the device detection rule number. Furthermore, the alarm data contains a unique traffic identifier to ensure accurate location of detection records related to the current attack simulation from massive amounts of alarm data.

[0126] S1042. Retrieve matching data from alarm data according to retrieval rules, and generate verification time sequence data based on the matching data.

[0127] Using the retrieval rules constructed in S1041, matching records are filtered from the alarm data of network security devices to generate verification time-series data. This verification time-series data, constructed from the device's detection results, includes at least: the attack response simulator address, used to associate with the attack target; a unique traffic identifier, used to associate with the attack simulation time-series data; the rule number and rule name of the device's detection rule, used to clarify the detection criteria for a hit; the alarm sending time, used for comparison with the attack request time; and the number of rule hits per minute, used to reflect the device's detection frequency of attack traffic. Essentially, the verification time-series data is a detection log of the network security device against simulated attacks, recording the specific details of the attack identification by the device.

[0128] The verification time-series data includes at least one of the following: attack response simulator address, unique traffic identifier, rule number of device detection rule, rule name, sending time, and number of rule hits per minute.

[0129]

[0130] Exemplary verification timing data tables 1-4

[0131] S1043. Verify the effectiveness of network security devices based on verification timing data and attack simulation timing data.

[0132] In some examples, S1043 includes:

[0133] Step 1: Compare and verify the unique traffic identifier in the time-series data with the unique traffic identifier in the attack simulation time-series data to obtain the number of attack request hits.

[0134] By comparing the unique traffic identifiers in the two datasets, if the unique traffic identifier of a certain attack request exists in both the attack simulation time series data and the verification time series data, it means that the request has been successfully detected by the device, and the number of attack request hits is counted.

[0135] Step 2: Verify the effectiveness of network security devices based on the ratio of the number of successful attack requests to the total number of attack requests.

[0136] Specifically, step two can calculate the hit rate using the formula "number of successful attack requests / total number of attack requests". The result is used to verify the effectiveness of the network security device. A security threshold can be preset; if the hit rate is greater than the threshold, the verification is successful; otherwise, it is not, thus evaluating the device's detection capabilities. For example, if 100 attack requests are sent and the device succeeds 85 times, the hit rate is 85%, reflecting the device's coverage and detection accuracy for this type of attack. If the hit rate is too low, vulnerabilities in the device's rule configuration, traffic parsing, etc., can be identified, providing direction for optimization.

[0137] In the first disclosed embodiment, participants Figure 5 , Figure 5 This diagram illustrates a flowchart of a verification method for a network security device according to a second embodiment of this disclosure. The method is applied to one side of an attack response simulator and includes:

[0138] S201. Receive the attack request sent by the attack response requester, match the attack request with the received attack response script, construct an attack response based on the matching result and send it to the attack response requester.

[0139] The attack request is generated according to the method of the first disclosed embodiment; the attack response requester is configured to receive the attack request and verify the effectiveness of the network security device according to the method of the first disclosed embodiment.

[0140] The attack response simulator receives attack requests sent by the attack request simulator, performs matching and judgment based on pre-configured attack response scripts, and finally generates and returns an attack response. The attack request is generated by the method of Embodiment 1 and includes real attack characteristics and a unique traffic identifier. The attack request simulator will subsequently verify the detection capabilities of the network security device based on the attack request-attack response interaction data, following the method of Embodiment 1.

[0141] In some examples, an attack response script includes at least one of the following: attack request matching criteria, attack response content, and attack type.

[0142] In some examples, S201 includes:

[0143] S2011. Receive the attack request sent by the attack response requester and determine whether the attack request matches the input configuration item corresponding to the attack request matching condition.

[0144] Parse the content of the industrial control request and compare it with the attack request matching conditions (input configuration items) in the script. For HTTP attack requests, this can specifically check whether the request line / header / body contains a preset string; for TCP attack requests, it can match a specific sequence of payload byte streams.

[0145] S2012. Under certain conditions, construct an attack response based on the attack response content and the unique traffic identifier carried in the attack request, and send it to the attack response requester.

[0146] When an attack request matches the attack request matching criteria, a response can be generated. For text-formatted attack response scripts, the output configuration items can be read; for hexadecimal stream attack response scripts, the response can be constructed according to a preset byte stream. Furthermore, a unique traffic identifier carried in the attack request can be appended to the end of the response.

[0147] Specifically, when the attack response script is in text format, if the request hits the input configuration item, the output content is returned with a traffic tag value appended before the connection is closed.

[0148] When the attack response script is in hexadecimal stream format, if the request hits the input configuration item, the long connection is maintained until the match ends, and the response is returned with an additional traffic marker value.

[0149] In the disclosed second embodiment, see Figure 6 , Figure 6 A schematic diagram of the structure of a verification device for a network security device according to a third embodiment of this disclosure is shown. The device includes:

[0150] The script generation module 601 is used to generate attack request scripts and attack response scripts based on the alarm data of network security devices, and send the attack response scripts to the attack response simulator.

[0151] The request generation module 602 is used to construct an attack request based on the attack request script and send the attack request to the attack response simulator. The attack response simulator is configured to receive the attack request, match the attack request with the received attack response script, construct an attack response based on the matching result, and return it.

[0152] The timing construction module 603 is used to obtain attack simulation timing data based on the received attack requests and attack responses;

[0153] The security verification module 604 is used to verify the effectiveness of network security devices based on alarm data and attack simulation time series data.

[0154] In some examples, the script generation module 601 is specifically used for:

[0155] Based on alarm data, obtain the protocol session characteristics of the attack traffic;

[0156] Generate attack request scripts based on protocol session characteristics;

[0157] An attack response script is generated based on the characteristics of the protocol session.

[0158] In some examples, the attack request script includes at least one of the Hypertext Transfer Protocol attack request script and the Transmission Control Protocol attack request script;

[0159] In the case of generating an attack request script based on protocol session characteristics, the script generation module 601 is specifically used for:

[0160] Based on the protocol session characteristics, generate a Hypertext Transfer Protocol attack request script that includes at least one of the following: request method, target address, header, and attack characteristics.

[0161] Based on the characteristics of the protocol session, generate a Transmission Control Protocol (TCP) attack request script that includes at least one of the source address, destination address, and original payload byte stream.

[0162] In some examples, the script generation module 601 is specifically used to generate attack response scripts based on protocol session characteristics, specifically for:

[0163] Based on the characteristics of the protocol session, generate an attack response script that includes at least one of the following: attack request matching conditions, attack response content, and attack type.

[0164] In some examples, the script generation module 601 is specifically used to obtain the protocol session characteristics of attack traffic based on alarm data:

[0165] The alarm data is decoded and spliced ​​to obtain the malicious sample download address. The malicious sample is downloaded in the security sandbox according to the malicious sample download address, the malicious sample is run and the attack traffic is captured to generate a malicious sample sampling packet.

[0166] The malicious sample packet is parsed to obtain protocol session characteristics, and attack request scripts and attack response scripts are generated based on the protocol session characteristics.

[0167] In some examples, requesting the generation module 602 is specifically used for:

[0168] Generate a unique traffic identifier corresponding to the attack request script and embed it into the attack request;

[0169] Replace the target address in the attack request with the address of the corresponding attack response simulator;

[0170] Send the attack request to the attack response simulator.

[0171] In some examples, the unique traffic identifier corresponding to the attack request script is generated in the following way:

[0172] A unique traffic identifier is obtained by hashing the script name, the attack request Internet Protocol address, and the target address of the attack response simulator.

[0173] In some examples, the attack response simulator constructs an attack response containing a unique traffic identifier when the attack request is hit.

[0174] In some examples, timing construction module 603 is specifically used for:

[0175] Based on the attack requests and attack responses, construct attack simulation time-series data containing at least one of the following: script name, attack request Internet Protocol address, target address of the attack response simulator, unique traffic identifier, attack request sending time, error code, and number of attack requests sent per minute.

[0176] In some examples, the device also includes:

[0177] The rule generation module is used to generate device detection rules based on alarm data, and / or to generate dial-up verification rules based on alarm data.

[0178] In some examples, device detection rules include at least a rule number and rule details; probing verification rules include at least a mapping table of script names and rule numbers, used to associate attack request scripts, attack response scripts and corresponding device detection rules during verification.

[0179] In some examples, the security verification module 604 is specifically used for:

[0180] Construct retrieval rules based on equipment detection rules;

[0181] The matching data is retrieved from the alarm data according to the retrieval rules, and the verification time series data is generated based on the matching data.

[0182] The effectiveness of network security devices is verified based on verification time-series data and attack simulation time-series data.

[0183] In some examples, the verification timing data includes at least one of the following: attack response simulator address, unique traffic identifier, rule number of device detection rule, rule name, sending time, and number of rule hits per minute.

[0184] In some examples, the security verification module 604 verifies the effectiveness of the network security device based on verification timing data and attack simulation timing data, specifically for:

[0185] By comparing the unique traffic identifier in the verification time series data with the unique traffic identifier in the attack simulation time series data, the number of attack request hits is obtained;

[0186] The effectiveness of network security devices is verified by the ratio of the number of successful attack requests to the total number of attack requests.

[0187] In some examples, the method is applied to an attack request simulator; the attack request simulator and the attack response simulator are deployed on different networks.

[0188] In some examples, the attack request simulator includes multiple distributed deployments; the attack response simulator includes multiple distributed deployments.

[0189] See in some examples Figure 7 , Figure 7 A schematic diagram of the structure of a verification device for a network security device according to a fourth embodiment of the present disclosure is shown. The device includes:

[0190] The attack response module 701 is used to receive the attack request sent by the attack response requester, match the attack request with the received attack response script, construct an attack response based on the matching result and send it to the attack response requester.

[0191] The attack request is generated according to the method of the first disclosed embodiment; the attack response requester is configured to receive the attack request and verify the effectiveness of the network security device according to the method of the first disclosed embodiment.

[0192] In some examples, an attack response script includes at least one of the following: attack request matching criteria, attack response content, and attack type.

[0193] In some examples, the attack response module 701 is specifically used for:

[0194] Receive attack requests sent by the attack response requester and determine whether the input configuration items of the attack request match the attack request matching conditions.

[0195] Under certain conditions, an attack response is constructed based on the attack response content and the unique traffic identifier carried in the attack request, and then sent to the attack response requester.

[0196] In the technical solution disclosed herein, the collection, storage, use, processing, transmission, provision, disclosure, and application of user personal information comply with the provisions of relevant laws and regulations, necessary confidentiality measures have been taken, and there is no violation of public order and good morals.

[0197] In the technical solution disclosed herein, the user's authorization or consent is obtained before acquiring or collecting the user's personal information.

[0198] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0199] like Figure 8 As shown, device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 802 or a computer program loaded from storage unit 802 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0200] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0201] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as a network security device verification method. For example, in some embodiments, the network security device verification method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the network security device verification method described above can be performed. Alternatively, in other embodiments, the computing unit 801 can be configured with the network security device verification method by any other suitable means (e.g., by means of firmware).

[0202] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0203] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0204] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0205] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0206] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0207] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0208] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0209] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for verifying a network security device, wherein, The method includes: Based on the alarm data from network security devices, attack request scripts and attack response scripts are generated, and the attack response scripts are sent to the attack response simulator. An attack request is constructed based on the attack request script and sent to the attack response simulator. The attack response simulator is configured to receive the attack request, match the attack request with the received attack response script, construct an attack response based on the matching result, and return it. Based on the received attack request and attack response, attack simulation time series data is obtained; The effectiveness of the network security device is verified based on the alarm data and the attack simulation time series data.

2. The method according to claim 1, wherein, The process of generating attack request scripts and attack response scripts based on alarm data from network security devices includes: Based on the alarm data, obtain the protocol session characteristics of the attack traffic; The attack request script is generated based on the protocol session characteristics; The attack response script is generated based on the protocol session characteristics.

3. The method according to claim 2, wherein, The attack request script includes at least one of the Hypertext Transfer Protocol attack request script and the Transmission Control Protocol attack request script; The step of generating the attack request script based on the protocol session characteristics includes: Based on the protocol session characteristics, generate a Hypertext Transfer Protocol attack request script that includes at least one of the following: request method, target address, header, and attack characteristics. Based on the protocol session characteristics, a Transmission Control Protocol (TCP) attack request script is generated, which includes at least one of the source address, destination address, and original payload byte stream.

4. The method according to any one of claims 2 or 3, wherein, The step of generating the attack response script based on the protocol session characteristics includes: Based on the protocol session characteristics, an attack response script is generated that includes at least one of the following: attack request matching conditions, attack response content, and attack type.

5. The method according to any one of claims 2-4, wherein, The process of obtaining protocol session characteristics of attack traffic based on the alarm data includes: The alarm data is decoded and spliced ​​to obtain the malicious sample download address. The malicious sample is downloaded in the security sandbox according to the malicious sample download address, the malicious sample is run and the attack traffic is captured to generate a malicious sample sampling packet. The malicious sample packet is parsed to obtain the protocol session characteristics, and the attack request script and attack response script are generated based on the protocol session characteristics.

6. The method according to any one of claims 1-5, wherein, Constructing an attack request based on the attack request script and sending the attack request to the attack response simulator includes: Generate a unique traffic identifier corresponding to the attack request script and embed it into the attack request; Replace the target address in the attack request with the address of the corresponding attack response simulator; The attack request is sent to the attack response simulator.

7. The method according to claim 6, wherein, The unique traffic identifier corresponding to the attack request script is generated in the following way: The unique traffic identifier is obtained by performing a hash operation based on the script name, the attack request Internet Protocol address, and the target address of the attack response simulator.

8. The method according to claim 6 or 7, wherein, The attack response constructed by the attack response simulator when the attack request is hit contains the unique traffic identifier.

9. The method according to any one of claims 1-8, wherein, The step of obtaining attack simulation time-series data based on the received attack request and attack response includes: Based on the attack request and the attack response, construct the attack simulation timing data, which includes at least one of the following: script name, attack request Internet Protocol address, target address of the attack response simulator, unique traffic identifier, attack request sending time, error code, and number of attack requests sent per minute.

10. The method according to any one of claims 1-9, wherein, Before verifying the effectiveness of the network security device based on the alarm data and the attack simulation time series data, the method further includes: Device detection rules are generated based on the alarm data, and / or dial-up verification rules are generated based on the alarm data.

11. The method according to claim 9, wherein, The equipment detection rules shall include at least a rule number and rule details; The test verification rules include at least a mapping table of script names and rule numbers, which is used to associate attack request scripts, attack response scripts and corresponding device detection rules during verification.

12. The method according to any one of claims 10 or 11, wherein, The verification of the effectiveness of the network security device based on the alarm data and the attack simulation time series data includes: Retrieval rules are constructed based on the aforementioned device detection rules; The matching data is retrieved from the alarm data according to the retrieval rules, and verification time sequence data is generated based on the matching data. The effectiveness of the network security device is verified based on the verification timing data and the attack simulation timing data.

13. The method according to claim 12, wherein, The verification timing data includes at least one of the following: attack response simulator address, unique traffic identifier, rule number of device detection rule, rule name, sending time, and number of rule hits per minute.

14. The method according to claim 12 or 13, wherein, The verification of the effectiveness of the network security device based on the verification timing data and the attack simulation timing data includes: The number of attack request hits is obtained by comparing the unique traffic identifier in the verification time series data with the unique traffic identifier in the attack simulation time series data. The effectiveness of the network security device is verified by the ratio of the number of successful attack requests to the total number of attack requests.

15. The method according to any one of claims 1-14, wherein, The method is applied to an attack request simulator; the attack request simulator and the attack response simulator are deployed on different networks.

16. The method according to claim 15, wherein, The attack request simulator includes multiple distributed simulators; the attack response simulator includes multiple distributed simulators.

17. A method for verifying a network security device, wherein, The method includes: Receive an attack request sent by an attack response requester, match the attack request with the received attack response script, construct an attack response based on the matching result, and send it to the attack response requester. The attack request is generated according to the method of claim 1; the attack response requester is configured to receive the attack request and verify the validity of the network security device according to the method of claim 1.

18. The method according to claim 17, wherein, The attack response script includes at least one of the following: attack request matching conditions, attack response content, and attack type.

19. The method according to claim 18, wherein, Receiving an attack request sent by an attack response requester, matching the attack request with a received attack response script, constructing an attack response based on the matching result, and sending it to the attack response requester, including: Receive attack requests sent by the attack response requester and determine whether the attack request matches the input configuration item corresponding to the attack request matching condition; Under certain conditions, an attack response is constructed based on the attack response content and the unique traffic identifier carried in the attack request, and then sent to the attack response requester.

20. A verification device for a network security device, wherein, The device includes: The script generation module is used to generate attack request scripts and attack response scripts based on alarm data from network security devices, and send the attack response scripts to the attack response simulator. A request generation module is used to construct an attack request based on the attack request script and send the attack request to the attack response simulator, wherein the attack response simulator is configured to receive the attack request, match the attack request with the received attack response script, construct an attack response based on the matching result, and return it. The timing construction module is used to obtain attack simulation timing data based on the received attack request and the attack response; The security verification module is used to verify the effectiveness of the network security device based on the alarm data and the attack simulation time series data.

21. A verification device for a network security device, wherein, The device includes: The attack response module is used to receive attack requests sent by the attack response requester, match the attack requests with the received attack response scripts, construct an attack response based on the matching results, and send it to the attack response requester. The attack request is generated according to the method of claim 1; the attack response requester is configured to receive the attack request and verify the validity of the network security device according to the method of claim 1.

22. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-16.

23. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-16.

24. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-16.

Images