An automated defect analysis and protocol statistics method for ics traffic databases

Abstract

This invention discloses an automated defect analysis and protocol statistics method for ICS traffic databases, comprising: based on various open-source shared industrial control system traffic databases, automatically determining file format uniformity through batch path retrieval and suffix clustering statistics; using the tshark command to batch read data packets and capture error information, filtering corrupted data packets; and employing a dual-mode collaborative mechanism of direct and indirect methods to automatically count industrial control protocol categories and all protocol categories, and identify mixed packets. The direct method reduces the false alarm rate through hierarchical regular expression matching and protocol normalization processing, while the indirect method extracts core protocols through protocol layer parsing to identify unknown protocols, and combines a prior industrial control protocol knowledge base to accurately distinguish between industrial control and non-industrial control protocols. This invention achieves full-process automation, improves data processing efficiency and accuracy, and provides high-quality dataset support for standardized database establishment and subsequent industrial control security research.

Description

Technical Field

[0001] This invention relates to the fields of industrial control system (ICS) security testing, network traffic data analysis and automated testing, and in particular to an automated defect analysis and protocol statistics method for ICS traffic databases. Background Technology

[0002] Industrial control systems (ICS) are core components of critical infrastructures such as energy, power, chemical industry, and rail transportation. Their safe and stable operation is directly related to national public safety and economic development. The ICS traffic database, as a fundamental resource for ICS security research, contains various protocol data and interactive behavior characteristics of ICS equipment during communication processes. It serves as a core basis for developing intrusion detection systems, protocol reverse engineering, and vulnerability exploitation verification technologies.

[0003] However, the current processing and analysis of ICS traffic databases suffer from numerous pain points, severely restricting the efficiency and accuracy of industrial control security research: First, the database collection sources are scattered and lack a systematic approach, lacking a unified tracking mechanism and failing to guarantee regular updates and further filtering and organization. This forces researchers to spend a significant amount of time filtering effective data and makes it difficult to obtain the latest data. Second, the data packets within the database suffer from defects such as inconsistent file formats and incomplete content. Defect analysis also relies on manual methods, resulting in low efficiency and poor accuracy. Traditional methods rely on manual verification using Wireshark, which cannot process data in batches and struggles to identify hidden issues such as "truncated corruption." Manual verification using tshark is extremely time-consuming. Furthermore, industrial control protocols suffer from weak message characteristics, port reuse, and proprietary protocols, leading to high false alarm rates for regular expression matching and invalid unknown protocols. Additionally, there is a lack of a mechanism to identify "hybrid packets" (a single data packet containing multiple industrial control protocols), failing to accurately reflect the core protocol category of the data packet and affecting the relevance of subsequent security analysis.

[0004] While some existing network data parsing methods (such as CN202010767366.7) have achieved network data classification and sniffing, multi-method parsing, and private protocol extension, they still have significant limitations: First, these methods focus on general network data parsing and do not design defect analysis mechanisms specifically for the characteristics of ICS traffic databases, thus failing to address specific issues such as inconsistent file formats and corrupted data packets in industrial control scenarios. Second, their protocol identification relies on Tshark tools for layer-by-layer parsing and customized rule supplementation, without optimizing the identification logic for the weak characteristics of industrial control protocol messages and port reuse, resulting in a high false alarm rate. Third, they lack a specific identification scheme for "mixed packets" in ICS scenarios, failing to meet the core need for accurate statistical analysis of protocol categories in industrial control security research.

[0005] In summary, the existing ICS traffic database processing methods suffer from core problems such as "fragmented data collection, inefficient defect analysis, and inaccurate protocol statistics." There is an urgent need for an automated, multi-dimensional, and high-precision processing method to achieve efficient preprocessing and in-depth analysis of ICS traffic databases. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by proposing an automated defect analysis and protocol statistics method for ICS traffic databases. Utilizing various open-source and shared Industrial Control System (ICS) traffic databases, after preprocessing the files, defect analysis is performed on the data packets within the ICS traffic database. This includes: analyzing data packet suffixes to automatically determine the uniformity of file formats; filtering corrupted data packets, reading each packet individually and determining the integrity of its file content; statistically analyzing ICS protocols, identifying mixed packets using both direct and indirect methods, and automatically statistically analyzing ICS protocol categories and all protocol categories.

