Asset identification method, equipment and medium

Abstract

The invention relates to an asset identification method and device and a medium, and the method comprises the steps: collecting network traffic, uploading the network traffic to a field-level platform, analyzing the traffic, and extracting the IP, protocol type and protocol feature of a survival port; matching candidate protocols based on a port-protocol mapping table and a protocol feature library, and screening protocol priorities in combination with an equipment communication relationship and service attributes in an asset information library; sending a screening result to a lightweight detection engine, and generating a feature instruction set according to an industrial control protocol fingerprint database; counting public and unique service sets of associated equipment for each target IP, and preferentially sending a protocol instruction to a public port; and if the response is matched with the fingerprint database, a customization request instruction is sent to the unique service port, and the asset manufacturer and the model are determined through the response data. According to the method, through an active and passive cooperation mechanism, an active detection sequence is optimized on the basis of passive analysis, invalid protocol attempts are reduced, the performance impact of traditional scanning on an industrial system is avoided, and the recognition precision and efficiency are improved.

Description

Technical Field

[0001] The present invention relates to the field of industrial control system network security, and particularly to an asset identification method, device and medium. Background Art

[0002] With the in-depth digital transformation of the energy industry, the information security of industrial networks such as power production control areas faces severe challenges. The core foundation of network security supervision lies in "asset inventory", that is, accurately identifying the model, software version and service information of assets in the network to support subsequent vulnerability detection and risk prevention and control. However, the network environment of energy stations (such as power plants and substations) has characteristics such as high closure and strong device vulnerability, and traditional asset identification technologies face significant limitations in such scenarios.

[0003] Currently, industrial network asset identification mainly relies on active detection technologies, such as IP-based port scanning and service protocol interaction. However, such technologies need to guess the TCP / UDP port alive state of the target device and verify the service type through multiple protocol access attempts. In industrial control systems, frequent active detection may cause the following problems:

[0004] 1. Performance consumption and system risks: Industrial control devices (such as PLCs, RTUs) have low fault tolerance for unexpected protocol requests, and active detection may lead to device resource exhaustion, logical errors or even system downtime, threatening production continuity;

[0005] 2. Closed environment restrictions: The power production control area is usually physically isolated from the external network and has a high degree of protocol privatization. General scanning tools are difficult to adapt, and active detection is inefficient;

[0006] 3. Lack of asset dynamics: Industrial network devices usually run stably for a long time, and traditional scanning cannot capture the device state changes in real time, resulting in lagging asset library information.

[0007] At the same time, the solution that simply relies on passive traffic analysis also has defects. Although passive technologies can obtain asset communication behaviors (such as IP, port, protocol characteristics) through traffic mirroring, their identification granularity is relatively coarse, and it is difficult to accurately determine key attributes such as device models and manufacturers. Especially for industrial devices using non-standard ports or customized protocols, the misjudgment rate is relatively high.

[0008] In the prior art, some solutions attempt to combine active and passive detection methods, but still fail to effectively solve the following problems:

[0009] Detection redundancy: Active detection lacks pertinence, and the protocol attempt order is not optimized, resulting in a large number of invalid detection times and long duration;

[0010] Insufficient adaptability of the feature library: The protocols of industrial control devices are diverse and have significant privatization characteristics. It is difficult for a general protocol fingerprint library to cover the interaction logic of devices unique to the energy industry (such as collectors and plant-level platforms).

[0011] Lack of business relevance: The connection relationship between devices (such as the fixed connection between collectors and plant-level platforms) is not fully utilized to narrow the detection range, resulting in waste of resources. Summary of the Invention

[0012] The present invention provides an asset identification method, device, and medium, aiming to solve the problems of inaccurate asset identification and low efficiency caused by the restricted closed network environment and the risks of traditional active detection technologies in energy stations.

[0013] To achieve the above objective, in the first aspect of the present invention, an asset identification method is provided, including the following steps:

