Target equipment network security compliance inspection method, device and equipment

Abstract

The embodiment of the invention provides a routing inspection method, device and equipment for network security compliance of target equipment. The method comprises the following steps: acquiring a digital certificate and a session key of a hardware encryption key; verifying the digital certificate, and if the verification is passed, decrypting a local compliance rule base according to the session key; selecting an inspection instruction corresponding to a target compliance scene from the local compliance rule base; sending the inspection instruction to target equipment, and receiving an inspection result returned by the target equipment according to the detection instruction; obtaining a risk score of the target equipment according to the inspection result; obtaining a compliance report of the target equipment according to the risk score; and outputting the compliance report of the target equipment. According to the embodiment of the invention, the local compliance rule base can be decrypted through the hardware encryption key, the target compliance scene inspection instruction is selected as required, the hybrid requirements of security, secret evaluation and operation and maintenance are adapted, tools do not need to be purchased repeatedly, and the cost and the management complexity are reduced.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of network security processing, and in particular to a method, apparatus and equipment for inspecting the network security compliance of a target device. Background Technology

[0002] Currently, cybersecurity compliance inspections typically employ a one-tool-one-rule model. For example, information security compliance (ICT) testing tools only have a built-in basic ICT compliance rule library, and cybersecurity security assessment (CSCI) tools only support CSCI-specific testing. The rule library is fixed within the tool and cannot be dynamically adjusted according to the enterprise's mixed compliance needs of ICT compliance, CSCI, and operations and maintenance. If an enterprise needs to meet multi-scenario testing requirements, it must repeatedly purchase multiple sets of specialized tools, resulting in high costs and complex management.

[0003] For newly added equipment, existing technology requires technicians to manually develop customized parsing scripts. From analyzing equipment command formats and writing data extraction logic to testing and verification, the entire process takes more than 30 days. This cannot keep up with the iteration speed of adding 1-2 types of equipment to the enterprise infrastructure every month, resulting in some new equipment remaining uninspected for extended periods.

[0004] Currently, the login authentication process uses plaintext transmission of usernames and passwords, and inspection results are stored directly in plaintext on local or cloud servers without hardware-level encryption protection. Once the transmission process is intercepted or the server is compromised, sensitive data is easily leaked, failing to meet the stringent requirements of zero data leakage in industries such as military and finance.

[0005] Furthermore, the generated plain text inspection reports (ranging from dozens to hundreds of pages) require manual analysis of risk points and matching of remediation solutions, which takes a long time in the decision-making process and leads to a delay in risk response. Summary of the Invention

[0006] The technical problem to be solved by the embodiments of the present invention is to provide a method, device and equipment for inspecting the network security compliance of target devices. It can decrypt the local compliance rule base through hardware encryption keys, select inspection instructions for target compliance scenarios as needed, adapt to the mixed needs of information security level protection, information security assessment and operation and maintenance, eliminate the need for repeated purchase of tools, and reduce costs and management complexity.

[0007] To solve the above-mentioned technical problems, the technical solution of this invention is as follows: a method for inspecting the network security compliance of a target device, comprising: Obtain the digital certificate and session key for the hardware encryption key; The digital certificate is verified. If the verification is successful, the local compliance rule base is decrypted based on the session key. Select the inspection instruction corresponding to the target compliance scenario from the local compliance rule base; Send the inspection command to the target device and receive the inspection results returned by the target device according to the inspection command; Based on the inspection results, a risk score for the target equipment is obtained; Based on the risk score, a compliance report for the target equipment is obtained; Output a compliance report for the target device.

[0008] Optionally, the digital certificate is verified. If the verification passes, the local compliance rule base is decrypted based on the session key, including: Read the public key and digital certificate chain from the digital certificate; The first challenge code, which is randomly generated, is sent to the hardware encryption key, and the second challenge code is returned after the hardware encryption key signs the first challenge code. The signature is verified using the public key, and the digital certificate chain is also verified. If the signature verification is successful and the digital certificate chain is valid, the local compliance rule base is decrypted using the session key; otherwise, the inspection process is terminated.

[0009] Optionally, select the inspection instruction corresponding to the target compliance scenario from the local compliance rule base, including: Load rule nodes matching the target compliance scenario from the decrypted local compliance rule base. The target compliance scenario includes: information security level protection detection scenario, security assessment detection scenario, and / or operation and maintenance inspection scenario. Translate the rule nodes into standardized atomic instructions; The standardized atomic instructions are converted into inspection instructions adapted to the target device.

[0010] Optionally, the inspection command is sent to the target device, and the inspection results returned by the target device according to the inspection command are received, including: Send probe packets to the target device to verify its liveness status; After successful verification, an encrypted communication connection with the target device is established; The inspection command is sent to the target device through the encrypted communication connection. Receive the inspection results returned by the target device according to the detection command; The inspection results are verified. If the verification passes, the inspection results are stored locally. Otherwise, the inspection command is resent to the target device, and the inspection results returned by the target device according to the inspection command are accepted until the inspection results pass the verification.

[0011] Optionally, based on the inspection results, a risk score for the target equipment is obtained, including: User information is extracted from the inspection results; The user information is stored in the account allocation permission tag and access control tag; Based on the account, assign permission tags and access control tags to obtain the account permission tag score and access control tag score; The conformity of the target device is obtained based on the account permission tag score and access control tag score. Based on the degree of compliance of the target device, a risk score for the target device is obtained.

[0012] Optionally, based on the risk score, a compliance report for the target device is obtained, including: A heatmap is generated based on the different colors corresponding to the risk scores. Bind click events to cells in the heatmap to obtain compliance reports for the target device.

[0013] Optionally, the above inspection methods also include: Based on the inspection results, a repair plan for the target equipment is obtained.