[0007] The objective of this invention is achieved through the following technical solution: an automated defect analysis and protocol statistics method for ICS traffic databases, the method comprising: A database of industrial control system flow was collected based on open resources and literature review citations. Perform multi-level verification decompression on data packets of the industrial control system flow database; extract and count the file extension strings of all data packet files, and output the file format uniformity status; batch call the tshark command to read data packets and capture error information, and separate intact data packets from damaged data packets; The direct method of industrial control protocol identification is adopted, which combines regularity optimization and protocol normalization statistical collaboration; the indirect method of industrial control protocol identification is adopted, which combines protocol hierarchy parsing and highest-level extraction collaboration; the statistical results of the direct and indirect methods are cross-validated to obtain the final statistical results.

[0008] Furthermore, the collection of industrial control system traffic databases based on open resources and paper reviews specifically includes: taking GitHub open resources as the core source, starting with the ICS-pcap traffic database compiled by The Information Trust Institution, and expanding the collection according to citation information to form three types of core databases: original databases that rely on their own laboratory data collection and public release, ICS traffic index pages that rely on existing open source databases, and public online databases that rely on public sharing and maintenance, thereby achieving a systematic integration of open source resources; Using literature reviews as supplementary sources and Mauro Conti's research on industrial control systems as a reference, we collected and summarized laboratory papers related to logic programmable controllers, and extracted and standardized the publicly available experimental data from these papers.

[0009] Furthermore, the multi-level verification-based decompression of the data packets in the industrial control system flow database specifically includes: A recursive traversal algorithm is used to decompress all ZIP files in the ICS traffic database and its subdirectories one by one. Compatibility files generated during decompression are identified and deleted simultaneously to avoid redundant files interfering with subsequent analysis. After decompression, a path scanning mechanism is used to uniformly check the number of residual ZIP files in all ICS traffic databases. If the number of residual files is 0, the check is considered passed and the process proceeds to the next step. If residual files exist, the decompression process of the corresponding directory is re-executed to achieve 100% verification of decompression integrity.

[0010] Furthermore, the step of extracting and statistically analyzing the file extension strings of all data packets specifically includes: A batch path retrieval algorithm is used to traverse all data packet files in the target ICS traffic database and extract the file extension string of each file. Construct a file extension statistics dictionary to automatically count the number of data packets with different file extensions; If the statistical results show that the database contains only one type of file extension, it is determined that the file format is uniform; if there are two or more types, the distribution of the number of each type of file extension will be output.

[0011] Furthermore, the step of batch calling the tshark command to read data packets and capture error information specifically includes: Iterate through all data packets with the suffixes .cap, .pcap, and .pcapng in the ICS traffic database, and use Python's subprocess module to call the tshark command in batches to attempt to read the data packets; Capture standard error output during tshark execution, matching error messages for truncated corruption, format incompatibility corruption, and general corruption. If any of the above error messages are captured, the data packet is determined to be a corrupted data packet, its path is automatically recorded and moved to a separate corrupted file directory, thus achieving automatic separation of intact data packets from corrupted data packets.

[0012] Furthermore, the direct method for industrial control protocol identification using regularization optimization and protocol normalization statistical coordination specifically includes: Traverse the valid data packets in the ICS traffic database and read the protocol field of each data row using the tshark command; Use general regular expressions to filter common protocol names, and then design specific matching rules for special protocol names; The protocol names belonging to the same category are uniformly replaced. The statistical protocol names are compared with the list of industrial control protocols in the knowledge base. Protocols that are not excluded are determined to be industrial control protocols, and non-industrial control protocols are removed. For a single data packet, if two or more industrial control protocol categories are statistically identified, it is determined to be a mixed packet. Finally, the total number of all protocol categories, the number of industrial control protocol categories, and the number of mixed packets in a single database are summarized.

[0013] Furthermore, the indirect method of using protocol layer parsing and top-level extraction in combination for industrial control protocol identification includes: traversing the valid data packets in the ICS traffic database, obtaining protocol hierarchy statistics through the tshark command, and filtering valid statistics between two identical lines, which are indented to represent the protocol hierarchy relationship; The hierarchy is determined by counting the number of spaces before the protocol name in each data line. Increasing indentation indicates a higher level, while decreasing indentation indicates switching to a different higher-level protocol. The highest-level protocols and their corresponding quantities within the same category are then filtered and counted. The statistically analyzed protocol names are compared with the list of industrial control protocols in the knowledge base. Protocols that are not excluded are identified as industrial control protocols, while non-industrial control protocols are removed. For a single data packet, if two or more industrial control protocol categories are identified, it is identified as a mixed packet. Finally, the total number of all protocol categories, industrial control protocol categories, and mixed packets in a single database are summarized.