[0014] Collect communication traffic from the network core switch mirror and transmit the communication traffic to the field-level platform;

[0015] The field-level platform analyzes the communication traffic and extracts the IP addresses, protocol types, and service behavior characteristics of the surviving service ports;

[0016] Based on a pre-set port-protocol mapping table and protocol feature library, match the candidate protocols and service types corresponding to the surviving service ports;

[0017] According to the device connection relationship and service attributes associated with the IP address in the asset information library, screen the priority sequence of the candidate protocols and service types;

[0018] Send the IP addresses of the surviving service ports, the screened candidate protocols, and the service type priority sequence to the lightweight detection engine;

[0019] The lightweight detection engine generates a protocol feature instruction set corresponding to the candidate protocol and service type priority sequence according to the industrial control device protocol fingerprint knowledge base;

[0020] For each target IP address in the candidate protocol and service type priority sequence, count the public service set and unique service set of its associated devices;

[0021] For the service ports in the public service set of the target IP address, send the matching instructions in the protocol feature instruction set in priority order;

[0022] If the protocol feature instruction response of the public service port matches the industrial control device protocol fingerprint knowledge base, send a customized protocol request instruction to the service ports in the unique service set;

[0023] Determine the manufacturer and model information of the assets corresponding to the target IP address according to the matching result between the response data of the customized protocol request instruction and the protocol fingerprint knowledge base.

[0024] Further, the communication traffic is obtained through a traffic mirror collector deployed on the core switch. The collector is configured with a hardware-accelerated traffic filtering module to intercept network packets containing TCP / UDP protocol headers in real time and forward them to the field-level platform.

[0025] Further, the method for screening the priority sequence of the candidate protocols and service types includes:

[0026] Query the device record corresponding to the IP address in the pre-set asset information database;

[0027] If the device record exists, extract the priority information of the associated devices and the supported range of candidate protocols according to the device connection relationship and service attributes in the device record, and generate a priority sequence;

[0028] If the device record does not exist, extract the peer IP address that has a session with the IP address from the communication traffic, and query the device type and connection relationship of the peer IP address in the asset information database;

[0029] Based on the device type and connection priority associated with the peer IP address, infer the potential device type of the IP address, and match the protocols and service types supported by the potential device type in the asset information database;

[0030] According to the matching result, combined with the default priority rules in the protocol feature library, dynamically adjust the priority sequence of the candidate protocols and service types.

[0031] Further, the method for generating the protocol feature instruction set includes:

[0032] Extract the corresponding protocol interaction templates from the industrial control device protocol fingerprint knowledge base according to the priority sequence of the candidate protocols and service types;

[0033] Based on the historical detection hit probability, optimize the execution order of the protocol interaction templates, and preferentially select protocol instructions with a hit rate higher than the preset threshold.

[0034] Further, the method for counting the common service set and the unique service set includes:

[0035] Traverse the associated device list of the target IP address, and extract the set of service ports supported by each device;

[0036] Perform an intersection operation on the set of service ports to obtain the common service set;

[0037] For the remaining service ports that are not in the intersection, generate a unique service set by sorting them according to the device communication priority.

[0038] Furthermore, the method for determining the priority order includes:

[0039] If the protocol type of the common service port matches the historical record of the target device manufacturer, then raise its priority to the highest level;

[0040] If there are multiple common service ports, then sort them according to the importance weights of the industrial control protocols preset in the protocol fingerprint knowledge base.

[0041] Furthermore, the method for generating the customized protocol request instruction includes:

[0042] Extract the private protocol instruction template of the target manufacturer's device from the protocol fingerprint knowledge base;

[0043] Based on the protocol interaction historical record of the target IP address, fill in the variable parameters in the private protocol instruction template.

[0044] Furthermore, the determination logic of the matching result includes:

[0045] If the response data contains the identification field unique to the target manufacturer's device, then directly determine that the match is successful;