[0014] Embodiments of the present invention also provide a network security compliance inspection device for a target device, comprising: The acquisition module is used to acquire the digital certificate and session key of the hardware encryption key; The processing module is used to verify the digital certificate. If the verification is successful, it decrypts the local compliance rule base according to the session key; selects the inspection instruction corresponding to the target compliance scenario from the local compliance rule base; sends the inspection instruction to the target device and receives the inspection result returned by the target device according to the inspection instruction; obtains the risk score of the target device according to the inspection result; obtains the compliance report of the target device according to the risk score; and outputs the compliance report of the target device.

[0015] Embodiments of the present invention also provide a computing device, comprising: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to perform the method as described above.

[0016] Embodiments of the present invention also provide a computing device readable storage medium storing a program that, when executed by a processor, implements the method described above.

[0017] The above-described solutions of the embodiments of the present invention have at least the following beneficial effects: The above-described solution in this invention breaks away from the rigid "one tool, one rule" model. By decrypting the local compliance rule base using a hardware encryption key, it allows for the selection of inspection instructions for target compliance scenarios as needed, adapting to mixed requirements of information security compliance, data security assessment, and operations and maintenance. This eliminates the need for repeated tool purchases, reducing costs and management complexity. It also eliminates the need for manually developing customized parsing scripts, quickly adapting to 1-2 new types of devices added monthly, resolving the issue of new devices not being inspected for extended periods. Employing digital certificates and session keys for authentication with the hardware encryption key, it ensures encrypted transmission and storage, meeting the zero-leakage requirements of industries such as military and finance. Furthermore, it automatically generates compliance reports, replacing manual line-by-line analysis of plain text reports, shortening risk decision-making time, improving risk response efficiency, and ensuring the flexibility, security, and efficiency of network security compliance inspections. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the network security compliance inspection method for target devices provided in an embodiment of the present invention.

[0019] Figure 2 This is a schematic diagram of a network security compliance inspection device for target devices provided in an embodiment of the present invention. Detailed Implementation

[0020] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0021] like Figure 1 As shown, an embodiment of the present invention provides a method for inspecting the network security compliance of a target device, including: Step 11: Obtain the digital certificate and session key for the hardware encryption key; Step 12: Verify the digital certificate. If the verification is successful, decrypt the local compliance rule base using the session key. Step 13: Select the inspection instruction corresponding to the target compliance scenario from the local compliance rule library; Step 14: Send the inspection command to the target device and receive the inspection results returned by the target device according to the inspection command; Step 15: Based on the inspection results, obtain the risk score of the target equipment; Step 16: Obtain a compliance report for the target device based on the risk score; Step 17: Output the compliance report for the target device.

[0022] This example breaks away from the rigid "one tool, one rule" model. By decrypting the local compliance rule base using a hardware encryption key, it allows for the selection of inspection instructions for target compliance scenarios as needed, adapting to mixed requirements of information security compliance, data security assessment, and operations and maintenance. This eliminates the need for repeated tool purchases, reducing costs and management complexity. It also eliminates the need for manually developing customized parsing scripts, quickly adapting to 1-2 new types of devices added monthly, resolving the issue of new devices not being inspected for extended periods. Employing digital certificates and session keys for authentication via the hardware encryption key, it ensures encrypted transmission and storage, meeting the zero-leakage requirements of industries such as military and finance. It automatically generates compliance reports, replacing manual line-by-line analysis of plain text reports, shortening risk decision-making time, improving risk response efficiency, and ensuring the flexibility, security, and efficiency of cybersecurity compliance inspections.

[0023] In an optional embodiment of the present invention, in step 11, the digital certificate and session key of the hardware encryption key are obtained.

[0024] Specifically, after the user inserts the hardware encryption key into the USB port of the target device, the system reads the digital certificate and session key of the hardware encryption key.

[0025] In this example, the hardware encryption key prevents account password theft, and the session key is dynamically generated and destroyed after the session, eliminating unauthorized access. It provides crucial evidence for subsequent decryption rule bases and encrypted communication, enabling offline data processing and meeting the zero-data-leakage requirements of high-security scenarios. Inserting the hardware encryption key automatically reads the data, simplifying authentication operations, shortening inspection startup time, and reducing human error and management costs.

[0026] In an optional embodiment of the present invention, step 12 involves verifying the digital certificate. If the verification passes, the local compliance rule base is decrypted based on the session key, including: Step 121: Read the public key and digital certificate chain from the digital certificate; specifically, the digital certificate chain includes: root certificate, intermediate certificate and user certificate; Step 122: Send the randomly generated first challenge code to the hardware encryption key, and receive the second challenge code returned by the hardware encryption key after signing the first challenge code; specifically, the first challenge code can be a 128-bit random number, and the second challenge code can include: the first challenge code and the signature value; Step 123: Verify the signature using the public key and simultaneously verify the digital certificate chain. If the signature verification passes and the digital certificate chain is valid, decrypt the local compliance rule base using the session key; otherwise, terminate the inspection process.

[0027] Specifically, the local compliance rule base is a tree structure, containing information security protection rule nodes, security assessment rule nodes, and operation and maintenance rule nodes. After decryption, it is loaded into memory as an executable set of rules. If the signature verification fails or the certificate chain is invalid, the inspection process is immediately terminated and a log record is generated (including the reason for failure, time, and hardware encryption key serial number) to prevent unauthorized devices from accessing the site.

[0028] In this example, the certificate public key and the root-intermediate-user three-level certificate chain are read, and the signature verification is combined with the 128-bit random challenge code to form a dual verification of certificate chain integrity and signature authenticity, which completely eliminates the access of forged certificates and greatly improves the security level compared with plaintext authentication.

[0029] Only after successful verification is the local rule base, which is structured in a tree structure, decrypted using a session key to prevent unauthorized access to sensitive rules such as those related to information security compliance and confidentiality assessment. Rules are loaded into memory for execution and are not stored on the ground, reducing the risk of rule leakage and solving the problem of the rule base being easily tampered with.

[0030] When signature or certificate chain verification fails, the process is immediately terminated and a log containing the reason for failure and the hardware encryption key serial number is generated. This allows for quick tracing of unauthorized access devices and prevention of them from stealing inspection data. Compared to continuing the process after a risk is discovered, this approach can promptly cut off security threats.