[0014] Furthermore, the cross-validation of the statistical results of the direct and indirect methods includes: cross-validating the statistical results of the direct and indirect methods: if the industrial control protocol categories counted by the two methods are consistent, the results are directly output; if there are differences, priority is determined based on the prior industrial control protocol knowledge base and the application scenario of the data packet.

[0015] According to another aspect of the specification, an automated defect analysis and protocol statistics device for an ICS traffic database is also provided, including a memory and one or more processors. The memory stores executable code, and when the processor executes the executable code, it implements the aforementioned automated defect analysis and protocol statistics method for an ICS traffic database.

[0016] According to another aspect of the specification, a computer-readable storage medium is also provided, on which a program is stored, which, when executed by a processor, implements the aforementioned automated defect analysis and protocol statistics method for an ICS traffic database.

[0017] The beneficial effects of this invention are: Compared with existing technologies, this invention achieves end-to-end optimization of ICS traffic database processing through multi-source data integration, automated process design, and a dual-mode protocol statistical mechanism. Its core advantages are as follows: 1. The multi-source collaborative collection strategy breaks through the bottleneck of traditional fragmented data collection: It innovatively adopts a dual-channel collaborative collection approach, which not only covers a wide range of data from the open source community, but also fills the data gap in professional laboratory scenarios, ensuring the comprehensiveness and timeliness of the dataset, and solving the problems of single data source and untimely updates in existing technologies.

[0018] 2. Multi-level verification decompression mechanism ensures 100% integrity of decompression: Through a combination of recursive traversal decompression and residual compressed package verification, redundant files generated during the decompression process are automatically cleared, avoiding interference from residual compressed packages to subsequent analysis. Compared with the traditional manual decompression method, the efficiency is improved by at least 10 times, with no omissions and no errors.

[0019] 3. The automated defect analysis process completely replaces manual operation: Through techniques such as file extension clustering statistics, Tshark batch calls and error capture, the entire process of file format uniformity verification and corrupted data packet identification is fully automated. This not only improves the efficiency of defect analysis by dozens of times, but also accurately identifies hidden problems that are difficult to detect manually, such as "truncated corruption", providing standardized and repeatable judgment criteria for database quality assessment.

[0020] 4. Dual-mode protocol statistics mechanism accurately addresses existing technical pain points: Addressing the issues of weak characteristics in industrial control protocol messages, port reuse, and numerous proprietary protocols, the direct method reduces the false alarm rate of regular expression matching to below 5% through layered regular expression matching and protocol normalization. The indirect method extracts core protocols through protocol layer parsing, enabling effective identification of unknown industrial control protocols. Simultaneously, both methods possess mixed packet identification capabilities, filling the gap in existing technologies that lack mixed packet identification mechanisms. This ensures that protocol statistics results accurately reflect the core protocol category of data packets, providing precise data support for subsequent industrial control security analysis.

[0021] 5. Excellent compatibility and engineering practicality: Compatible with multiple mainstream data packet formats such as .cap, .pcap, and .pcapng; supports statistical analysis of all mainstream industrial control protocols such as Modbus, DNP3, S7comm, and IEC 61850; automated process design can match ICS traffic databases of different sizes (from hundreds of MB to tens of GB), and can complete the entire process without manual intervention, possessing broad engineering application value and promotion prospects. Attached Figure Description

[0022] Figure 1This is a target graph for traversing an ICS traffic database provided in an embodiment of the present invention; Figure 2 A flowchart illustrating an automated defect analysis and protocol statistics method for ICS traffic databases, provided as an embodiment of the present invention; Figure 3 Flowchart of the method for statistical data packet industrial control protocol using direct and indirect methods provided in embodiments of the present invention; Figure 4 This is a schematic diagram of an automated defect analysis and protocol statistics device for ICS traffic database provided in an embodiment of the present invention. Detailed Implementation