[0046] If the response data does not contain the identification field, then calculate its similarity with the feature code in the protocol fingerprint knowledge base. If the similarity exceeds the preset threshold, then determine it as a fuzzy match.

[0047] To achieve the above object, a second aspect of the present invention provides an electronic device, including a memory and a processor. The memory is used to store a program that supports the processor to execute the asset identification method, and the processor is configured to execute the program stored in the memory.

[0048] To achieve the above object, a third aspect of the present invention provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, it executes the steps of the asset identification method.

[0049] Advantages of the present invention:

[0050] Compared with the prior art, an asset identification method, device and medium provided by the present invention effectively solve the problems of high risk in active detection and low accuracy in passive analysis in traditional industrial network asset identification through the active and passive collaborative detection mechanism and multi-dimensional service logic optimization. Specifically: initially obtain the asset survival ports and protocol characteristics through passive analysis of mirrored traffic, dynamically generate a priority detection sequence in combination with the port-protocol mapping table, device connection relationship and service attributes, greatly reduce the blindness of active detection, avoid redundant protocol attempts on vulnerable industrial devices, and reduce the risk of system downtime; generate a customized instruction set based on the industrial control device protocol fingerprint knowledge base, preferentially verify the public service ports and dynamically trigger unique service detection according to the response results, which not only adapts to the privatized protocol characteristics (such as the instructions of special collectors in the power industry), but also improves the accuracy of manufacturer model identification through the deep matching of protocol characteristic instructions and the fingerprint library; utilize the device connection relationship (such as the fixed connection between the collector and the plant-level platform) and service attributes in the asset information library to construct a priority screening model based on the service scenario, significantly narrow the detection range and improve the protocol hit rate. Through the above technical integration, the present invention realizes low invasiveness, high accuracy and strong service adaptability of asset identification in a closed industrial network environment, providing a reliable basic support for the network security protection of energy stations. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for description in the embodiments.

[0052] Figure 1 It is an operation mechanism diagram of an asset identification method disclosed in an embodiment of the present invention.

[0053] Figure 2 It is a traffic identification process diagram disclosed in an embodiment of the present invention.

[0054] Figure 3 It is a lightweight detection engine identification flow chart disclosed in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0055] In order to enable those skilled in the art to better understand the solution of the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0056] According to an embodiment of the present invention, it should be noted that the steps shown in the flowchart of the drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the following manufacturing method, in some cases, the steps shown or described can be executed in a different order than here.

[0057] As Figure 1 shown, the present invention provides an asset identification method, including the following steps:

[0058] Step S100: Mirror and collect communication traffic from the network core switch, and transmit the communication traffic to the field-level platform;

[0059] The network core switch is the core communication device connecting each node of the industrial control network. Its mirror collection function can copy the data packets passing through the switch to a specified port through port mirroring technology. "Communication traffic" refers to the set of original data packets transmitted in the network, including key behavioral characteristics such as protocol messages and session information for device interaction. In this step, a traffic collector deployed on the core switch is used to obtain the full network traffic in a non-intrusive manner by mirroring, avoiding interference with vulnerable industrial control devices by traditional scanning. The field-level platform is a centralized analysis system deployed on the energy field side, with protocol parsing and asset reasoning capabilities. Transmitting the mirrored traffic to the field-level platform not only meets the requirement of keeping data within the closed network environment without leaving the field, but also enables in-depth analysis using its computing resources. For example, a certain photovoltaic power station configures the SPAN port of the switch to mirror the traffic to the collector hardware device, and after preprocessing, uploads it to the Kafka message queue of the field-level platform for real-time parsing.

[0060] Step S200: The field-level platform parses the communication traffic and extracts the IP addresses, protocol types, and service behavioral characteristics of the surviving service ports;

