A terminal probe-based asset verification and software compliance detection method and system

CN122969820APending Publication Date: 2026-10-23BEIJING INST OF AEROSPACE INFORMATION & INFORMATION
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610825676.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-09
Publication Date
2026-10-23

AI Technical Summary

Technical Problem

[0003]本发明提供一种基于终端探针的资产校验与软件合规检测方法及系统,用以解决传统的信息资产核查方式所依赖人工统计或定期扫描,导致信息采集不全面,资产台账与实际情况脱节,执行效率极低,无法满足实时校验需求的问题

Benefits of technology

1、基于双阶段匹配并行比对的信息资产管理策略

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122969820A_ABST
    Figure CN122969820A_ABST
Patent Text Reader

Abstract

The application belongs to the technical field of network and distributed computing, and particularly discloses an asset checking and software compliance detection method and system based on a terminal probe, which comprises the following steps: uniformly collecting data collected by the terminal probe; performing data preprocessing on the collected data, performing local end data processing, and obtaining preprocessed data; performing information asset dynamic comparison and software black-white-red list comparison according to the preprocessed data, so as to check the information asset and perform compliance detection on the software, thereby solving the problems that the traditional information asset checking mode relies on manual statistics or periodic scanning, the information collection is not comprehensive, the asset ledger is out of touch with the actual situation, the execution efficiency is extremely low, and the real-time checking demand cannot be met.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of network and distributed computing technology, and in particular relates to an asset verification and software compliance detection method and system based on terminal probes. Background Technology

[0002] In the current digital transformation process, the number of terminal devices in enterprises and institutions continues to grow, and the types of terminals are becoming increasingly complex. The need for dynamic management of information assets and software compliance testing has become a core requirement of cybersecurity management. Traditional information asset verification methods rely on manual statistics or periodic scanning, resulting in incomplete information collection and a disconnect between asset ledgers and actual conditions. When the number of terminals and the amount of data are large, the execution efficiency is extremely low, failing to meet the needs of real-time verification. At the same time, software compliance testing is inaccurate, failing to capture information such as newly installed software in real time, resulting in significant lag issues. Summary of the Invention

[0003] This invention provides a method and system for asset verification and software compliance testing based on terminal probes, which solves the problems of traditional information asset verification methods that rely on manual statistics or periodic scanning, resulting in incomplete information collection, a disconnect between asset ledgers and actual conditions, extremely low execution efficiency, and inability to meet real-time verification requirements.

[0004] Firstly, a method for asset verification and software compliance testing based on terminal probes is provided, the method comprising: Unify and collect data collected by terminal probes; The collected data is preprocessed locally to obtain preprocessed data. Based on the preprocessed data, dynamic comparison of information assets and comparison of software blacklists, whitelists, and redlists are performed to verify information assets and conduct compliance testing on software.

[0005] Secondly, a terminal probe-based asset verification and software compliance detection system is provided, the system comprising: The data acquisition module is used to collect data collected by the terminal probes in a unified manner; The data preprocessing module is used to preprocess the collected data and perform local data processing to obtain preprocessed data. The inspection and testing module is used to perform dynamic comparison of information assets and comparison of software blacklists, whitelists, and redlists based on preprocessed data, so as to verify information assets and conduct compliance testing on software.

[0006] Beneficial effects: 1. Information asset management strategy based on two-stage matching and parallel comparison By employing a two-stage matching algorithm and hash index optimization mechanism, a hash index is established based on the terminal information collected from ledgers and probes, selecting core identifiers. An equi-join is performed using the asset number as the unique primary key to quickly mark matching success, inventory shortages, and inventory surpluses. Furthermore, a data sharding parallel comparison technology is introduced to split massive amounts of terminal data into data shards. Multi-threaded concurrent execution of comparison tasks is used to build a two-level caching mechanism, storing ledger data that has been accessed frequently for nearly 72 hours into the cache data, avoiding frequent database I / O operations, and reducing the response time to milliseconds.