[0023] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0024] This application provides an automated defect analysis and protocol statistics method for ICS traffic databases. The operating environment is an Intel-Windows architecture PC with an Intel Core i7-8565U CPU with a main frequency of 1.80GHz or higher, ≥8GB of memory, 1TB of hard disk, and running Windows 11 operating system. The software programming language is Python 3.12.3, and the core libraries include os, re, subprocess, collections, etc. The traffic analysis tool is Wireshark 4.2.6 (including the tshark command line tool).

[0025] The target graph for traversing the ICS traffic database provided in this embodiment of the invention is as follows: Figure 1 As shown, it includes: The collected database is analyzed one by one, and the data packets in the protocol folder are gradually retrieved. Then, the protocol columns of the data packets are gradually retrieved. Finally, defect analysis and summary display of protocol information are performed.

[0026] The method provided by this invention comprises the following three core steps, which are linked together to form a complete automated data flow defect analysis and protocol statistics chain: Step 1: Multi-source collaborative collection of ICS traffic database Primarily based on two perspectives—GitHub open resources and paper reviews and citations—a multi-dimensional data collection and tracking mechanism is constructed to ensure the comprehensiveness and timeliness of the dataset.

[0027] The specific collection steps are as follows: 1.1 Taking GitHub open resources as the core source and the ICS-pcap traffic database compiled by The Information Trust Institution (ITI) as the starting point, the collection is expanded based on the reference information to form three types of core databases: original databases that rely on data collected and published by our own laboratory, ICS traffic index pages that rely on existing open source databases, and public online databases that rely on public sharing and maintenance, thus realizing the systematic integration of open source resources; 1.2 Using literature reviews as supplementary sources and the industrial control system survey compiled by Mauro Conti as a reference, we collected and summarized laboratory papers related to logic programmable controllers (PLCs), extracted the publicly available experimental data from the papers, standardized and organized them, and filled the gaps in professional scenario data in open source databases.

[0028] The ICS traffic database ultimately collected in this embodiment includes, but is not limited to: { 1_ICS-Security-Tools(ITI), 2_PCAPS(4SICS ICS), 3_ICS-pcap(automayt), 4_ctp-samples-protocols(controlthings-io), 5_ICS-Pcaps(Emre), 6_ICS-PCAPs(engage-svg), 7_s7-pcaps(gymgit), 8 _ICS_PCAPS(tjcruz-dei), 9_Industrial-protocols-dataset(hi-zer), 10_hvac_traces, 11_Modbus_dataset, 12_2017QUT_S7comm, 13_CTF-PCAP-files }; Step 2: Multi-level verification decompression of ZIP files To address the common issues of multi-level compression and decompression residues in ICS traffic databases, an automated decompression and verification process was designed to ensure thorough file cleanup and lay the foundation for subsequent defect analysis.

[0029] The specific decompression steps are as follows: 2.1 A recursive traversal algorithm is adopted to decompress all ZIP files in the ICS traffic database and its subdirectories one by one, and compatibility files generated during decompression (such as the MACOSX directory, .DS_Store files, etc.) are identified and deleted simultaneously to avoid redundant files interfering with subsequent analysis; 2.2 After decompression, the number of residual ZIP files in all ICS traffic databases is uniformly detected through the path scanning mechanism. If the number of residual files is 0, the detection is considered successful and the next step is initiated. If residual files exist, the decompression process of the corresponding directory is re-executed to achieve 100% verification of decompression integrity.

[0030] The output format is as follows: { Processing folder: D:\Documents\github\ICS\1_ICS-Security-Tools(ITI) Folder: 1_ICS-Security-Tools(ITI) Number of .zip files: 0 }; Step 3: Full-process automated defect analysis and dual-mode protocol statistics 3.1 Automated file extension classification and statistics (file format consistency verification) To address the issues of low efficiency and frequent omissions in traditional manual verification, an automated analysis mechanism based on file system traversal and file extension clustering is designed to achieve accurate judgment of file format uniformity.

[0031] The specific steps are as follows: 3.1.1 A batch path retrieval algorithm is used to traverse all data packet files in the target ICS traffic database and extract the file extension string for each file; 3.1.2 Construct a file extension statistics dictionary to automatically count the number of data packets with different file extensions. The core statistical file extensions include .cap, .pcap, and .pcapng (all three are data packets captured by Wireshark, the difference being their storage format). 3.1.3 If the statistical results show that the database contains only one type of file extension, it is determined to be "file format uniform"; if there are two or more types, the distribution of the number of each type of file extension is output to provide a basis for database standardization.