[0061] A surviving service port refers to a TCP / UDP port with an active session within a certain time window. For example, if it is detected that the 502 port of a certain IP periodically transmits Modbus / TCP protocol messages, it is determined as a surviving service port. Protocol type identification is based on a preset protocol feature library, and service behavioral characteristics are realized by analyzing metadata such as session frequency and payload length. For example, when a handshake message is captured in the traffic, the platform will extract the client / server version identification field and match it with the collectors and plant-level platform devices recorded in the asset information database. Combining the device communication priority (such as a higher communication probability between the collector and the plant-level platform), a candidate set of the most likely service types is dynamically screened, providing accurate input for subsequent active detection.

[0062] Step S300: Based on the preset port-protocol mapping table and protocol feature library, match the candidate protocols and service types corresponding to the surviving service ports;

[0063] Protocol recognition is a technology that determines the protocol type of network traffic by analyzing the packet characteristics in the traffic; in this step, a protocol recognition mechanism is adopted, combining dual verification of port mapping and feature matching: First, a preliminary candidate protocol list is generated based on the port-protocol mapping table (e.g., port 80 is associated with the HTTP protocol, port 502 is associated with the Modbus TCP protocol); then, the feature codes in the traffic payload are matched through the protocol feature library (e.g., the "GET / POST" request header in the HTTP protocol, the function code structure of the Modbus protocol), further verifying the protocol type. In particular, in the industrial control network scenario, this method combines the pre-set asset information library (such as known collector devices only support the MySQL service) to optimize the priority of candidate protocols. For example, when the traffic on port 3306 matches the characteristics of both MySQL and private industrial control protocols, the protocol type supported by the associated devices in the asset information library is preferentially selected, thus reducing the redundant detection caused by protocol guessing in traditional methods. This dynamic screening mechanism that integrates context information significantly improves the accuracy and efficiency of protocol recognition in a closed environment.

[0064] Step S400: According to the device connection relationship and service attributes associated with the IP address in the asset information library, screen the priority sequence of the candidate protocols and service types;

[0065] The field-level platform deeply analyzes the received communication traffic. First, it extracts the IP address, port number, and protocol characteristics of the surviving TCP / UDP service ports (such as the MySQL handshake packet for port 3306, the Modbus function code for port 502). Through the pre-set port-protocol mapping table (such as 3306 → MySQL, 80 → HTTP) and protocol feature library (such as the "GET / POST" request header of HTTP), the possible protocols and service types are initially analyzed. For example, when a session accessing port 3306 is detected in the energy industrial control network, the system preferentially generates a candidate list from the device types that support MySQL (such as collectors, field-level platforms), rather than traversing all possible service types.

[0066] If the target IP address already has a record in the asset information library (such as marked as "collector"), then a priority sequence is generated according to the confidence level of its connection relationship. For example, the connection relationship of the collector in the asset information library is:

[0067] 1. Field-level platform (confidence level 20%);

[0068] 2. Log audit device (confidence level 15%);

[0069] 3. Network isolation device (confidence level 10%).

[0070] At this time, protocols and service types related to the plant-level platform (such as MySQL and Web services) will be preferentially screened, and a candidate protocol list will be generated based on the protocol scope supported by the plant-level platform (MySQL, OceanBase, etc.), while service types not supported by the collector will be excluded.

[0071] If the target IP is not registered in the asset information database, reverse inference is performed by analyzing the peer IP in its communication session. For example: when the peer IP of the traffic on port 3306 of a certain IP address is a known collector, the system infers that the target IP may be a plant-level platform device based on the communication relationship of the collector (preferably connecting to the plant-level platform), and then preferentially matches the protocols supported by the plant-level platform. Specifically: query the asset record of the peer IP and find that it belongs to the "plant-level platform" and its communication relationship includes the "collector"; combined with the business attributes of the plant-level platform (such as supporting MySQL and OceanBase services), infer that the target IP may be the collector device communicating with it; according to the protocol support scope (MySQL, Web services) and port configuration (such as ports 3306 and 80) of the collector, generate a priority sequence and preferentially match the MySQL protocol characteristics (rather than the unique services of the plant-level platform such as OceanBase), thus avoiding ineffective detection.