[0007] 2. Software compliance detection strategy based on progressive comparison using similarity algorithms A rigorous and flexible compliance detection system is constructed by setting up a three-tiered list and performing progressive comparisons. This system clearly defines the installed and running "red list" software, the allowed installation and running "white list" software, and the prohibited installation and running "black list" software. These three lists are stored independently and managed separately, with a progressive priority verification system: red list first, white list second priority, and black list as the most critical. Red list matching results directly override subsequent list judgments, avoiding rule conflicts. Relevant fields are extracted from software information collected by probes, and the compliance list is standardized. Fuzzy matching is performed based on the similarity of the collected data and relevant fields in the compliance list using an edit distance algorithm. Redundant fields are selected for weighted calculation to further verify the rationality of the matching results. This two-step calculation and comprehensive score significantly improves the accuracy and efficiency of software compliance detection.

[0008] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0009] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram illustrating the implementation process of an asset verification and software compliance testing method based on a terminal probe, according to an embodiment of the present invention. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of this specification.

[0011] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0012] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0013] To improve the ability to verify information assets and detect whether software is compliant, this invention provides a method and system for asset verification and software compliance detection based on terminal probes.

[0014] Figure 1 This is a schematic diagram illustrating the implementation process of an asset verification and software compliance detection method based on a terminal probe according to an embodiment of the present invention. (See attached diagram.) Figure 1 The method includes: S100: Unifies and collects data gathered by terminal probes; S102: Perform data preprocessing on the collected data, perform local data processing, and obtain preprocessed data; S104: Based on the preprocessed data, perform dynamic comparison of information assets and comparison of software blacklists, whitelists, and redlists to verify information assets and conduct compliance testing on software.

[0015] In one specific implementation, the unified collection of data collected by the terminal probe specifically includes: (1) Data integration Deploy terminal probes in terminal devices to collect hardware, software, network, and operational status information at a pre-set frequency, and collect key information such as CPU utilization and port occupancy in real time. (2) Data collection The collected raw data is fragmented and then uploaded to the server via an HTTPS encrypted channel. If the transmission is interrupted, a resume function is triggered to ensure that no data is lost. Key data collection metrics for the terminal are shown in Table 1.

[0016] Table 1 Terminal probe acquisition indicators It should be noted that the fragmentation here is for large data encountered during transmission, in order to ensure transmission reliability and adapt to network bandwidth fluctuations.

[0017] In one specific implementation, the step of performing data preprocessing on the collected data, and performing local data processing to obtain preprocessed data, specifically includes: (1) Data cleaning and normalization Data cleaning: Remove IP addresses with incorrect formats and invalid software version numbers; Field standardization: Software names are uniformly converted to lowercase, special characters are removed, and authoritative fields are extracted based on publisher information; Deduplication: Duplicate reported data is removed based on timestamps and unique device identifiers; Feature extraction: Generate hash values ​​for key fields such as terminal unique identifier and software digital signature as unique fingerprints for rapid comparison; (2) Data fragmentation and cache preheating Massive amounts of data are split into independent data slices based on the department, geographical location, or asset type of the terminal. Ledger data that is frequently accessed within a preset time period is preloaded into the remote dictionary service Redis cache, and a two-level cache (memory → SSD) hierarchical storage is established.

[0018] It should be noted that the sharding here refers to business sharding, which aims to improve business processing efficiency. For example, data from department A can be preloaded into Redis cluster node 1.

[0019] The second-level cache is a multi-level caching architecture consisting of a memory cache [first level, located in server memory (such as Redis / Memcached)] and a persistent cache [second level, located on SSD hard disk or distributed storage (such as HBase / Cassandra)]. To improve efficiency, hot data is stored in expensive memory, and cold data is stored on inexpensive hard disk. When accessing data: the first-level cache is queried first → if a match is found, it is returned directly; if a match is missed, the second-level cache is queried → after a return, the first-level cache is updated synchronously.