[0031] The decrypted and loaded set of executable rules can directly support subsequent rule calls in multiple scenarios without additional parsing; the tree structure facilitates quick matching of target scenarios such as information security compliance and confidentiality assessment, improving the efficiency of subsequent processes and balancing security and smooth inspection.

[0032] In an optional embodiment of the present invention, step 13, selecting the inspection instruction corresponding to the target compliance scenario from the local compliance rule base, includes: Step 131: Load rule nodes matching the target compliance scenario from the decrypted local compliance rule library. The target compliance scenario includes: information security compliance detection scenario, security assessment detection scenario, and / or operation and maintenance inspection scenario. Specifically, based on the target compliance scenario selected by the user (single or multiple selections are possible), load all rule nodes matching the target scenario from the decrypted local compliance rule library. For example, if the operation and maintenance inspection scenario is selected, load sub-rule nodes such as account permission detection, port open detection, and process compliance detection. Each sub-node contains detection indicators, standard thresholds, and command templates. Step 132: Translate the rule node into standardized atomic instructions; specifically, the standardized atomic instructions are predefined general instructions, and the instruction format is uniformly set as instruction type + parameter + return value format to ensure cross-device compatibility; Step 133: Convert the standardized atomic instructions into inspection instructions adapted to the target device; specifically, based on the type of the target device (such as a Linux system or a MySQL database), convert the standardized atomic instructions into inspection instructions adapted to the target device.

[0033] This example supports single or multiple selections for compliance scenarios such as information security level protection, information security assessment, and operation and maintenance, and loads corresponding rule nodes (such as loading sub-nodes like account permissions and port detection in operation and maintenance scenarios). This eliminates the need to repeatedly purchase multiple tools, meets the mixed compliance needs of enterprises, and reduces procurement and management costs.

[0034] The rule nodes are translated into standardized atomic instructions with instruction type, parameters, and return value, and then converted into adaptation instructions according to device type (Linux / MySQL, etc.). This eliminates the need for manual development of custom scripts, solves the problem of long adaptation cycles for new devices, and enables rapid access for various devices.

[0035] The rule nodes include detection indicators, standard thresholds, and command templates. The atomic command format is uniform, avoiding result deviations caused by non-standard commands. The adaptation and conversion are based on preset mapping relationships, requiring no manual intervention, ensuring that the detection standards of different devices in the same scenario are consistent, and improving the reliability of inspection results.

[0036] The loaded rule nodes directly support instruction generation, and the standardized conversion process is simple, reducing the time spent in intermediate steps. Compared with manual instruction processing, it greatly improves the efficiency of inspection instruction generation and helps to promote the automation of the entire process.

[0037] In an optional embodiment of the present invention, step 14, sending the inspection command to the target device and receiving the inspection result returned by the target device according to the inspection command, includes: Step 141: Send probe packets to the target device to verify its liveness status. Specifically, read the pre-configured target device IP range (e.g., 192.168.1.0 / 24), send ICMP probe packets to each IP address, and if an ICMP echo packet is received from the target device, the device is considered live; if not, it is marked as an offline device and recorded in the inspection log. Furthermore, for live devices, port connectivity verification packets can be sent, and subsequent inspections are only performed on devices with open target ports to avoid invalid connections. Step 142: After successful verification, establish an encrypted communication connection with the target device; specifically, all data (instructions and results) during the communication process is encrypted to prevent man-in-the-middle attacks. Step 143: Send the inspection command to the target device through the encrypted communication connection; specifically, send the inspection command to the target device in batches through the encrypted communication connection to avoid single-device command congestion. Step 144: Receive the inspection results returned by the target device according to the detection command; specifically, after the target device executes the inspection command, it receives the inspection results returned via an encrypted connection. Step 145: Verify the inspection result. If the verification passes, store the inspection result locally. Otherwise, resend the inspection command to the target device and accept the inspection result returned by the target device according to the inspection command, until the inspection result passes the verification. Specifically, verifying the inspection result may include: format verification and signature verification. Format verification includes checking whether the result conforms to a preset format. Signature verification includes: the target device signs the result, and the system verifies the signature using the device's public key to ensure that the result has not been tampered with.

[0038] Specifically, if the verification passes, the result is encrypted and stored in the local database; if the verification fails, a retry mechanism is triggered (up to 3 retries, with a 5-second interval between each retry). After 3 failures, the device is marked as having abnormal results and a manual investigation is prompted.

[0039] In this example, the device's liveness is first verified by ICMP probe packets, and then the device with open target ports is filtered by port connectivity verification. Subsequent operations are only performed on compliant devices, which solves the problem of invalid connections caused by blindly sending commands, reduces system resource consumption, and improves inspection efficiency.

[0040] The entire communication process is encrypted to transmit instructions and results, which can effectively resist man-in-the-middle attacks. Compared with plaintext transmission, it completely eliminates the risk of inspection data being stolen or tampered with during transmission, ensuring data security and meeting the needs of highly sensitive scenarios.

[0041] By sending inspection commands in batches and concurrently, congestion of commands on a single device is avoided. Especially in large-scale equipment inspection scenarios, the total time for sending commands is significantly reduced. Compared with processing commands sequentially on a single device, the inspection efficiency is significantly improved, making it suitable for enterprises' multi-device inspection needs.