[0072] In the candidate protocol screening, weighted calculations are performed by combining the default rules of the protocol feature library (such as the priority of industrial control protocols is higher than that of general IT protocols) with the device business scenario. For example: if the port 3306 of the target IP matches both the MySQL and private database protocol characteristics, but the associated device type is inferred to be a collector (only supporting MySQL), then the priority of the MySQL protocol is raised to the highest; if the peer IP is a network isolation device (confidence level 10%), the priority of its associated service (such as a specific encrypted tunnel protocol) will be reduced, and the protocols supported by devices with high confidence levels (such as the plant-level platform) will be preferentially matched.

[0073] Through the above mechanism, step S400 effectively utilizes the logical association and business constraints between devices to transform the traditional coarse-grained matching based on ports into refined protocol screening for business scenarios, significantly improving the efficiency and security of subsequent active detection.

[0074] Step S500: Send the IP address of the surviving service port, the screened candidate protocols, and the service type priority sequence to the lightweight detection engine;

[0075] The lightweight detection engine is a low-intrusive and resource-optimized active detection module. By only initiating minimized detection instructions for high-priority protocols and service types (such as only sending key feature verification requests instead of full-scale protocol interactions), the lightweight detection engine significantly reduces the performance impact on industrial control devices. Different from the full-port detection of traditional active scanning tools, this engine only initiates customized requests for high-probability services in the candidate protocol priority sequence. For example, when the target IP address is inferred to be likely a plant-level platform, the engine only sequentially sends necessary interactions such as MySQL protocol version query instructions and PostgreSQL handshake packets, rather than traversing all possible industrial control protocol instructions. This on-demand detection mechanism significantly reduces the number of protocol attempts and avoids the protocol impact on industrial control devices caused by traditional scanning.

[0076] Step S600: The lightweight detection engine generates a protocol feature instruction set corresponding to the candidate protocol and service type priority sequence according to the industrial control device protocol fingerprint knowledge base;

[0077] The lightweight detection engine extracts the corresponding protocol interaction templates from the industrial control device protocol fingerprint knowledge base according to the candidate protocol priority sequence and generates a protocol feature instruction set. This instruction set consists of a set of refined detection instructions based on protocol feature codes. To improve the detection efficiency, the engine dynamically optimizes the instruction execution order based on the historical detection hit probability, preferentially executing the instructions with a historical matching success rate higher than the preset threshold, and demoting the instructions with a low hit rate.

[0078] In addition, the protocol feature instruction set supports dynamic update: when unknown protocol features are detected, the engine will collect the complete interaction message and send it back to the field-level platform, which will be updated to the fingerprint library after parsing. For example, a newly added inverter device in a certain photovoltaic power station uses a private protocol encrypted by AES. The engine generates a new protocol instruction template by recording the fixed byte sequence in its handshake stage and associating with the manufacturer information for subsequent detection to directly call.

[0079] Step S700: For each target IP address in the candidate protocol and service type priority sequence, count the public service set and unique service set of its associated devices;

[0080] In this step, by traversing the list of devices associated with the target IP address in the asset information database (for example, there is a communication relationship between a certain IP address and a collector and a plant-level platform), the set of service ports supported by each device is extracted, and the intersection operation is performed on these port sets to obtain the common service set. The remaining non-intersection ports are used to generate a unique service set according to the device communication priority (the collector has no unique ports, and the 5432 port of the plant-level platform). For example, when the target IP address is inferred to possibly belong to the plant-level platform, its associated devices include a collector and a log audit device. First, the service ports of the collector and the plant-level platform are extracted, and the intersection is calculated to obtain the common service. Then, the unique services are sorted according to the communication priority: the 5432 (PostgreSQL service) of the plant-level platform takes precedence over the 514 (Syslog service) of the log audit device. This service classification mechanism based on the business topology relationship enables subsequent detection to preferentially verify high-confidence services (such as PostgreSQL of the plant-level platform) rather than blindly traversing all possible ports, thus achieving efficient asset identification in a closed network.