[0020] In one specific implementation, dynamic comparison of information assets is performed based on preprocessed data to verify the information assets, specifically including: (1) Hash index fast matching By employing a hash index fast matching technique, and using the asset number as the unique primary key, a composite hash key is generated. The data from both the ledger database and the probe data are organized using an "asset number + hardware fingerprint" method, with the first 8 digits used to create a hash index table for both the ledger database and probe data. Through equi-join operations, key-value matching can be performed quickly, enabling efficient comparison of ledger data and probe data. The composite hash key... The generatrices are as follows: (Asset Number || Hardware Fingerprint) [0:8] ); Among them, SHA3-256 is a national security algorithm that can prevent counterfeiting; the asset number can be determined by itself according to the asset size and actual business needs, and can be set to a 12-bit mixed code according to the asset type, department, year of entry, etc.; || represents string concatenation operation, and [0:8] represents truncating the first 8 bytes, that is, the first 16 hexadecimal characters; During the comparison process, assets are divided into three categories based on the matching results: successful matching, inventory shortage, and inventory surplus. A successful matching indicates that the asset number and hardware fingerprint of the ledger and probe are consistent, and the device is in normal condition. An inventory shortage indicates that the asset exists in the ledger but is not reported by the probe, which may be due to the device being lost or offline. An inventory surplus indicates that the probe has reported the asset but it is not registered in the ledger, which may be due to unauthorized device access. (2) Parallel comparison and result aggregation The above comparison method is used to perform multi-threaded comparison of information assets to improve comparison efficiency. In the parallel comparison stage, multi-threaded concurrency technology is used to divide the data into multiple data slices. (This involves starting multiple threads for parallel processing, so the data is divided into multiple data slices for processing by multiple threads, thereby achieving parallel computing resource allocation and performance optimization.) Start N Each data segment is processed by an independent process, with concurrent execution of tasks achieved through a thread pool. Simultaneously, an incremental update strategy is employed, initiating comparison tasks only for data segments that have changed within a preset timeframe (e.g., within 72 hours), effectively reducing redundant computation. During the result aggregation phase, the comparison results from each thread are summarized to generate a global asset status. Among these, data segments... The division formula is as follows: ;in, Z Indicates the total number of records; N The number of threads is represented by the following formula: N线程数 =min(CPU 内核数 Total data volume / 10 4 ); In this context, / indicates division by.

[0021] By employing a two-stage hash index matching and data sharding parallel comparison technology, the performance bottleneck of manual statistics and batch scanning methods in processing massive amounts of terminal data has been resolved. The hash index optimization mechanism significantly improves asset matching efficiency, data sharding concurrent processing reduces terminal data comparison time to minutes, and the two-level caching mechanism reduces high-frequency access response time to milliseconds, enabling real-time updates of dynamic asset ledgers.

[0022] A dynamic mapping mechanism based on core identifiers is constructed, and the asset number primary key is accurately matched through the equi-join algorithm. Incremental data capture technology is adopted to mark hot zones of asset information that changes within 72 hours. Combined with a two-stage comparison strategy, the delay in identifying inventory surpluses / shortages is significantly reduced, thereby lowering the consistency error rate between physical assets and digital ledgers.

[0023] In one specific implementation, software blacklists, whitelists, and redlists are compared based on preprocessed data to perform compliance testing on the software, specifically including: (1) Fuzzy matching algorithm Fuzzy matching is optimized based on the edit distance algorithm, and the similarity S1 between the probe-collected data and the associated fields in the asset ledger is calculated. 关联 The preset similarity threshold for related fields is S1. 阈值 If the actual similarity S1 关联 <threshold S1 阈值 If the actual similarity is S1, then the match is considered unsuccessful. 关联 ≥threshold S1 阈值 Then, further verification is performed using redundant fields; among which, the actual similarity S1 关联 The calculation formula is as follows: S1 关联 =(1-edit distance(probe acquisition value, ledger value) / max(probe acquisition value length, ledger value length))×100%; Where / means divide by; Software version number, software installation time, and software update status were selected as redundant fields to further verify the rationality of the matching results. A weighted summation scoring mechanism was used to assign weights to the selected redundant fields, with the software version number being assigned a weight separately. Software installation time is weighted as follows: Software update status weight Calculate the overall similarity S of redundant fields. 冗余综合 The preset redundancy comprehensive similarity threshold is S2. 阈值If the similarity of the associated fields is S1 关联 ≥threshold S1 阈值 Furthermore, the overall similarity S of redundant fields 冗余综合 ≥threshold S2 阈值 If the match is successful, it is considered a successful match; otherwise, manual verification is required. The redundant fields' overall similarity S... 冗余综合 The calculation is as follows: S 冗余综合 = w 1×S 版本 + w 2×S 时间 + w 3×S 状态 ; In specific implementation, S1 阈值 It can be set to 80%; S2 阈值 It can be set to 70%; , and These values ​​can be set to 0.4, 0.3, and 0.3 respectively, depending on actual needs; no restrictions are imposed here.