[0042] By verifying the format (checking whether the result conforms to the preset format) and verifying the signature (using the device's public key to verify the signature of the result), the inspection results are ensured to be in the correct format and have not been tampered with. This solves the problem of erroneous data interference caused by missing result verification, improves the credibility of the inspection results, and provides an accurate basis for subsequent risk scoring.

[0043] When verification fails, a retry mechanism of up to 3 times with an interval of 5 seconds is triggered, which can solve the result abnormality caused by temporary network fluctuations. After 3 failures, the abnormality is marked and manual investigation is prompted. This reduces the inspection interruption caused by occasional problems and can promptly locate the equipment that requires manual intervention. It balances the flexibility of automation and abnormal handling and avoids frequent interruptions of the inspection process due to the lack of a retry mechanism.

[0044] The verified results are encrypted and stored in the local database instead of the cloud, which further enhances data security, meets the requirement of zero data leakage, makes up for the shortcomings of unencrypted storage of results, and eliminates the risk of data leakage in the storage process.

[0045] In an optional embodiment of the present invention, step 15, obtaining a risk score for the target equipment based on the inspection results, includes: Step 151: Extract user information from the inspection results. Specifically, the system calls a multi-level regular expression parsing tool to filter key user information from the inspection results (e.g., the output of the sudoers configuration file on a Linux device): First, it uses primary regular expressions to extract usernames that may have administrator privileges (e.g., text fragments matching usernames with ALL privileges); then, it performs secondary filtering to exclude three types of invalid information: entries containing NOPASSWD (administrator commands can be executed without a password), group permission entries containing wheel (system default administrator group), and group permission entries containing % (representing a group rather than a single user); finally, it obtains a list of individual users with full administrator privileges who require password verification, which serves as the core user information for subsequent analysis. Step 152: Store the user information in an account allocation permission tag and an access control tag; specifically, categorize and store the user information into two preset tags: Account permission assignment tags: Record the user list and the specific permission scope of each user (e.g., root user: can execute all system commands; admin user: can only execute file viewing commands). Access control label: Records management information related to user permissions (such as whether there is a permission approval process log, the number of times administrator commands failed to execute in the past 7 days, and abnormal IP address access records); Step 153: Based on the assigned permission tags and access control tags for the account, obtain the account permission tag score and access control tag score; specifically, the system calculates the account permission tag score and access control tag score respectively according to a preset quantitative scoring standard (both scores have a maximum of 100 points): Account permission tag score calculation standard: If all user permissions comply with the principle of least permission (no permissions exceeding the job requirements), the score is 80-100 points; if 1-2 user permissions exceed the job requirements, the score is 50-79 points; if 3 or more user permissions exceed the job requirements, the score is 0-49 points. Access control label scoring criteria: If there is a complete permission approval process and abnormal access behavior can be monitored in real time, 80-100 points will be awarded; if there is a permission approval process but no abnormal access monitoring mechanism, 50-79 points will be awarded; if there is neither a permission approval process nor abnormal access monitoring, 0-49 points will be awarded.

[0046] Of course, you can also use the formula Obtain an account permission tag score; in, X Score the account permission tag. i =1,2,..., N , N For users whose permissions exceed the requirements of their assigned roles. R i The risk level coefficient for unauthorized users' permissions. W i Weighting the scope of permissions for users with excessive privileges. a The timeliness coefficient for authority rectification. T i This is a frequency coefficient for the use of privileges by users with excessive privileges. According to the formula Obtain the access control label score; in, Y Score the access control label. P comp The completeness coefficient of the authorization approval process. P eff The validity coefficient of the authorization approval process. M comp The completeness coefficient of the authorization approval process. M eff This is the validity coefficient of the authorization approval process. Step 154: Based on the account permission tag score and access control tag score, obtain the target device's compliance degree; specifically, it can be based on... S = A × X + B × Y To obtain the conformity of the target equipment; in, S For the conformity of the target equipment, A As the first weighting coefficient, X Score the account permission tag. B This is the second weighting coefficient. Y Score the access control label; Of course, it can also be based on Obtain the conformity of the target equipment; in, S For the conformity of the target equipment, A s For the scenario weighting coefficients of the account permission dimension, B s For the scenario weight coefficients of the access control dimension, A As the first weighting coefficient, X Score the account permission tag.B This is the second weighting coefficient. Y Score the access control label. e ∆ represents the historical trend influence coefficient. S This represents the historical compliance score trend coefficient. d This is a correction factor for equipment failure risk. F Equipment failure risk coefficient; Step 155: Obtain the risk score of the target device based on the conformity of the target device; specifically, it can be based on... W =100- S， Obtain the risk score for the target equipment; in, W Risk scoring for the target equipment S The degree of conformity of the target equipment.

[0047] In this example, multi-level regular expression parsing and secondary filtering are used to exclude invalid information such as passwordless access and group permissions, retaining only a single user with full permissions who requires password verification. This solves the problem of messy information extraction, provides an accurate data foundation for subsequent scoring, and avoids invalid information interfering with risk assessment.

[0048] By storing user information separately in account-assigned access control tags, the scope of permissions and control information are clearly recorded. Compared with uncategorized storage, this facilitates the rapid location of key data, provides structured support for scoring calculation and subsequent risk tracing, and improves information management efficiency.

[0049] Account permissions and access control labels are scored according to clear standards (e.g., 80-100 points corresponds to compliance with the principle of least privilege), combined with formulas. S = A × X + B × Y Calculate compliance W =100- S A risk score is generated to replace subjective human judgment, avoid scoring bias, ensure consistent scoring standards across different devices and scenarios, and make the results more credible and comparable.

[0050] By using first and second weighting coefficients to reflect the different impacts of various dimensions on compliance, the compliance calculation is made to better reflect the industry’s risk perception. Compared with unweighted average scoring, risk scoring can more accurately reflect core risk points (such as the greater impact of abnormal account permissions on security).

[0051] The risk score is directly derived from the compliance score; the higher the score, the clearer the risk, which facilitates the rapid identification of high-risk equipment. This solves the pain point of having to manually analyze reports page by page to find risks, provides a clear basis for prioritizing subsequent repairs, and improves the efficiency of risk response.

[0052] It realizes the accurate calculation of account permissions and access control scores, avoiding the ambiguity of interval scoring. The compliance formula introduces scenario weights, historical trends, and equipment failure coefficients, taking into account scenario differences and long-term equipment compliance, and is more in line with actual business. The risk scoring formula accurately reflects the characteristics of risk superposition and distribution through models such as coupling effect, entropy weight method, and exponential growth, improving the accuracy and granularity of risk identification.

[0053] In an optional embodiment of the present invention, in step 16, according to the risk score, a compliance report for the target device is obtained, including: Step 161, generate a heat map according to different colors corresponding to the risk score; if W≦ W ≤ 20, the corresponding color is green, if 20 < W ≤ 50, the corresponding color is yellow, if W W > 50, the corresponding color is red; where W W is the risk score of the target device; Construct a heat map through a visualization tool. The X-axis of the heat map is clearly the compliance dimension (i.e., the account allocation permission dimension, the access control dimension), the Y-axis is the IP address of the target device, and the color of each cell corresponds to the risk score color of the device under a certain compliance dimension, visually displaying the risk distribution on the target device distribution map; Step 162, bind a click event to the cells of the heat map to obtain a compliance report for the target device; Specifically, bind a click event to each color cell in the heat map. After clicking, the function of popping up the details panel is triggered; two types of core information are displayed in the panel: Basic information of the target device: including device IP address, hostname, operating system version, specific configuration value of the current compliance dimension (such as the number of users with excessive permissions under the account permission dimension), and the standard requirement value of this dimension (such as the number of users with excessive permissions ≤ 0); Risk details: including risk level (such as high risk), compliance clauses corresponding to the risk (such as the identity authentication clause of Class 3, Level 2.0 of the Equal Protection 2.0, 8.1.4), and the cause of the risk (such as the admin user being misconfigured as ALL permissions); Summarize the heat map and the details panel information of all devices to generate a structured compliance report.

[0054] In this example, the heat map is marked with colors according to the risk score, and the risk distribution is visually presented on the device distribution map, replacing the pure text report. There is no need to manually search page by page, and the overall risk profile of all devices can be grasped within 10 minutes, greatly reducing the risk identification cost.

[0055] Heatmap cells are bound to click events, and clicking them will pop up a details panel that clearly displays basic device information (IP, system version, etc.), differences between configuration values ​​and standard requirements, and the reasons for risks (such as admin mistakenly configuring ALL permissions). This solves the problem of knowing the risks but finding the root cause, helps to quickly identify risk points, and improves the efficiency of problem investigation.

[0056] The panel directly marks the corresponding compliance clauses for the risks (such as clause 8.1.4 of Level 3 of the Information Security Protection Scheme 2.0), clearly indicating the legal basis for the non-compliance of the risks. Compared with reports which lack compliance relevance, this makes it easier for companies to explain the direction of rectification to regulatory authorities, while also helping internal personnel understand the necessity of the risks and reducing compliance communication costs.

[0057] It summarizes heatmaps and detailed information to generate structured reports covering risk distribution, equipment details, and compliance basis. No manual data processing is required, avoiding the problem of disorganized reports. It is convenient for archiving and auditing, and can also be quickly exported for cross-departmental synchronization, improving compliance management efficiency.

[0058] Color-coded grading makes high-risk (red) equipment immediately apparent, allowing companies to prioritize resources for rectification and avoid resource waste caused by a lack of prioritization of risks. This helps to accurately allocate maintenance efforts and improve the pertinence and timeliness of compliance rectification.

[0059] In an optional embodiment of the present invention, in step 17, a compliance report of the target device is output.

[0060] Specifically, it provides a visual display on a local screen and supports the export of encrypted files.

[0061] In this example, the compliance report is presented directly on the local interface, allowing for quick viewing of risk distribution and device details without relying on external tools. Compared to compiling text reports, this significantly improves the efficiency of risk viewing and helps to grasp the compliance status in real time.

[0062] It supports exporting encrypted files to prevent reports from leaking sensitive data during dissemination, meeting the needs of high-security scenarios and making up for the lack of encryption protection in reports. At the same time, it facilitates compliant archiving and secure synchronization across departments, balancing practicality and security.

[0063] In an optional embodiment of the present invention, the above-mentioned inspection method further includes: Step 18: Based on the inspection results, obtain a repair plan for the target equipment.

[0064] Specifically, the system accesses the built-in case reasoning case library, which stores historical repair cases. Each case includes key information such as risk type (e.g., Linux user privilege overreach), device type (e.g., Linux CentOS7), original configuration value, repair command, post-repair verification result, and implementation time. according toST = AT × XT + BT × YT This allows us to obtain the similarity between the current inspection results and historical cases. in, ST The similarity between the current inspection results and historical cases is used to determine the degree of similarity. AT This is the third weighting coefficient. XT For risk type matching degree, BT It is the fourth weighting coefficient. YT For device type matching degree; Risk type matching degree: If the current risk is completely consistent with the risk type of historical cases, then XT =100%; if the types are similar, then XT =60%; if type is irrelevant, then XT =0%; Device type matching: If the current device is completely identical to the device type and operating system version in historical cases, then... BT =100%; if the device types are the same and the versions are similar, then BT =80%; if the equipment type is different, then BT =0%; Candidate solution screening: Screening ST ≥80% of historical cases are used as candidate repair solutions. If there are multiple candidate solutions (such as three cases with similarity of 80%, 90%, and 95%), they are sorted from high to low similarity, and the solution with the highest similarity is recommended first. In the local sandbox environment of the system, the operating system environment of the target device is simulated, the repair commands in the candidate repair schemes are executed, and the risk score is checked to see if it drops to the low-risk range after the repair. Confirm that the repair commands of the candidate repair solutions are compatible with the operating system version and existing configuration of the target device. For example, if the target device is a Linux Ubuntu system, it is necessary to confirm that the repair command visudo can be executed normally on the system and will not affect the normal permissions of other users. If a candidate solution passes the simulation execution verification and compatibility check, it is determined as the final repair solution; if it fails (e.g., the risk score is still medium risk after repair), the candidate solution with the second highest similarity is selected for re-verification until an effective solution is found; if all candidate solutions are ineffective, the system will generate a custom repair suggestion template, which includes risk analysis, suggested repair directions (e.g., manual adjustment of sudoers configuration, removal of users with super privileges), and verification methods, for manual development of repair solutions. The final repair solution is output in the form of a step-by-step document, which includes operation steps, repair commands, precautions and rollback plan.

[0065] In this example, throughST = AT × XT + BT × YT By combining risk and equipment type matching, candidate solutions are screened, and solutions with high similarity (≥80%) are given priority to avoid blind manual matching, which greatly improves the accuracy of repair solutions and reduces trial and error costs.

[0066] The local sandbox simulates the device environment to test repair commands, verifying compatibility and repair effectiveness (risk score reduced to low risk), preventing direct command execution from causing device failure, solving the problem of operational risks caused by lack of verification, and ensuring repair security.

[0067] When all candidate solutions are invalid, a custom repair template is generated, providing risk analysis and repair directions to avoid repair interruptions. Compared with relying on manual solutions to develop solutions from scratch, this reduces the technical threshold and improves problem-solving efficiency.

[0068] The remediation plan is presented in a step-by-step document, including operation steps, commands, precautions and rollback options. No manual organization is required, and even beginners can follow the document. It solves the problem of ambiguous remediation suggestions, shortens the remediation cycle and helps achieve rapid compliance.

[0069] Example 1 Taking a company's mixed inspection of a Linux CentOS 7 server cluster (IP range: 192.168.2.0 / 24) at Level 3 of the Information Security Protection Standard 2.0 plus maintenance as an example, Hardware encryption key (Ukey): Built-in SM2 digital certificate, Ukey serial number: UK202405001; Local compliance rule base: Level 3 rule nodes of Information Security Protection 2.0 (including clauses such as 8.1.4 identity authentication and 8.1.5 access control) and operation and maintenance rule nodes (including account permission detection and port open detection) have been stored in advance and encrypted on the local inspection terminal; Target devices: 20 Linux CentOS 7 servers within the 192.168.2.0 / 24 network segment. The focus of the inspection should be on the compliance of account permissions and the integrity of access control. A method for inspecting network security compliance of a target device, comprising: Step 21, obtain the Ukey's digital certificate and session key: Insert the Ukey into the USB port of the inspection terminal, and the system will automatically call the national cryptographic module: Read the digital certificate (including holder identity information and SM2 public key) from the Ukey; Ukey dynamically derives session keys based on the built-in private key and a 256-bit random seed generated by the system (the key is only valid for this inspection and will be automatically destroyed after the session ends). The system obtains the certificate and session key through a TLS 1.3 encrypted channel, with no plaintext data transmission throughout the process; Step 22, verify the certificate and decrypt the local rule base: The system reads the SM2 public key and the three-level certificate chain from the certificate: root certificate (CPA of the State Cryptography Administration) - intermediate certificate (internal CA of the enterprise) - user certificate (holder Ukey); The system generates a 128-bit random number as the first challenge code (e.g., 8a7f3e9d2b5c104e6g8h9i0j1k2l3m4n) and sends it to Ukey; Ukey uses its private key to perform an SM2 signature on the number, generates a second challenge code (containing the original challenge code and the signature value), and returns it. The system verifies the signature using the certificate's public key (the signature value matches the public key decryption result) and simultaneously verifies the certificate chain (the root certificate is trusted and the certificate has not expired). After successful verification, the system uses the session key to decrypt the local rule base using SM4 and loads it into a tree-like rule set in memory (including sub-nodes for information security compliance identity authentication and sub-nodes for operation and maintenance account permission detection). If verification fails (e.g., the Ukey is forged), the system immediately terminates the process and generates a log (2024-05-20 10:00: Ukey serial number UK202405002 signature verification failed). Step 23, select the inspection command for the mixed scene: In the system interface, select the Level 3 + Operation and Maintenance hybrid detection scenario of Information Security Protection 2.0. The system loads the matching rule nodes, Information Security Protection 8.1.4 identity authentication (requiring user permissions to not exceed job requirements) and operation and maintenance account permission detection (requiring no passwordless administrator users). Each sub-node contains detection indicators (such as the number of users with excessive permissions ≤ 0), standard thresholds, and command templates (such as sudocat / etc / sudoers). The system translates rule nodes into standardized atomic instructions, such as get_sudoers_user (parameter: none, return value: list of user permissions); The CPP adapter translates atomic instructions into adapted instructions based on the Linux CentOS 7 device type, sudocat / etc / sudoers (used to read user permission configurations). Step 24: Send instructions and receive inspection results: The system reads the IP segment 192.168.2.0 / 24 and sends ICMP probe packets to each device (timeout 3 seconds). 18 devices return an echo (determined to be alive), and 2 devices do not return (marked as offline devices and recorded in the log). Port 22 (SSH) connectivity verification packets are sent to the alive devices. All 18 devices have the port open, so proceed to the next step. The system establishes SM4 encrypted communication connections with 18 devices (the key is updated every 10 minutes). The system operates in a 10-device concurrent mode, sending the `sudocat / etc / sudoers` command via an encrypted connection to avoid congestion on a single device. After the device executes the command, it returns the contents of the sudoers file (such as adminALL=(ALL)NOPASSWD:ALL) to the system via an encrypted connection; The system performs dual verification on the results: format verification (containing the keyword ALL=(ALL) and conforming to the preset format) and signature verification (the device signs with its own private key, and the system verifies with the device's public key); 17 devices passed the verification and were encrypted and stored in the local database; 1 device (IP192.168.2.10) had an incorrect result format, and the system triggered a retry mechanism (5-second interval, 3 times in total), and the verification passed after the second retry; if it failed 3 times, it was marked as a device with abnormal results and prompted for manual investigation; Step 25, Calculate the equipment risk score: Taking IP 192.168.2.10 as an example: The system uses multi-level regular expressions to parse its sudoers results. The primary regular expression extracts rootALL=(ALL)ALLadminALL=(ALL)NOPASSWD:ALLwheelALL=(ALL)ALL; the secondary filter excludes NOPASSWD (admin) and the wheel group (wheel), and finally obtains the core user list: root (has ALL privileges and requires a password). Store the information in tags, and assign the following permissions to the account: root (can execute all commands); access control tags: no permission approval process log, 2 sudo failures in the last 7 days; Calculate the tag scores: Account Permissions tag: Root permissions meet the minimum permissions (only 1 administrator), score 90 points; Access Control tag: No approval process, score 40 points; Calculate the compliance ( A =60%, B =40%) S =90×60%+40×40%=54+16=70; According to the formula W =100- S Calculate the risk score: W =100-70=30 (20< W ≤50, medium risk); Step 26, Generate a compliance report: The system maps colors to risk scores. W=30-yellow), generate a heatmap using D3.js, with the X-axis representing compliance dimensions (account permissions, access control) and the Y-axis representing the IPs of 18 devices. The account permission cell for 192.168.2.10 is displayed in yellow, and there are 2 devices ( W =60-Red, High Risk), 15 units ( W =15 - Green, low risk); Clicking the yellow cell for 192.168.2.10 will bring up a details panel, displaying basic device information (IP: 192.168.2.10, hostname: Server10, system: CentOS7, current configuration: root has ALL privileges, standard requirement: ≤0 users with excessive privileges); risk details (risk level: medium risk, compliance terms: Level 3 8.1.4 of Information Security Compliance Standard 2.0, reason: lack of authorization approval process); the system summarizes the heatmap and all panel information, generating a structured PDF report; Step 27, Output a compliance report: Choose local visualization + encrypted export: The local interface displays the report, filters for medium-risk devices, and quickly locates three devices, including 192.168.2.10. Export encrypted PDF reports (password is UkeyPIN code) for submission to regulatory authorities or internal operations and maintenance synchronization, preventing report leakage; Step 28, Generate a repair plan: Taking 192.168.2.10 (medium risk, no approval process) as an example: The system accesses the CBR case library and matches historical cases. The case is a Linux CentOS 7 approval process without permissions (with the same risk type). XT =100%; Equipment type is consistent. YT =100%), calculate similarity: ST =70%×100%+30%×100%=100%, selected as a candidate solution; The system simulates a CentOS 7 environment in a local sandbox and executes repair commands for candidate solutions (such as configuring the / etc / sudoers.d / approval file and adding the permission approval process log path). After the repair, the risk score drops to 15 (low risk), and the commands are compatible with the device. The system outputs a step-by-step repair document: Step 1: Log in to Server10 and execute `vim / etc / sudoers.d / approval`; Step 2: Add `'logfile= / var / log / sudo_approval.log'`; Step 3: Execute `chmod 600 / etc / sudoers.d / approval`; Note: Back up the sudoers file before making changes; Rollback solution: Delete the approval file and restore from backup; If the candidate solutions are ineffective, the system generates a custom template (e.g., it is recommended to contact the IT department to configure the approval system).