[0032] In this embodiment, the number of data packets with different file extensions is output through batch path retrieval and file extension clustering statistics, in the following format: { Processing folder: D:\Documents\github\ICS\1_ICS-Security-Tools(ITI) Folder: 1_ICS-Security-Tools(ITI) Number of .cap files: 0 Number of .pcap files: 344 Number of .pcapng files: 34 }; 3.2 Batch Corrupted Data Packet Identification Based on Tshark To address the issues of traditional manual verification's inability to process data in batches and the difficulty in identifying hidden corruption, an automated filtering mechanism based on command-line calls and error message capture is designed to achieve precise isolation of corrupted data packets.

[0033] The specific steps are as follows: 3.2.1 Traverse all data packets with the suffixes .cap, .pcap, and .pcapng in the ICS traffic database, and use Python's subprocess module to batch call the tshark command (command format: tshark -r data packet path) to attempt to read the data packets; 3.2.2 Capture the standard error output (stderr) during tshark execution and match three core error messages: "The file appears to have been cut short in the middle of a packet." (truncated corruption), "The file isn't a capture file in a format Tshark understands." (format incompatibility corruption), and "The file appears to be damaged or corrupt." (general corruption). 3.2.3 If any of the above error messages are captured, the data packet is determined to be a "corrupted data packet", its path is automatically recorded and moved to a separate corrupt file directory, thus achieving automatic separation of intact data packets and corrupted data packets.

[0034] In this embodiment, the tshark command is used in batches to read data packets, capture error messages, and filter out corrupted data packets. The output format is as follows: { Processing folder: D:\Documents\github\ICS\11_Modbus_dataset The tshark command execution failed: tshark: The file "D:\Documents\github\ICS\11_Modbus_dataset\run1_12rtu(1).pcap" appears to have been cut short in themiddle of a packet.}; 3.3 Industrial Control Protocol Statistics Using a Combination of Direct and Indirect Methods (Hybrid Packet Identification + Precise Classification) To address the three core problems in existing technologies—high false alarm rate of regular expression matching for industrial control protocols, ineffective identification of unknown protocols, and inability to identify mixed packets—an innovative dual-mode protocol statistics mechanism is designed. By combining a priori industrial control protocol knowledge base, it achieves accurate statistics of protocol categories and effective identification of mixed packets.

[0035] 3.3.1 Direct Method: Regular expression optimization + protocol normalization statistics (solving the problem of high false alarm rate in regular expression matching) The accuracy of industrial control protocol identification is improved by using customized regular expressions and protocol name normalization. The specific steps are as follows: 3.3.1.1 Traverse the valid data packets in the ICS traffic database and read the protocol field of each data line using the tshark command (command format: tshark -r data packet path -T fields -e frame.protocols); 3.3.1.2 Design a hierarchical regular expression matching strategy: First, filter common protocol names using the general regular expression "([A-Za-z]+[A-Za-z0-9 / -+.]+\s*[A-Za-z0-9_-.]\s[A-Za-z]*)"; then design specific matching rules for special protocol names ("802.11", "SCCP (Int. ITU)", "5co-xx", "? KNNnet / IP") to avoid missed identification. Specifically, for the protocol name "802.11", two types of dedicated regular expressions are designed to adapt tshark output lines of different formats: "^\s*\d+\s+[0-9.\-]+(?:\s+\S*)\s*→(?:\s+\S*)\s+(802.11)\s+\d+\s+.* (matching regular format output lines) and "^\s*\d+\s+[0-9.\-]+(?:\s+\S*\s*\S*)\s*→(?:\s+\S*\s+\S*\s+\S*)\s+(802.11)\s+\d+\s+.* (matching complex format output lines containing multiple segments of characters), for the protocol name "SCCP (Int). ITU): Design a dedicated regular expression “^\s*\d+\s+[0-9.\-]+(?:\s+\S*)\s*→(?:\s+\S*)\s+(SCCP\s\(Int\.\sITU\))\s+\d+\s+.*”, and for the protocol name “5co-xx”: Design a dedicated regular expression “^\s*\d+\s+[0-9.\-]+(?:\s+\ S*)\s*→(?:\s+\S*)\s+(5co-\S*)\s+\d+\s+.*”, for the protocol name “?KNXnet / IP”: design a special regular expression “^\s*\d+\s+[0-9.\-]+(?:\s+\S*)\s*→(?:\s+\S*)\s+(\?\s+KNXnet / IP)\s+\d+\s+.*”; 3.3.1.3 Perform protocol name normalization: Replace protocol names belonging to the same category (e.g., unify "ECAT" series protocols to "ECAT", "DNPv127" to "DNP3", etc.). The protocol names that need to be unified include "ECAT", "TCP", "UDP", "MMS", "DNPv127", "WLCCP", "VMWARE-HB", "ALLJOYN-NS", "FIND", "HTTP", "iPerf3", "Netsync", "IPDC", and "TPM" to eliminate statistical errors caused by differences in protocol names; 3.3.1.4 Classification based on prior industrial control protocol knowledge base: The statistical protocol names are compared with the list of industrial control protocols in the knowledge base. Protocols that are not excluded are determined to be industrial control protocols. Non-industrial control protocols such as TCP and UDP are eliminated to focus on the core analysis target. 3.3.1.5 Mixed Packet Identification and Statistics: If two or more industrial control protocol categories are identified for a single data packet, it is determined to be a "mixed packet"; finally, the total number of all protocol categories, the number of industrial control protocol categories, and the number of mixed packets in a single database are summarized and counted.