[0024] (2) Priority verification of the three-level list To avoid rule conflicts, based on a priority-based logic, the collected software asset information is first matched with the red list, and the red list matching result directly overrides the subsequent list determination; if a match exists, the software is marked as "must comply" and does not need to be compared with the white list and black list; if no match exists, a red list missing alarm is triggered, prompting the administrator that the terminal is missing the necessary compliant software. For software that does not match the red list, a similarity calculation is performed with the white list. If a match is found, the software is marked as "allowed to run" and deemed compliant. If no match is found, the software proceeds to the blacklist comparison stage. For software that does not match the first two levels of the list, a blacklist verification is performed to determine whether it is a prohibited item on the blacklist.

[0025] The innovative priority-based verification framework effectively solves the problem of judgment conflicts in traditional rule engines through a three-level progressive judgment logic of red / white / black lists. It adopts a combination of fuzzy matching and edit distance algorithms to improve the accuracy of software name similarity recognition. Combined with the publisher information cross-verification mechanism, it enhances the real-time performance and reliability of software compliance detection.

[0026] This invention provides an asset verification and software compliance detection method based on terminal probes. Based on the operational status and performance data of application software and hardware collected by the probes, and combined with the application deployment architecture, a comprehensive information asset management and terminal compliance inspection mode is constructed to promptly discover and resolve potential security vulnerabilities, thereby improving the management efficiency and security of the information asset dynamic management platform.

[0027] Based on the same inventive concept, the present invention also provides an asset verification and software compliance detection system based on terminal probes, the system comprising: The data acquisition module is used to collect data collected by the terminal probes in a unified manner; The data preprocessing module is used to preprocess the collected data and perform local data processing to obtain preprocessed data. The inspection and testing module is used to perform dynamic comparison of information assets and comparison of software blacklists, whitelists, and redlists based on preprocessed data, so as to verify information assets and conduct compliance testing on software.

[0028] In one specific embodiment, the data acquisition module is specifically used for: (1) Data integration Deploy terminal probes in terminal devices to collect hardware, software, network, and operational status information at a pre-set frequency, and collect key information such as CPU utilization and port occupancy in real time. (2) Data collection After the collected raw data is processed into segments, it is uploaded to the server via an HTTPS encrypted channel. If the transmission is interrupted, the interruption will be resumed to ensure that no data is lost.

[0029] In one specific embodiment, the data preprocessing module is specifically used for: (1) Data cleaning and normalization Data cleaning: Remove IP addresses with incorrect formats and invalid software version numbers; Field standardization: Software names are uniformly converted to lowercase, special characters are removed, and authoritative fields are extracted based on publisher information; Deduplication: Duplicate reported data is removed based on timestamps and unique device identifiers; Feature extraction: Generate hash values ​​for key fields of terminal unique identifier and software digital signature as unique fingerprints for hardware or software, for rapid comparison; (2) Data fragmentation and cache preheating Massive amounts of data are split into independent data slices based on the department, geographical location, or asset type of the terminal. Ledger data that is frequently accessed within a preset time period is preloaded into the remote dictionary service Redis cache to establish a two-level cache hierarchical storage.