[0070] This invention achieves high-security authentication through hardware encryption keys, dynamic session keys prevent unauthorized access, simplify operations, and ensure zero leakage during offline processing. It employs a dual verification system of certificate chains and random challenge codes to prevent certificate forgery; the decrypted rule base is loaded into memory without being stored on the disk, mitigating the risk of leakage and tampering. It supports flexible selection for multiple scenarios such as information security compliance and security assessment, with standardized atomic commands adaptable to multiple devices, eliminating the need for custom development. Device liveness and port verification reduce invalid connections, encrypted communication resists man-in-the-middle attacks, batch concurrency improves inspection efficiency, and result verification and retry mechanisms ensure data accuracy. Risk scoring quantifies account permissions and access control, accurately identifying core risks. Heatmaps visualize risk distribution, with clicks revealing compliance clauses and root causes, and structured reports facilitate auditing. Encrypted export balances security and practicality, case reasoning matches high-similarity remediation solutions, sandbox verification ensures security, and step-by-step documentation lowers the operational threshold. Overall, it achieves a balance between security and efficiency, significantly reducing compliance costs and improving risk response and remediation capabilities.

[0071] like Figure 2 As shown, embodiments of the present invention also provide a network security compliance inspection device 20 for a target device, comprising: Module 21 is used to obtain the digital certificate and session key of the hardware encryption key; Processing module 22 is used to verify the digital certificate. If the verification is successful, it decrypts the local compliance rule base according to the session key; selects the inspection instruction corresponding to the target compliance scenario from the local compliance rule base; sends the inspection instruction to the target device and receives the inspection result returned by the target device according to the inspection instruction; obtains the risk score of the target device according to the inspection result; obtains the compliance report of the target device according to the risk score; and outputs the compliance report of the target device.