[0036] In this embodiment, a single database is used to count the number of all protocol types, the number of industrial control protocol types, and the number of mixed packets. The output format is as follows: { Processing folder: D:\Documents\github\ICS\2_PCAPS(4SICS ICS) Folder: 2_PCAPS(4SICS ICS) Total number of protocol types: 43 Number of industrial control protocol types after filtering: 3 Protocol after screening: Protocol: S7COMM, Quantity: 326669 Protocol: ENIP, Quantity: 5 Protocol: DNP 3.0, Quantity: 38 There is one mixed package file }; 3.3.2 Indirect Method: Protocol Layer Parsing + Top Layer Extraction (Solving the Problem of Ineffective Identification of Unknown Protocols) By utilizing Wireshark's protocol hierarchical statistics function, core protocols can be extracted through hierarchical analysis, thus overcoming the shortcomings of the direct method in identifying unknown protocols. The specific steps are as follows: 3.3.2.1 Traverse the valid data packets in the ICS traffic database and obtain protocol classification statistics using the tshark command (command format: tshark -r data packet path -z io,phs); 3.3.2.2 Filter the valid statistics between two identical lines ("========================================="), which are indented to show the protocol hierarchy (e.g., eth→ip→tcp→enip→cip). The data format for "protocol hierarchical statistics" is as follows: “ ========================================= (Congruent lines) Protocol Hierarchy Statistics Filter: eth frame:xx bytes:xx llc frame:xx bytes:xx stp frame:xx bytes:xx IP frame:xx byete:xx TCP frame:xx bytes:xx enip frame:xx bytes:xx cip frame:xx bytes:xx cipcm frame:xx bytes:xx cipcls frame:xx bytes:xx lldp frame:xx bytes:xx ========================================== (Congruent lines) ”; 3.3.2.3 Design an indentation analysis algorithm: Determine the level by counting the number of spaces before the protocol name in each data line. Increasing indentation represents a higher level, while decreasing indentation represents switching to a different upper-level protocol. Filter and count the highest-level protocols (i.e., the core protocols closest to the application layer) and their corresponding quantities in the same category to ensure that no core industrial control protocols in nested protocols are missed. 3.3.2.4 A priori industrial control protocol knowledge base, consistent with the direct method, is used for category differentiation to ensure the uniformity of protocol classification standards; 3.3.2.5 Mixed Packet Identification and Statistics: Consistent with the direct method logic, determine the mixed packet attributes of a single data packet, and summarize and count the number of protocol categories, industrial control protocol categories, and mixed packets at the database level.