[0030] In one specific implementation, the inspection and testing module is specifically used for: (1) Hash index fast matching By employing a hash index fast matching technique, and using the asset number as the unique primary key, a composite hash key is generated. The data from both the ledger database and the probe data are organized using an "asset number + hardware fingerprint" method, with the first 8 digits used to create a hash index table for both the ledger database and probe data. Through equi-join operations, key-value matching can be performed quickly, enabling efficient comparison of ledger data and probe data. The composite hash key... The generatrices are as follows: (Asset Number || Hardware Fingerprint) [0:8] ); Among them, SHA3-256 is a security algorithm that can prevent forgery; the asset number can be determined automatically according to the asset size and actual business needs; || represents string concatenation operation, and [0:8] represents extracting the first 8 bytes, that is, the first 16 hexadecimal characters; During the comparison process, assets are divided into three categories based on the matching results: successful matching, inventory shortage, and inventory surplus. A successful matching indicates that the asset number and hardware fingerprint of the ledger and probe are consistent, and the device is in normal condition. An inventory shortage indicates that the asset exists in the ledger but is not reported by the probe, which may be due to the device being lost or offline. An inventory surplus indicates that the probe has reported the asset but it is not registered in the ledger, which may be due to unauthorized device access. (2) Parallel comparison and result aggregation The above comparison method is used to perform multi-threaded comparison of information assets to improve comparison efficiency. In the parallel comparison stage, multi-threaded concurrency technology is used to divide the data into multiple data slices. ,start up N Each data slice is processed by an independent process, with concurrent execution of tasks achieved through a thread pool. Simultaneously, an incremental update strategy is employed, initiating comparison tasks only for data slices that have changed within a preset timeframe, effectively reducing redundant computation. During the result aggregation phase, the comparison results from each thread are summarized to generate a global asset status. Among these, data slices... The division formula is as follows: ;in, Z Indicates the total number of records; N The number of threads is represented by the following formula: N 线程数 =min(CPU 内核数 Total data volume / 10 4 ); In this context, / indicates division by.

[0031] In one specific implementation, the inspection and testing module is further used for: (1) Fuzzy matching algorithm Fuzzy matching is optimized based on the edit distance algorithm, and the similarity S1 between the probe-collected data and the associated fields in the asset ledger is calculated. 关联The preset similarity threshold for related fields is S1. 阈值 If the actual similarity S1 关联 <threshold S1 阈值 If the actual similarity is S1, then the match is considered unsuccessful. 关联 ≥threshold S1 阈值 Then, further verification is performed using redundant fields; among which, the actual similarity S1 关联 The calculation formula is as follows: S1 关联 =(1-edit distance(probe acquisition value, ledger value) / max(probe acquisition value length, ledger value length))×100%; Where / means divide by; Software version number, software installation time, and software update status were selected as redundant fields to further verify the rationality of the matching results. A weighted summation scoring mechanism was used to assign weights to the selected redundant fields, with the software version number being assigned a weight separately. Software installation time is weighted as follows: Software update status weight Calculate the overall similarity S of redundant fields. 冗余综合 The preset redundancy comprehensive similarity threshold is S2. 阈值 If the similarity of the associated fields is S1 关联 ≥threshold S1 阈值 Furthermore, the overall similarity S of redundant fields 冗余综合 ≥threshold S2 阈值 If the match is successful, it is considered a successful match; otherwise, manual verification is required. The redundant fields' overall similarity S... 冗余综合 The calculation is as follows: S 冗余综合 = w 1×S 版本 + w 2×S 时间 + w 3×S 状态 ; (2) Priority verification of the three-level list To avoid rule conflicts, based on a priority-based logic, the collected software asset information is first matched with the red list, and the red list matching result directly overrides the subsequent list determination; if a match exists, the software is marked as "must comply" and does not need to be compared with the white list and black list; if no match exists, a red list missing alarm is triggered, prompting the administrator that the terminal is missing the necessary compliant software. For software that does not match the red list, a similarity calculation is performed with the white list. If a match is found, the software is marked as "allowed to run" and deemed compliant. If no match is found, the software proceeds to the blacklist comparison stage. For software that does not match the first two levels of the list, a blacklist verification is performed to determine whether it is a prohibited item on the blacklist.

[0032] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention.