[0072] Optionally, the digital certificate is verified. If the verification passes, the local compliance rule base is decrypted based on the session key, including: Read the public key and digital certificate chain from the digital certificate; The first challenge code, which is randomly generated, is sent to the hardware encryption key, and the second challenge code is returned after the hardware encryption key signs the first challenge code. The signature is verified using the public key, and the digital certificate chain is also verified. If the signature verification is successful and the digital certificate chain is valid, the local compliance rule base is decrypted using the session key; otherwise, the inspection process is terminated.

[0073] Optionally, select the inspection instruction corresponding to the target compliance scenario from the local compliance rule base, including: Load rule nodes matching the target compliance scenario from the decrypted local compliance rule base. The target compliance scenario includes: information security level protection detection scenario, security assessment detection scenario, and / or operation and maintenance inspection scenario. Translate the rule nodes into standardized atomic instructions; The standardized atomic instructions are converted into inspection instructions adapted to the target device.

[0074] Optionally, the inspection command is sent to the target device, and the inspection results returned by the target device according to the inspection command are received, including: Send probe packets to the target device to verify its liveness status; After successful verification, an encrypted communication connection with the target device is established; The inspection command is sent to the target device through the encrypted communication connection. Receive the inspection results returned by the target device according to the detection command; The inspection results are verified. If the verification passes, the inspection results are stored locally. Otherwise, the inspection command is resent to the target device, and the inspection results returned by the target device according to the inspection command are accepted until the inspection results pass the verification.