[0081] Step S800: Send the matching instructions in the protocol feature instruction set to the service ports in the common service set of the target IP address in the order of priority.

[0082] If the protocol type of the common service port matches the historical record of the target device manufacturer, directly raise the detection priority of this port to the highest, and preferentially send the MySQL version query instruction. Secondly, when there are multiple common service ports and there is no historical match record, sort them according to the preset industrial control protocol importance weight in the protocol fingerprint knowledge base, and preferentially detect the high-weight ports. For example, in the scenario of a thermal power plant, the common service set of a certain target IP address contains port 502 (Modbus TCP) and port 80 (HTTP). According to the industrial control protocol importance rule, first send the Modbus function code instruction to port 502. After confirming that it is a PLC device, then send the HTTP request header detection instruction to port 80. This hierarchical detection strategy not only avoids redundant detection of non-critical ports but also significantly reduces the risk of industrial control system performance fluctuations caused by protocol floods.

[0083] Step S900: If the protocol feature instruction response of the common service port matches the industrial control device protocol fingerprint knowledge base, send a customized protocol request instruction to the service ports in the unique service set.

[0084] This step achieves precise identification by extracting the private protocol features of the target manufacturer's devices: after the public service port verification passes, the lightweight detection engine retrieves the private protocol instruction template of the target manufacturer from the protocol fingerprint knowledge base, and fills the variable parameters in the instruction template based on the historical interaction records of the target IP address (such as the timestamp of industrial control instructions periodically sent, session ID). For example, when the 3306 port of a certain IP address is confirmed as the exclusive MySQL service of Huadian, the engine sends a customized instruction to the unique service port 5432 of this IP: based on the private protocol features of Huadian devices, construct an extended query instruction containing the manufacturer identifier. If the response data contains a feature code, it is directly determined as the Huadian plant-level platform. This instruction construction mechanism based on the manufacturer's private protocol logic effectively solves the misjudgment caused by protocol compatibility problems in traditional methods.

[0085] Step S1100: Determine the manufacturer and model information of the asset corresponding to the target IP address according to the matching result between the response data of the customized protocol request instruction and the protocol fingerprint knowledge base.

[0086] This step adopts a hierarchical determination logic to achieve the integration of precise and fuzzy matching: First, if the response data contains the identification field unique to the target manufacturer's device, it is directly determined that the asset manufacturer and model match successfully; if no clear identification is detected, the matching degree between the response data and the feature code in the protocol fingerprint knowledge base is calculated through a similarity algorithm, and when the similarity exceeds the preset threshold, it is determined as a fuzzy match. This determination mechanism takes into account the diversity and closure characteristics of industrial control protocols, while ensuring high accuracy, covers the identification scenarios of non-standard devices through fuzzy matching, and automatically feeds the suspected results back to the field-level platform for manual review, forming a dynamically optimized asset information closed-loop.

[0087] Preferably, the communication traffic is obtained through a traffic mirroring collector deployed on the core switch, and the collector is configured with a hardware-accelerated traffic filtering module to intercept network data packets containing TCP / UDP protocol headers in real time and forward them to the field-level platform.

[0088] In this embodiment, steps S100 - S400 are the traffic identification process, as Figure 2As shown, the recognition flow chart demonstrates the technical process of asset recognition combining passive and active methods, which is specifically described as follows: Starting from "traffic capture" (collecting network communication data through mirroring), followed by "preliminary identification of IP, port, and service information" (analyzing traffic to extract the characteristics of live ports and protocols); then, through "judging whether the peer IP is an identified device from the asset information database", if the match is successful, the target protocol range is narrowed based on the connection device information of the peer IP (such as the collector associated with the plant-level platform), and if the match fails, all possible device types corresponding to the local port services are counted; the process dynamically calls the device connection relationship and protocol support list through the "asset information database", and finally, the filtered candidate information is input into the "lightweight detection engine" for accurate protocol verification until the process ends. In the figure, by distinguishing functional modules (passive recognition, logical judgment, data support), the hierarchical progressive logic from traffic analysis to protocol detection is intuitively reflected, which conforms to the idea of "passive first and then active, and optimizing detection based on association", aiming to achieve accurate asset identification in a closed network with minimal active interference.