[0037] In this embodiment, a single database is used to count the number of all protocol types, the number of industrial control protocol types, and the number of mixed packets. The output format is as follows: { Processing folder: D:\Documents\github\ICS\3_ICS-pcap(automayt) Folder: 3_ICS-pcap(automayt) Total number of agreement types: 74 Number of industrial control protocol types after filtering: 18 Protocol: s7comm, Quantity: 63794 Protocol: Modbus, Quantity: 227 Protocol: opensafety, Quantity: 3 Protocol: enip, Quantity: 149 Protocol: dnp3, Quantity: 245 Protocol: ...dnp3, Quantity: 219 Protocol: bacapp, Quantity: 6072 Protocol: CIP, Quantity: 1701 Protocol: cipcls, Quantity: 42484 Protocol: cipcm, Quantity: 2177 Protocol: ecat.subframe.pad_bytes, Quantity: 2 Protocol: pn_dcp, Quantity: 14 Protocol: esio, Quantity: 2779 Protocol: hart_ip, Quantity: 49 Protocol: iec60870_asdu, Quantity: 4 Protocol: ...iec60870_104, Quantity: 8 Protocol: ...iec60870_asdu, Quantity: 8 Protocol: epl, Quantity: 1001 }; 3.3.3 Fusion of Dual-Mode Results Cross-validation of the statistical results of the direct and indirect methods: If the industrial control protocol categories counted by the two methods are consistent, the results are output directly; if there are differences, priority is determined based on the prior industrial control protocol knowledge base and the application scenario of the data packets (e.g., in industrial control scenarios, the highest-level protocol extracted by the indirect method has a higher priority than the surface protocol matching results of the direct method) to ensure the accuracy of the final statistical results.

[0038] Corresponding to the aforementioned embodiment of an automated defect analysis and protocol statistics method for ICS traffic databases, the present invention also provides an embodiment of an automated defect analysis and protocol statistics device for ICS traffic databases.

[0039] See Figure 4 The present invention provides an automated defect analysis and protocol statistics device for an ICS traffic database, comprising a memory and one or more processors. The memory stores executable code, and when the processor executes the executable code, it implements an automated defect analysis and protocol statistics method for an ICS traffic database as described in the above embodiment.

[0040] The embodiment of the automated defect analysis and protocol statistics device for ICS traffic database provided by this invention can be applied to any device with data processing capabilities, such as a computer. The device embodiment can be implemented through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of any data processing device loading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 4 The diagram shown is a hardware structure diagram of any device with data processing capabilities, which is used for automated defect analysis and protocol statistics of ICS traffic databases provided by this invention. (Except for...) Figure 4 In addition to the processor, memory, network interface, and non-volatile memory shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0041] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0042] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0043] This invention also provides a computer-readable storage medium storing a program that, when executed by a processor, implements an automated defect analysis and protocol statistics method for an ICS traffic database as described in the above embodiments.

[0044] The computer-readable storage medium can be an internal storage unit of any data processing device described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device of any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of any data processing device. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0045] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the aforementioned automated defect analysis and protocol statistics method for ICS traffic databases.

[0046] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0047] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. This application is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. An automated defect analysis and protocol statistics method for ICS traffic databases, characterized in that, The method includes: A database of industrial control system flow was collected based on open resources and literature review citations. Perform multi-level verification decompression on data packets of the industrial control system flow database; extract and count the file extension strings of all data packet files, and output the file format uniformity status; batch call the tshark command to read data packets and capture error information, and separate intact data packets from damaged data packets; The direct method of industrial control protocol identification is adopted, which combines regularity optimization and protocol normalization statistical collaboration; the indirect method of industrial control protocol identification is adopted, which combines protocol hierarchy parsing and highest-level extraction collaboration; the statistical results of the direct and indirect methods are cross-validated to obtain the final statistical results.

2. The automated defect analysis and protocol statistics method for ICS traffic database according to claim 1, characterized in that, The collection of industrial control system traffic databases based on open resources and paper reviews specifically includes: taking GitHub open resources as the core source, starting with the ICS-pcap traffic database compiled by The Information Trust Institution, and expanding the collection based on citation information to form three core databases: original databases that rely on their own laboratory data collection and public release, ICS traffic index pages that rely on existing open source databases, and public online databases that rely on public sharing and maintenance, thus realizing the systematic integration of open source resources; Using literature reviews as supplementary sources and Mauro Conti's research on industrial control systems as a reference, we collected and summarized laboratory papers related to logic programmable controllers, and extracted and standardized the publicly available experimental data from these papers.