[0075] Optionally, based on the inspection results, a risk score for the target equipment is obtained, including: User information is extracted from the inspection results; The user information is stored in the account allocation permission tag and access control tag; Based on the account, assign permission tags and access control tags to obtain the account permission tag score and access control tag score; The conformity of the target device is obtained based on the account permission tag score and access control tag score. Based on the degree of compliance of the target device, a risk score for the target device is obtained.

[0076] Optionally, based on the risk score, a compliance report for the target device is obtained, including: A heatmap is generated based on the different colors corresponding to the risk scores. Bind click events to cells in the heatmap to obtain compliance reports for the target device.

[0077] Optionally, the above-mentioned inspection device also includes: Based on the inspection results, a repair plan for the target equipment is obtained.

[0078] It should be noted that this device is a device corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0079] Embodiments of the present invention also provide a computing device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0080] Embodiments of the present invention also provide a computing device readable storage medium storing instructions that, when executed on a computing device, cause the computing device to perform the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0081] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computing device software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0082] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0083] In the embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0084] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0085] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0086] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computing device-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computing device software product is stored in a storage medium and includes several instructions to cause a computing device (which may be a personal computing device, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0087] Furthermore, it should be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of the present invention. Moreover, the steps performing the above-described series of processes can naturally be executed in the order described, but are not necessarily required to be executed in chronological order; some steps can be executed in parallel or independently of each other. Those skilled in the art will understand that all or any step or component of the method and apparatus of the present invention can be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or a combination thereof. This is something that those skilled in the art can achieve using basic programming skills after reading the description of the present invention.