[0089] In this embodiment, steps S500 - S1100 are the recognition process of the lightweight detection engine, as Figure 3 shown, this flow chart shows its core logic: Extract the common service set (such as MySQL on port 3306) and the unique service set (such as PostgreSQL on port 5432 of the plant-level platform) from the asset information database, and give priority to initiating protocol detection for common services; if the detection is successful (such as the MySQL version query response matching the fingerprint database), then send customized protocol requests for unique services, and finally backfill the asset information database through response matching; if the detection of common services fails (such as protocol feature mismatch), then terminate the process to avoid ineffective scanning.

[0090] "Asset inventory" is an important foundation for network security supervision. Before conducting network vulnerability detection, it is necessary to accurately identify the model and software version of the target assets. However, most power generation (plant) stations lack technical means for network asset management. Since networks such as the power production control area are in a closed environment and are relatively vulnerable, there is a lack of technical means for asset collection at the plant site. This method uses the asset recognition technology combining passive and active methods. After discovering asset network behavior information through traffic, it effectively identifies assets based on an accurate feature library combined with lightweight active detection recognition technology, thus solving the problems of asset discovery and recognition in energy plants.

[0091] It should be noted that passive detection refers to the real-time capture and analysis of network communication traffic through mirror traffic monitoring and protocol parsing technologies, without sending any detection packets to the target device. Specifically, it involves collecting the original communication traffic from the core switch through mirroring, parsing the IP addresses, port numbers, protocol types, and session behavior characteristics in the traffic, and inferring the basic attributes and potential service types of the surviving assets based on the pre-set port-protocol mapping table and device connection relationships. Its core feature is non-invasiveness, relying entirely on data mining of existing network communication behaviors to avoid imposing additional loads or protocol interferences on vulnerable industrial control networks.

[0092] Active detection, on the other hand, refers to the precise verification of the target device through lightweight protocol interactions after the scope is narrowed down by passive analysis. Specifically, it includes generating a characteristic instruction set based on the industrial control protocol fingerprint library, sending customized protocol requests to the public service ports of the target IP according to the priority, and confirming the device model and manufacturer information based on the matching results between the response data and the fingerprint library. The inventive point lies in the adoption of the "probability-optimized detection order" and "customized protocol instruction" technologies, only initiating minimal interactions for high-confidence candidate protocols, and improving the recognition accuracy by differentiating the detection of unique service sets (such as device manufacturer private protocol instructions), significantly reducing the number of protocol attempts and system risks of traditional active scans. The combination of the two achieves a closed-loop of interference-free discovery + precise verification, overcoming the contradiction between the security and effectiveness of asset identification in closed industrial networks.

[0093] According to another aspect of the embodiments of the present application, an electronic device is further provided, including a processor and a memory. The processor is used to implement the steps of the method when executing the computer program stored in the memory.

[0094] In the above embodiments of the present invention, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0095] In the several embodiments provided by the present application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only illustrative. For example, the division of the units can be a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the units or modules can be in an electrical or other form.

[0096] In addition, in each embodiment of the present invention, the functional units can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0097] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs that can store program codes.