3. The automated defect analysis and protocol statistics method for ICS traffic databases according to claim 1, characterized in that, The multi-level verification-based decompression of data packets in the industrial control system flow database specifically includes: A recursive traversal algorithm is used to decompress all ZIP files in the ICS traffic database and its subdirectories one by one. Compatibility files generated during decompression are identified and deleted simultaneously to avoid redundant files interfering with subsequent analysis. After decompression, a path scanning mechanism is used to uniformly check the number of residual ZIP files in all ICS traffic databases. If the number of residual files is 0, the check is considered passed and the process proceeds to the next step. If residual files exist, the decompression process of the corresponding directory is re-executed to achieve 100% verification of decompression integrity.

4. The automated defect analysis and protocol statistics method for ICS traffic databases according to claim 1, characterized in that, The step of extracting and statistically analyzing the file extension strings of all data packet files specifically includes: A batch path retrieval algorithm is used to traverse all data packet files in the target ICS traffic database and extract the file extension string of each file. Construct a file extension statistics dictionary to automatically count the number of data packets with different file extensions; If the statistical results show that the database contains only one type of file extension, it is determined that the file format is uniform; if there are two or more types, the distribution of the number of each type of file extension will be output.

5. The automated defect analysis and protocol statistics method for ICS traffic database according to claim 1, characterized in that, The process of batch calling tshark commands to read data packets and capture error information specifically includes: Iterate through all data packets with the suffixes .cap, .pcap, and .pcapng in the ICS traffic database, and use Python's subprocess module to call the tshark command in batches to attempt to read the data packets; Capture standard error output during tshark execution, matching error messages for truncated corruption, format incompatibility corruption, and general corruption; If any of the above error messages are captured, the data packet is determined to be a corrupted data packet, its path is automatically recorded and moved to a separate corrupted file directory, thus achieving automatic separation of intact data packets from corrupted data packets.

6. The automated defect analysis and protocol statistics method for ICS traffic database according to claim 1, characterized in that, The direct method for industrial control protocol identification using regularization optimization and protocol normalization statistical coordination specifically includes: Traverse the valid data packets in the ICS traffic database and read the protocol field of each data row using the tshark command; Use general regular expressions to filter common protocol names, and then design specific matching rules for special protocol names; The protocol names belonging to the same category are uniformly replaced. The statistical protocol names are compared with the list of industrial control protocols in the knowledge base. Protocols that are not excluded are determined to be industrial control protocols, and non-industrial control protocols are removed. For a single data packet, if two or more industrial control protocol categories are statistically identified, it is determined to be a mixed packet. Finally, the total number of all protocol categories, the number of industrial control protocol categories, and the number of mixed packets in a single database are summarized.

7. The automated defect analysis and protocol statistics method for ICS traffic database according to claim 1, characterized in that, The indirect method of using protocol hierarchy parsing and top-level extraction in combination for industrial control protocol identification includes: traversing the valid data packets in the ICS traffic database, obtaining protocol hierarchy statistics through the tshark command, and filtering valid statistics between two identical lines. This data reflects the protocol hierarchy relationship in an indented format. The hierarchy is determined by counting the number of spaces before the protocol name in each data line. Increasing indentation indicates a higher level, while decreasing indentation indicates switching to a different higher-level protocol. The highest-level protocols and their corresponding quantities within the same category are then filtered and counted. The statistically analyzed protocol names are compared with the list of industrial control protocols in the knowledge base. Protocols that are not excluded are identified as industrial control protocols, while non-industrial control protocols are removed. For a single data packet, if two or more industrial control protocol categories are identified, it is identified as a mixed packet. Finally, the total number of all protocol categories, industrial control protocol categories, and mixed packets in a single database are summarized.

8. The automated defect analysis and protocol statistics method for ICS traffic database according to claim 1, characterized in that, The cross-validation of the statistical results of the direct and indirect methods includes: cross-validating the statistical results of the direct and indirect methods: if the industrial control protocol categories counted by the two methods are consistent, the results are output directly; if there are differences, priority is determined based on the prior industrial control protocol knowledge base and the application scenario of the data packet.

9. An automated defect analysis and protocol statistics device for ICS traffic databases, comprising a memory and one or more processors, wherein the memory stores executable code, characterized in that, When the processor executes the executable code, it implements an automated defect analysis and protocol statistics method for an ICS traffic database as described in any one of claims 1-8.

10. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements an automated defect analysis and protocol statistics method for an ICS traffic database as described in any one of claims 1-8.

Images