[0033] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for asset verification and software compliance testing based on terminal probes, characterized in that, The method includes: Unify and collect data collected by terminal probes; The collected data is preprocessed locally to obtain preprocessed data. Based on the preprocessed data, dynamic comparison of information assets and comparison of software blacklists, whitelists, and redlists are performed to verify information assets and conduct compliance testing on software.

2. The method according to claim 1, characterized in that, The unified collection of data from the terminal probes specifically includes: (1) Data integration Deploy terminal probes in terminal devices to collect hardware, software, network, and operational status information at a pre-set frequency, and collect key information such as CPU utilization and port occupancy in real time. (2) Data collection After the collected raw data is processed into segments, it is uploaded to the server via an HTTPS encrypted channel. If the transmission is interrupted, the interruption will be resumed to ensure that no data is lost.

3. The method according to claim 2, characterized in that, The process of preprocessing the collected data locally to obtain preprocessed data specifically includes: (1) Data cleaning and normalization Data cleaning: Remove IP addresses with incorrect formats and invalid software version numbers; Field standardization: Software names are uniformly converted to lowercase, special characters are removed, and authoritative fields are extracted based on publisher information; Deduplication: Duplicate reported data is removed based on timestamps and unique device identifiers; Feature extraction: Generate hash values ​​for key fields of terminal unique identifier and software digital signature as unique fingerprints for hardware or software, for rapid comparison; (2) Data fragmentation and cache preheating Massive amounts of data are split into independent data slices based on the department, geographical location, or asset type of the terminal. Ledger data that is frequently accessed within a preset time period is preloaded into the remote dictionary service Redis cache to establish a two-level cache hierarchical storage.

4. The method according to claim 3, characterized in that, Dynamic comparison of information assets is performed based on preprocessed data to verify the information assets, specifically including: (1) Hash index fast matching By employing a hash index fast matching technique, and using the asset number as the unique primary key, a composite hash key is generated. The data from both the ledger database and the probe data are organized using an "asset number + hardware fingerprint" method, with the first 8 digits used to create a hash index table for both the ledger database and probe data. Through equi-join operations, key-value matching can be performed quickly, enabling efficient comparison of ledger data and probe data. The composite hash key... The generatrices are as follows: (Asset Number || Hardware Fingerprint) [0:8] ); Among them, SHA3-256 is a security algorithm that can prevent forgery; the asset number can be determined automatically according to the asset size and actual business needs; || represents string concatenation operation, and [0:8] represents extracting the first 8 bytes, that is, the first 16 hexadecimal characters; During the comparison process, assets are divided into three categories based on the matching results: successful matching, inventory shortage, and inventory surplus. A successful matching indicates that the asset number and hardware fingerprint of the ledger and probe are consistent, and the device is in normal condition. An inventory shortage indicates that the asset exists in the ledger but is not reported by the probe, which may be due to the device being lost or offline. An inventory surplus indicates that the probe has reported the asset but it is not registered in the ledger, which may be due to unauthorized device access. (2) Parallel comparison and result aggregation The above comparison method is used to perform multi-threaded comparison of information assets to improve comparison efficiency. In the parallel comparison stage, multi-threaded concurrency technology is used to divide the data into multiple data slices. ,start up N Each data slice is processed by an independent process, with concurrent execution of tasks achieved through a thread pool. Simultaneously, an incremental update strategy is employed, initiating comparison tasks only for data slices that have changed within a preset timeframe, effectively reducing redundant computation. During the result aggregation phase, the comparison results from each thread are summarized to generate a global asset status. Among these, data slices... The division formula is as follows: ;in, Z Indicates the total number of records; N The number of threads is represented by the following formula: N 线程数 =min(CPU 内核数 Total data volume / 10 4 ); In this context, / indicates division by.