[0098] The above are only the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. An asset identification method, characterized in that, It includes the following steps: Collect communication traffic from the network core switch mirror and transmit the communication traffic to the field-level platform; The field-level platform analyzes the communication traffic and extracts the IP addresses, protocol types, and service behavior characteristics of the surviving service ports; Based on the preset port-protocol mapping table and protocol feature library, match the candidate protocols and service types corresponding to the surviving service ports; According to the device connection relationship and service attributes associated with the IP address in the asset information database, filter the priority sequence of the candidate protocols and service types; Send the IP addresses of the surviving service ports, the filtered candidate protocols, and the service type priority sequence to the lightweight detection engine; The lightweight detection engine generates a protocol feature instruction set corresponding to the candidate protocol and service type priority sequence according to the industrial control device protocol fingerprint knowledge base; For each target IP address in the candidate protocol and service type priority sequence, count the public service set and unique service set of its associated devices; Send the matching instructions in the protocol feature instruction set to the service ports in the public service set of the target IP address in priority order; If the protocol feature instruction response of the public service port matches the industrial control device protocol fingerprint knowledge base, send a customized protocol request instruction to the service ports in the unique service set; Determine the manufacturer and model information of the asset corresponding to the target IP address according to the matching result between the response data of the customized protocol request instruction and the protocol fingerprint knowledge base.

2. The asset identification method according to claim 1, wherein The communication traffic is obtained through a traffic mirror collector deployed on the core switch. The collector is configured with a hardware-accelerated traffic filtering module to intercept network data packets containing TCP / UDP protocol headers in real time and forward them to the field-level platform.

3. The asset identification method according to claim 1, characterized in that, The method for filtering the priority sequence of the candidate protocols and service types includes: Query the device record corresponding to the IP address in the preset asset information database; If the device record exists, extract the priority information of the associated device and the supported range of candidate protocols according to the device connection relationship and service attributes in the device record, and generate a priority sequence; If the device record does not exist, extract the peer IP address that has a session with the IP address from the communication traffic, and query the device type and connection relationship of the peer IP address in the asset information database; Based on the device type and connection priority associated with the peer IP address, infer the potential device type of the IP address, and match the protocols and service types supported by the potential device type in the asset information database; According to the matching result, dynamically adjust the priority sequence of the candidate protocols and service types in combination with the default priority rules in the protocol feature library.

4. The asset identification method according to claim 1, wherein The method for generating the protocol feature instruction set includes: Extract the corresponding protocol interaction templates from the industrial control device protocol fingerprint knowledge base according to the candidate protocol and service type priority sequence; Based on the historical detection hit probability, optimize the execution order of the protocol interaction templates, and preferentially select protocol instructions with a hit rate higher than the preset threshold.

5. The asset identification method according to claim 1, characterized in that The method for counting the public service set and unique service set includes: Traverse the list of associated devices of the target IP address and extract the set of service ports supported by each device; Perform an intersection operation on the set of service ports to obtain a common service set; For the remaining service ports that are not in the intersection, generate a unique service set by sorting them according to the device connection priority.

6. The asset identification method according to claim 1, characterized in that, The method for determining the priority order includes: If the protocol type of the common service port matches the historical record of the target device manufacturer, its priority is raised to the highest; If there are multiple common service ports, they are sorted according to the importance weights of the industrial control protocols preset in the protocol fingerprint knowledge base.

7. The asset identification method according to claim 1, wherein The method for generating the customized protocol request instruction includes: Extract the private protocol instruction template of the target manufacturer's device from the protocol fingerprint knowledge base; Based on the protocol interaction historical record of the target IP address, fill in the variable parameters in the private protocol instruction template.

8. The asset identification method according to claim 1, wherein, The determination logic of the matching result includes: If the response data contains the unique identification field of the target manufacturer's device, it is directly determined that the match is successful; If the response data does not contain the identification field, calculate its similarity with the feature code in the protocol fingerprint knowledge base. If the similarity exceeds the preset threshold, it is determined as a fuzzy match.

9. An electronic device, comprising a memory and a processor, characterized in that, The memory is used to store a program for supporting the processor to execute any one of the asset identification methods in claims 1-8, and the processor is configured to execute the program stored in the memory.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, it executes the steps of any one of the asset identification methods in claims 1-8.

Images