[0088] Therefore, the object of the present invention can also be achieved by running a program or a set of programs on any computing device. The computing device can be a known general-purpose device. Therefore, the object of the present invention can also be achieved simply by providing a program product containing program code implementing the method or apparatus. That is, such a program product also constitutes the present invention, and the storage medium storing such a program product also constitutes the present invention. Obviously, the storage medium can be any known storage medium or any storage medium developed in the future. It should also be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent to the present invention. Furthermore, the steps performing the above series of processes can naturally be performed in the order described, but are not necessarily required to be performed in chronological order. Some steps can be performed in parallel or independently of each other.

[0089] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for inspecting network security compliance of a target device, characterized in that, include: Obtain the digital certificate and session key for the hardware encryption key; The digital certificate is verified. If the verification is successful, the local compliance rule base is decrypted based on the session key. Select the inspection instruction corresponding to the target compliance scenario from the local compliance rule base; Send the inspection command to the target device and receive the inspection results returned by the target device according to the inspection command; Based on the inspection results, a risk score for the target equipment is obtained; Based on the risk score, a compliance report for the target equipment is obtained; Output a compliance report for the target device.

2. The network security compliance inspection method for target devices according to claim 1, characterized in that, The digital certificate is verified. If the verification is successful, the local compliance rule base is decrypted based on the session key, including: Read the public key and digital certificate chain from the digital certificate; The first challenge code, which is randomly generated, is sent to the hardware encryption key, and the second challenge code is returned after the hardware encryption key signs the first challenge code. The signature is verified using the public key, and the digital certificate chain is also verified. If the signature verification is successful and the digital certificate chain is valid, the local compliance rule base is decrypted using the session key; otherwise, the inspection process is terminated.

3. The network security compliance inspection method for target devices according to claim 1, characterized in that, Select the inspection instruction corresponding to the target compliance scenario from the local compliance rule base, including: Load rule nodes matching the target compliance scenario from the decrypted local compliance rule base. The target compliance scenario includes: information security level protection detection scenario, security assessment detection scenario, and / or operation and maintenance inspection scenario. Translate the rule nodes into standardized atomic instructions; The standardized atomic instructions are converted into inspection instructions adapted to the target device.

4. The network security compliance inspection method for target devices according to claim 1, characterized in that, Sending the inspection command to the target device and receiving the inspection results returned by the target device according to the inspection command, including: Send probe packets to the target device to verify its liveness status; After successful verification, an encrypted communication connection with the target device is established; The inspection command is sent to the target device through the encrypted communication connection. Receive the inspection results returned by the target device according to the detection command; The inspection results are verified. If the verification passes, the inspection results are stored locally. Otherwise, the inspection command is resent to the target device, and the inspection results returned by the target device according to the inspection command are accepted until the inspection results pass the verification.

5. The network security compliance inspection method for target devices according to claim 1, characterized in that, Based on the inspection results, a risk score for the target equipment is obtained, including: User information is extracted from the inspection results; The user information is stored in the account allocation permission tag and access control tag; Based on the account, assign permission tags and access control tags to obtain the account permission tag score and access control tag score; The conformity of the target device is obtained based on the account permission tag score and access control tag score. Based on the degree of compliance of the target device, a risk score for the target device is obtained.

6. The network security compliance inspection method for target devices according to claim 1, characterized in that, Based on the risk score, a compliance report for the target device is obtained, including: A heatmap is generated based on the different colors corresponding to the risk scores. Bind click events to cells in the heatmap to obtain compliance reports for the target device.

7. The network security compliance inspection method for target devices according to claim 1, characterized in that, Also includes: Based on the inspection results, a repair plan for the target equipment is obtained.

8. A network security compliance inspection device for target devices, characterized in that, include: The acquisition module is used to acquire the digital certificate and session key of the hardware encryption key; The processing module is used to verify the digital certificate. If the verification is successful, it decrypts the local compliance rule base according to the session key and selects the inspection instruction corresponding to the target compliance scenario from the local compliance rule base. Send the inspection command to the target device and receive the inspection results returned by the target device according to the inspection command; Based on the inspection results, a risk score for the target equipment is obtained; Based on the risk score, a compliance report for the target equipment is obtained; Output a compliance report for the target device.

9. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 7.

10. A computing device readable storage medium, characterized in that, The computing device readable storage medium stores a program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images