5. The method according to claim 3, characterized in that, The software performs blacklist / whitelist / redlist comparisons based on the preprocessed data. To conduct compliance testing on the software, specifically including: (1) Fuzzy matching algorithm Fuzzy matching is optimized based on the edit distance algorithm, and the similarity S1 between the probe-collected data and the associated fields in the asset ledger is calculated. 关联 The preset similarity threshold for related fields is S1. 阈值 If the actual similarity S1 关联 <threshold S1 阈值 If the actual similarity is S1, then the match is considered unsuccessful. 关联 ≥threshold S1 阈值 Then, further verification is performed using redundant fields; among which, the actual similarity S1 关联 The calculation formula is as follows: S1 关联 =(1-edit distance(probe acquisition value, ledger value) / max(probe acquisition value length, ledger value length))×100%; Where / means divide by; Software version number, software installation time, and software update status were selected as redundant fields to further verify the rationality of the matching results. A weighted summation scoring mechanism was used to assign weights to the selected redundant fields, with the software version number being assigned a weight separately. Software installation time is weighted as follows: Software update status weight Calculate the overall similarity S of redundant fields. 冗余综合 The preset redundancy comprehensive similarity threshold is S2. 阈值 If the similarity of the associated fields is S1 关联 ≥threshold S1 阈值 Furthermore, the overall similarity S of redundant fields 冗余综合 ≥threshold S2 阈值 If the match is successful, it is considered a successful match; otherwise, manual verification is required. The redundant fields' overall similarity S... 冗余综合 The calculation is as follows: S 冗余综合 = w 1×S 版本 + w 2×S 时间 + w 3×S 状态 ; (2) Priority verification of the three-level list To avoid rule conflicts, based on a priority-based logic, the collected software asset information is first matched with the red list, and the red list matching result directly overrides the subsequent list determination; if a match exists, the software is marked as "must comply" and does not need to be compared with the white list and black list; if no match exists, a red list missing alarm is triggered, prompting the administrator that the terminal is missing the necessary compliant software. For software that does not match the red list, a similarity calculation is performed with the white list. If a match is found, the software is marked as "allowed to run" and deemed compliant. If no match is found, the software proceeds to the blacklist comparison stage. For software that does not match the first two levels of the list, a blacklist verification is performed to determine whether it is a prohibited item on the blacklist.

6. An asset verification and software compliance detection system based on terminal probes, characterized in that, The system employs the terminal probe-based asset verification and software compliance detection method according to any one of claims 1 to 5, wherein the system comprises: The data acquisition module is used to collect data collected by the terminal probes in a unified manner; The data preprocessing module is used to preprocess the collected data and perform local data processing to obtain preprocessed data. The inspection and testing module is used to perform dynamic comparison of information assets and comparison of software blacklists, whitelists, and redlists based on preprocessed data, so as to verify information assets and conduct compliance testing on software.

7. The system according to claim 6, characterized in that, The data acquisition module is specifically used for: (1) Data integration Deploy terminal probes in terminal devices to collect hardware, software, network, and operational status information at a pre-set frequency, and collect key information such as CPU utilization and port occupancy in real time. (2) Data collection After the collected raw data is processed into segments, it is uploaded to the server via an HTTPS encrypted channel. If the transmission is interrupted, the interruption will be resumed to ensure that no data is lost.

8. The system according to claim 7, characterized in that, The data preprocessing module is specifically used for: (1) Data cleaning and normalization Data cleaning: Remove IP addresses with incorrect formats and invalid software version numbers; Field standardization: Software names are uniformly converted to lowercase, special characters are removed, and authoritative fields are extracted based on publisher information; Deduplication: Duplicate reported data is removed based on timestamps and unique device identifiers; Feature extraction: Generate hash values ​​for key fields of terminal unique identifier and software digital signature as unique fingerprints for hardware or software, for rapid comparison; (2) Data fragmentation and cache preheating Massive amounts of data are split into independent data slices based on the department, geographical location, or asset type of the terminal. Ledger data that is frequently accessed within a preset time period is preloaded into the remote dictionary service Redis cache to establish a two-level cache hierarchical storage.

9. The system according to claim 8, characterized in that, The inspection and testing module is specifically used for: (1) Hash index fast matching By employing a hash index fast matching technique, and using the asset number as the unique primary key, a composite hash key is generated. The data from both the ledger database and the probe data are organized using an "asset number + hardware fingerprint" method, with the first 8 digits used to create a hash index table for both the ledger database and probe data. Through equi-join operations, key-value matching can be performed quickly, enabling efficient comparison of ledger data and probe data. The composite hash key... The generatrices are as follows: (Asset Number || Hardware Fingerprint) [0:8] ); Among them, SHA3-256 is a security algorithm that can prevent forgery; the asset number can be determined automatically according to the asset size and actual business needs; || represents string concatenation operation, and [0:8] represents extracting the first 8 bytes, that is, the first 16 hexadecimal characters; During the comparison process, assets are divided into three categories based on the matching results: successful matching, inventory shortage, and inventory surplus. A successful matching indicates that the asset number and hardware fingerprint of the ledger and probe are consistent, and the device is in normal condition. An inventory shortage indicates that the asset exists in the ledger but is not reported by the probe, which may be due to the device being lost or offline. An inventory surplus indicates that the probe has reported the asset but it is not registered in the ledger, which may be due to unauthorized device access. (2) Parallel comparison and result aggregation The above comparison method is used to perform multi-threaded comparison of information assets to improve comparison efficiency. In the parallel comparison stage, multi-threaded concurrency technology is used to divide the data into multiple data slices. ,start up N Each data slice is processed by an independent process, with concurrent execution of tasks achieved through a thread pool. Simultaneously, an incremental update strategy is employed, initiating comparison tasks only for data slices that have changed within a preset timeframe, effectively reducing redundant computation. During the result aggregation phase, the comparison results from each thread are summarized to generate a global asset status. Among these, data slices... The division formula is as follows: ;in, Z Indicates the total number of records; N The number of threads is represented by the following formula: N 线程数 =min(CPU 内核数 Total data volume / 10 4 ); In this context, / indicates division by.

10. The system according to claim 9, characterized in that, The inspection and testing module is also specifically used for: (1) Fuzzy matching algorithm Fuzzy matching is optimized based on the edit distance algorithm, and the similarity S1 between the probe-collected data and the associated fields in the asset ledger is calculated. 关联 The preset similarity threshold for related fields is S1. 阈值 If the actual similarity S1 关联 <threshold S1 阈值 If the actual similarity is S1, then the match is considered unsuccessful. 关联 ≥threshold S1 阈值 Then, further verification is performed using redundant fields; among which, the actual similarity S1 关联 The calculation formula is as follows: S1 关联 =(1-edit distance(probe acquisition value, ledger value) / max(probe acquisition value length, ledger value length))×100%; Where / means divide by; Software version number, software installation time, and software update status were selected as redundant fields to further verify the rationality of the matching results. A weighted summation scoring mechanism was used to assign weights to the selected redundant fields, with the software version number being assigned a weight separately. Software installation time is weighted as follows: Software update status weight Calculate the overall similarity S of redundant fields. 冗余综合 The preset redundancy comprehensive similarity threshold is S2. 阈值 If the similarity of the associated fields is S1 关联 ≥threshold S1 阈值 Furthermore, the overall similarity S of redundant fields 冗余综合 ≥threshold S2 阈值 If the match is successful, it is considered a successful match; otherwise, manual verification is required. The redundant fields' overall similarity S... 冗余综合 The calculation is as follows: S 冗余综合 = w 1×S 版本 + w 2×S 时间 + w 3×S 状态 ; (2) Priority verification of the three-level list To avoid rule conflicts, based on a priority-based logic, the collected software asset information is first matched with the red list, and the red list matching result directly overrides the subsequent list determination; if a match exists, the software is marked as "must comply" and does not need to be compared with the white list and black list; if no match exists, a red list missing alarm is triggered, prompting the administrator that the terminal is missing the necessary compliant software. For software that does not match the red list, a similarity calculation is performed with the white list. If a match is found, the software is marked as "allowed to run" and deemed compliant. If no match is found, the software proceeds to the blacklist comparison stage. For software that does not match the first two levels of the list, a blacklist verification is performed to determine whether it is a prohibited item on the blacklist.