Safety equipment management and service system and method based on trusted scene

Abstract

The invention belongs to the technical field of Internet of Things, and discloses a safety equipment management and service system and method based on a trusted scene, and the method comprises the steps: obtaining manufacturer basic information and a real-time risk signal, judging a credit level according to a four-level standard, generating a corresponding rectification work order, collecting equipment attributes, signing and issuing a trusted passport, and forming an equipment initial trusted certificate; the scene admission type is judged by combining the batch admission template and the offline rule packet, differential adaptation is executed, and a scene adaptation result is generated; historical experience labels are converted through a cross-domain label mapping table, invalid labels are cleared up, an inheritance trust state is determined, and a trust passport is updated; sandbox simulation is executed on the major strategy, conflicts are arbitrated according to mode priorities, and an arbitration strategy, an execution instruction and an audit log are generated; the trust passport and the manufacturer credit level are updated, trust approval and strategy arbitration rules are optimized, and a closed-loop auditing link is formed.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and more specifically, to a security device management and service system and method based on trusted scenarios. Background Technology

[0002] With the development of the Internet of Things, smart security, and edge computing, the deployment scope of security devices is expanding and cross-scenario migration is frequent. Security incidents such as falsified vendor qualifications and firmware tampering are occurring frequently, requiring enterprises to implement end-to-end trust management. However, current management has shortcomings: vendor credit is not dynamically assessed, and high-risk devices are easily connected; trust is difficult to inherit across devices in different scenarios, and edge environment adaptation is inefficient; policy conflicts are not intelligently resolved, and the entire process lacks a closed loop, making it difficult to balance security, efficiency, and adaptability.

[0003] While existing security device management solutions attempt to address these issues through various technical means, they still have significant shortcomings and cannot fundamentally solve the problems: At the vendor credit management level, they rely heavily on static vendor qualifications for one-time ratings, without considering real-time risks; at the device trust management level, the initial trust status of a device is determined solely based on static attributes such as hardware and firmware, without considering device performance, and is not updated with operational data, making cross-scenario tagging difficult to adapt; at the scenario adaptation level, a unified online verification process is used for batch devices and edge offline devices, resulting in low adaptation efficiency and wasted resources; at the policy execution level, there is a lack of pre-simulation verification for critical policies affecting core business, and direct execution can easily lead to business interruptions. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art and to achieve the above objectives, the present invention provides the following technical solution: a security device management and service system based on trusted scenarios, comprising: Credit governance and trust building module: acquires basic information and real-time risk signals from manufacturers to determine credit rating; if risk conditions are triggered, it performs temporary downgrade and generates corresponding rectification work orders; it synchronously collects device attributes, verifies the initial trust status, issues trust passports, and forms the initial trusted certificate for the device. Scene admission and adaptation execution module: Based on the initial trusted credentials and scene security requirements, combined with the batch admission template and offline rule package, the scene admission type is determined and differentiated adaptation is performed to generate scene adaptation results; Cross-scene tag processing module: When a device migrates across scenes, based on the scene adaptation results and trust passport, it converts historical experience tags, cleans up invalid and aging tags, determines the inherited trust status in combination with the requirements of the new scene, and updates the trust passport; Multi-strategy arbitration audit module: Based on the inherited trust status and multiple strategies to be executed, it performs sandbox simulation on major strategies, arbitrates conflicts according to mode priority, generates arbitration strategies and execution instructions, and records audit logs synchronously; Iterative closed-loop module: Based on audit logs and vendor rectification completion status, update trust passports and vendor credit ratings, optimize trust approval and policy arbitration rules, and form a closed-loop audit link.

[0005] Furthermore, the method for generating the rectification work order includes: Based on the equipment manufacturer's basic information and real-time risk signals, an initial credit rating is given to the manufacturer according to a predefined four-level classification rule that includes a reverse veto item. The system identifies real-time risks for manufacturers by using real-time risk signals. If a risk condition is triggered, the manufacturer's rating is automatically suspended, and the credit rating is temporarily adjusted using temporary downgrade rules to obtain the final credit rating result. Based on the manufacturer's final credit rating, generate a differentiated rectification work order that includes the work order type, triggering conditions, and rectification requirements.

[0006] Furthermore, the method for forming the initial trusted credential of the device includes: Based on the manufacturer's final credit rating, device attribute data is collected, and the device attributes are converted into a firmware security tag set according to predefined tag generation rules. Based on the dual hard condition matching rules of manufacturer credit rating and firmware security tag set, the initial trust status of the device is determined, and a level four approval result is obtained. Based on the initial trust approval results of the equipment, for the two categories of equipment with the lowest approval results, an equipment rectification work order will be triggered; For the two highest-level devices with the highest approval results, a trust passport containing historical scenario experience tags is issued after being stored on the blockchain, forming the initial trusted certificate for the device.

[0007] Furthermore, the method for determining the scene access type includes: The access control types for device access scenarios are divided into three categories: batch access control, edge offline access control, and single online access control, and access control type determination rules are defined for each category. Collect device access characteristic data, obtain the security requirements of the target scenario to which the device is to be connected, combine the device's initial trusted credentials, determine the device scenario access type according to the predefined three types of access type judgment rules, and synchronously generate the corresponding type of adaptation pre-parameters.

[0008] Furthermore, the method for generating the scene adaptation result includes: Perform differentiated adaptation operations based on the access type: For batch access type scenarios, perform batch automated adaptation operations; for edge offline access type scenarios, temporarily store the adaptation results locally and automatically review them after connecting to the network; for single online access type scenarios, perform single real-time adaptation operations. After completing all adaptation operations, the scene adaptation results are summarized and generated.

[0009] Furthermore, the methods for converting historical experience tags and cleaning up invalid and aging tags include: Based on the scenario adaptation results and the trust passport, for cross-domain migration devices, the historical scenario experience tag set in the trust passport is extracted and cross-domain tag conversion is performed through the pre-set cross-domain tag mapping table and migration instructions. For successfully converted tags, a new conversion record is added to the Trust Passport; for tags that fail to convert, manual processing is performed. By using tag aging rules, the historical scene experience tag set after conversion is aged and cleaned up, generating tag cleanup logs and aging tag cleanup reports.

[0010] Furthermore, the method for determining the inherited trust state and updating the trust passport in accordance with the requirements of the new scenario includes: Based on the tag cleanup log and aging tag cleanup report, combined with the security requirements of the target scenario, the experience tag matching degree of the target scenario is obtained, and the real-time operation data score of the device is used as a bonus. The scenario risk level coefficient is obtained and adjusted to obtain the final trust score of the target scenario. The trust status is mapped to the Level 4 approval result based on the interval of the final trust score to obtain the inherited trust status of the device in the new scenario. For the two highest-level devices with the highest approval results, a formal trust passport update operation will be performed, and the data will be synchronized to the blockchain for storage and archiving.

[0011] Furthermore, the method for generating the arbitration strategy and enforcement instructions includes: Based on a pre-set list of multiple strategies to be executed, sandbox simulation verification is performed on the major strategies in the list. If there are no abnormalities, the simulation is deemed to have passed. If there are risks, abnormal handling operations are performed on the major strategies, and a strategy simulation pass report is generated. Obtain the current global operating mode of the system and define the policy arbitration priority rules corresponding to each mode; Based on the device's inherited trust state and updated trust passport, and combined with policy simulation, conflicting policies are identified through reports. The conflicting policies are then arbitrated according to the policy arbitration priority rules of the current operating mode, generating the final arbitration policy and converting it into standardized execution instructions. The entire arbitration process and enforcement instructions are recorded as an audit log and simultaneously stored on the blockchain.

[0012] Furthermore, the methods for updating trust passports and vendor credit ratings, and optimizing trust approval and policy arbitration rules include: Acquire the equipment's operational data throughout its entire lifecycle, combine it with the manufacturer's rectification completion status, update the Trust Passport Contribution Value label according to predefined rules, and restore the credit rating of manufacturers that have rectified to the standard, while downgrading the credit rating of manufacturers that have not rectified to the standard. Optimize the trust status approval and policy arbitration rules by combining audit logs with the requirements of new scenarios; The original label generation rules and trust status determination dual hard condition matching rules are updated by optimizing the trust status approval rules; the original policy arbitration priority rules and conflict determination logic are updated by optimizing the policy arbitration rules, forming a closed-loop audit link.

[0013] Furthermore, the method for managing and serving security devices based on trusted scenarios is characterized by including: S1: Obtain basic information and real-time risk signals from the manufacturer to determine the credit rating; if risk conditions are triggered, execute a temporary downgrade and generate a corresponding rectification work order; simultaneously collect device attributes, verify the initial trust status, issue a trust passport, and form the initial trusted certificate for the device. S2: Based on the initial trusted credentials and scenario security requirements, the scenario access type is determined by combining the batch access template and offline rule package, and differentiated adaptation is performed to generate scenario adaptation results; S3: When a device migrates across scenarios, based on the scenario adaptation results and trust passport, the historical experience tags are converted, invalid and aging tags are cleaned up, the inherited trust status is determined in combination with the requirements of the new scenario, and the trust passport is updated. S4: Based on the inherited trust status and multiple strategies to be executed, perform sandbox simulation on major strategies, arbitrate conflicts according to mode priority, generate arbitration strategies and execution instructions, and record audit logs synchronously. S5: Based on the audit logs and the vendor's rectification completion status, update the trust passport and vendor credit rating, optimize the trust approval and policy arbitration rules, and form a closed-loop audit link.

[0014] The technical effects and advantages of the security device management and service system and method based on trusted scenarios of this invention are as follows: This invention establishes a multi-level dynamic credit rating mechanism to dynamically assess manufacturer credit (corresponding to real-time risk downgrades) and generate differentiated work orders to drive manufacturers to rectify their practices, thereby blocking access to high-risk manufacturers' equipment from the source. On the other hand, it only allows equipment from manufacturers with qualified credit ratings to enter the access process, while generating security tags based on device attributes, verifying the initial trust status, and issuing blockchain trust passports to ensure that the initial trust status of the device is traceable, thus completely solving the problems of static manufacturer credit and lack of credentials for initial device trust.

[0015] Secondly, by automatically determining the admission type (batch / edge offline / single device), batch devices are verified with a single click using templates, edge devices temporarily store the adaptation results locally, and single devices are verified in real time. This differentiated process fully matches the needs of different scenarios and solves the problems of low adaptation efficiency and resource waste in existing solutions.

[0016] Then, by converting historical tags through a cross-domain tag mapping table, cleaning up aging tags, calculating the inherited trust status and updating the passport, and updating the blockchain evidence information, the problem of broken cross-scenario trusted transmission and the need for repeated access is completely solved.

[0017] Next, by first simulating major strategies in a sandbox before execution, using two-factor authentication for authorized personnel in emergency scenarios to quickly switch modes, and using blockchain for evidence storage during the arbitration process, the execution of strategies is ensured to be traceable and tamper-proof, thus solving the problems of existing solutions lacking strategy simulation and having delayed emergency response.

[0018] Finally, by updating the equipment contribution value and manufacturer credit based on operational data, optimizing trust and arbitration rules and injecting them into the preceding processes, a continuous optimization mechanism of problem discovery, rule adjustment, and effect verification is formed, solving the problems of existing solutions lacking closure and having poor adaptability.

[0019] This invention achieves trusted management of security devices from vendor access to the entire lifecycle through end-to-end design, effectively solving the core pain points of existing solutions such as staticity, fragmentation, and lack of closed-loop operation. It is applicable to fields such as smart parks, government security, edge computing, and multi-scenario IoT, significantly improving the trustworthiness, dynamic adaptability, and system robustness of device management. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the security device management and service system based on trusted scenarios according to the present invention; Figure 2 This is a schematic diagram of the vendor credit dynamic rating and work order generation process in the trusted scenario-based security device management and service system of the present invention. Figure 3 This is a schematic diagram of the security device management and service method based on trusted scenarios according to the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example 1

[0022] Please see Figure 1 and Figure 2 As shown in this embodiment, the security device management and service system based on trusted scenarios includes: Credit governance and trust building module: acquires basic information and real-time risk signals from manufacturers, determines credit rating according to a four-level standard; if risk conditions are triggered, a temporary downgrade is executed, and a corresponding rectification work order is generated; simultaneously collects device attributes, verifies the initial trust status, issues a trust passport, and forms the initial trusted certificate for the device; Scene admission and adaptation execution module: Based on the initial trusted credentials and scene security requirements, combined with the batch admission template and offline rule package, the scene admission type is determined and differentiated adaptation is performed to generate scene adaptation results; Cross-scene tag processing module: When a device migrates across scenes, based on the scene adaptation results and trust passport, it converts historical experience tags through the cross-domain tag mapping table, cleans up invalid tags according to the tag aging rules, determines the inherited trust status in combination with the requirements of the new scene, and updates the trust passport. Multi-strategy arbitration audit module: Based on the inherited trust status and multiple strategies to be executed, it performs sandbox simulation on major strategies, arbitrates conflicts according to mode priority, generates arbitration strategies and execution instructions, and records audit logs synchronously; Iterative closed-loop module: Based on audit logs and vendor rectification completion status, update trust passports and vendor credit ratings, optimize trust approval and policy arbitration rules, and form a closed-loop audit link.

[0023] Obtain basic information about equipment manufacturers and real-time risk signals through the corresponding standardized API interfaces; The basic information of equipment manufacturers includes qualification data and operational data: Qualification data includes business license (the business scope must include the production and sale of security equipment, and must be verified through the National Enterprise Credit Information Publicity System), product type inspection report (must be consistent with the information filed on the official website of the Ministry of Public Security Testing Center), and ISO information security certification (must be within the validity period); operational data includes the online rate of equipment in the most recent period (e.g., the last six months) (extracted from the equipment management platform, must cover more than half of the equipment sold by the manufacturer, excluding data of faulty and scrapped equipment), the response time of the most recent (e.g., the last 3 times) security threats (e.g., the duration of the repair feedback after the vulnerability notification, based on the time when the manufacturer submits the repair plan), and the record of major security vulnerabilities in the most recent long period (e.g., the last year) (referring to high-risk vulnerabilities with a CVSS score ≥ 9.0, extracted from the National Vulnerability Database CNNVD and the National Information Security Vulnerability Sharing Platform CNVD, and must include the vulnerability number and repair status); Real-time risk signals include vulnerability warning signals and operation and maintenance reporting signals; Vulnerability warning signals include real-time information on the vendor's equipment pushed by the national vulnerability database (e.g., 0-day vulnerabilities, high-risk vulnerabilities, major security vulnerabilities, etc., with push intervals as short as possible, such as receiving within 1 hour, to ensure timely risk assessment); Operation and maintenance reporting signals include vendor response timeout events reported by system operation and maintenance personnel or users (e.g., equipment failure reported within 48 hours), and clues of qualification fraud verified by authoritative institutions (e.g., market supervision departments, third-party testing institutions) (e.g., forged inspection reports). Based on the equipment manufacturer's basic information and real-time risk signals, an initial credit rating is given to the manufacturer according to a predefined four-level classification rule. Specifically, the rating system is defined as follows: the initial rating is divided into four levels (A / B / C / D) based on the core compliance conditions and the reverse veto items. Among them, the reverse veto item (priority judgment, triggered and directly classified as D level) is defined as: including the existence of major security vulnerabilities that have not been patched, the provision of false qualifications (this item needs to be verified by an authoritative institution), and security incidents caused by equipment security issues within a long period of time (such as 1 year). The rating criteria for Grade A are defined as follows: all core compliance conditions must be met simultaneously, including no major security vulnerabilities in a recent period (e.g., the past six months), threat response time ≤ minimum time threshold (e.g., ≤ 24 hours, and the last 3 times all met the standard), device online rate ≥ maximum online rate threshold (e.g., 99.5%, calculated based on the daily average online rate), and all qualification data are within the validity period; The rating criteria for Grade B are defined as follows: all core compliance conditions must be met simultaneously, including no major security vulnerabilities in a recent period (e.g., the past six months), threat response time ≤ medium time threshold (e.g., ≤ 48 hours, and the last 3 times all met the standard), device online rate ≥ medium online rate threshold (e.g., 98%), and core qualification data (including business license, inspection report) within the validity period; The C-level rating criteria are defined as follows: all core compliance conditions must be met simultaneously, including no major security vulnerabilities in a recent period (e.g., the past six months), threat response time ≤ the maximum time threshold (e.g., ≤ 72 hours, and the last 3 times all met the standard), device online rate ≥ the minimum online rate threshold (e.g., 95%), and business license within the validity period. The rating criteria for Grade D are defined as: failing to meet any of the core compliance conditions for Grade C, or triggering any of the reverse veto conditions; Based on the manufacturer's initial rating, if the manufacturer has real-time risk signals, the manufacturer's risk level is first determined by the risk signal judgment rules, including high-priority risk and medium-priority risk. For high-priority risks, the temporary downgrade rules are immediately implemented, and for medium-priority risks, the temporary downgrade rules are implemented within 24 hours. The risk signal judgment rule is defined as follows: if a 0-day vulnerability exists and the vendor does not release a fix within 24 hours, or if the falsification of qualifications reported by the operation and maintenance is verified, it is judged as a high-priority risk; if a high-risk vulnerability exists and the vendor does not respond within 48 hours, or if the equipment failure is not handled within 72 hours after warranty, it is judged as a medium-priority risk. The temporary downgrade rules are defined as follows: If the original rating is A or B, and a high-priority risk is triggered, the rating will be temporarily downgraded by 1 level (e.g., A → B, B → C). If a medium-priority risk is triggered, the rating will be downgraded by 1 level if the risk is not rectified within 24 hours. If the original rating is C and any risk is triggered, the rating will be temporarily downgraded to D. If the original rating is D and the risk persists, the rating will remain at D, and restrictions on new device access will be added. Based on the manufacturer's final credit rating, a corresponding differentiated rectification work order is generated, specifically: The types of work orders include vendor regular governance work orders, vendor emergency rectification work orders, and vendor exclusion notices; The definition of a vendor’s periodic governance work order is: the final credit rating is C (no real-time risk has been triggered), and rectification (such as improving the equipment online rate to 98% or updating the soon-to-expire inspection report) must be completed within a certain period of time (such as 30 days). The verification standard is that the online rate is ≥ the medium online rate threshold for multiple consecutive times (such as 7 days, 7 consecutive times) and the new inspection report is within the validity period. The triggering condition for an emergency rectification work order from a vendor is defined as follows: the final credit rating is temporarily downgraded due to real-time risks (such as A to B, C to D), and a response (such as providing a vulnerability remediation plan) is required within a short period of time (such as 24 hours) and the rectification is completed within a certain period of time (such as 7 days). The verification standard is that the remediation plan passes third-party testing and the vulnerability retest shows no residual risk. The triggering conditions for a vendor ban notice are defined as follows: the final credit rating is D, and the access of new devices from that vendor must be stopped immediately. Security checks must be initiated on the devices that have already been accessed, and the devices must be replaced or rectified within a certain period of time (e.g., 30 days). The verification standard is that all devices that have been accessed must be replaced with products from compliant vendors, or pass multiple (e.g., 3) consecutive security scans after rectification. The system will automatically push the corresponding work order to the designated contact person of the vendor (real-name authentication is required to prevent fraudulent claims) and copy it to the system operation and maintenance team; within the vendor's rectification period, the vendor needs to upload rectification proof materials (such as vulnerability repair plan, new qualification documents), and the system will automatically verify the authenticity of the materials through the interface (such as verifying that the inspection report number is consistent with the filing of the certification agency, and that the vulnerability repair version is consistent with the version released on the vendor's official website). If the rectification is not completed within the specified period, the rating will be downgraded by one level: C to D, B to C, and D to an extended ban period (e.g., 6 months). At the same time, the manufacturer will be added to the industry's blacklist and the information will be simultaneously uploaded to the regional security equipment procurement platform.

[0024] The methods for forming the initial trusted credentials for a device include: Based on the manufacturer's final credit rating results (only devices with a manufacturer credit rating ≥ B can enter this stage; manufacturers with C and D ratings need to rectify their issues and achieve a rating ≥ B before they can access the system. After rectification, devices can only regain access eligibility after multiple consecutive credit reviews), collect qualified device attribute data, including hardware attributes, firmware attributes, and configuration attributes. The hardware attributes include the device model, hardware root of trust configuration (i.e., whether a hardware root of trust is built-in, such as a TPM2.0 chip), and encryption module support (e.g., whether it is compatible with the AES-256 encryption algorithm); the firmware attributes include the firmware version, security patch update time, and firmware signature verification result (must be an official digital signature from the manufacturer to prevent tampering); the configuration attributes include the default account password modification status (i.e., whether the initial password has been changed) and remote access permission settings (whether only specified IP ranges are allowed to access the device management interface). Based on the acquired device attribute data, the device attributes are converted into a firmware security tag set according to predefined tag generation rules; Specifically, the tag generation rules are defined as follows: tags are divided into four categories: basic security, patch security, enhanced security, and configuration security. Each category of tags only outputs a clear result of whether it conforms or does not conform, yes or no, without any ambiguity. The standard for generating basic security labels is defined as follows: firmware version ≥ the minimum security version officially released by the manufacturer (e.g., if the minimum version set by the manufacturer for this model of device is V2.2, then V2.3.1 is considered compliant, and V2.1 is considered non-compliant). The standard for generating security patch labels is defined as follows: the time since the security patch update is less than or equal to the current operation time (e.g., 90 days; for example, an interval of 83 days is considered yes, and an interval of 203 days is considered no). The standard for generating enhanced security labels is defined as follows: if a device has hardware-level encryption capabilities (such as a built-in TPM 2.0 or independent encryption chip, and can generate and store encryption keys normally), it is considered to support the label; otherwise, it is not supported. The standard for generating security labels is defined as follows: if the default administrator's initial password has been changed and remote access permissions are only allowed to the specified IP range, it is considered as yes; if either condition is not met, it is considered as no. Based on the manufacturer's credit rating and firmware security tag set, the initial trust status of the device is approved according to the predefined dual hard condition matching rules, resulting in a four-level approval result. Specifically, the dual hard condition matching rule is defined as: dividing the approval level into four levels, including high trust, medium trust, low trust and untrust. The high-reliability approval standard is defined as follows: the manufacturer must simultaneously meet the following requirements: a credit rating of A, and basic security label, patch security label, and enhanced security label must all be compliant or supported. The approval standard of Zhongxin Trust is defined as follows: it must simultaneously meet the following requirements: the manufacturer's credit rating is A or B, and both the basic security label and the patch security label are compliant or compliant. The low-reliability approval criteria are defined as follows: the manufacturer credit rating must be B and the basic security label must be compliant and the patch security label must be non-compliant, or the manufacturer credit rating must be A and the basic security label must be compliant and the patch security label must be non-compliant. The untrusted approval criteria are defined as: meeting any of the following conditions: manufacturer credit rating < B, basic security label is non-compliant, or firmware signature verification fails. Based on the initial trust status approval results of the device, generate an initial trust approval report for the device, including the approval results and key evidence (i.e., the corresponding approval standard basis). For equipment with the lowest approval results (i.e., low trust and untrust), trigger an equipment rectification work order; The equipment rectification work order is defined as follows: low-trust equipment must complete the security patch update within a time limit (e.g., 7 days), untrusted equipment must replace compliant firmware / upgrade hardware within 15 days, and equipment that does not meet the standards is prohibited from entering the subsequent scenario access stage; Then, the equipment rectification work order is pushed to the contact person of the unit to which the equipment belongs, and copied to the system operation and maintenance team at the same time. Within the rectification period, the unit to which the equipment belongs needs to upload rectification supporting materials (such as patch update records, firmware upgrade vouchers, hardware replacement documents). The system automatically verifies the authenticity of the materials through the interface (such as verifying whether the patch version matches the latest release from the manufacturer and whether the firmware signature is compliant). If the rectification is not completed within the time limit, the low-trust device will be downgraded to untrusted, and the untrusted device will be subject to additional access restrictions (prohibited from accessing any scenario), and the rectification period will be extended (such as extended to 30 days). For devices with the highest approval levels (i.e., high trust and medium trust), a blockchain-based evidence-based trust passport is issued to form the device's initial trust credential (associated with the trust passport identifier and the corresponding initial trust status). Specifically, the issuance rules for Trust Passports are defined as follows: they only cover highly trusted and medium trusted devices, contain four types of core information (including basic information, associated trust information, tag profiles, and contribution value profiles), and are stored through blockchain (such as Hyperledger Fabric) to ensure immutability; The basic information includes: passport unique identifier, device serial number, issuance date, and validity period (synchronized with the manufacturer's credit rating validity period). The associated trust information includes: the device's initial trust status, the associated vendor's credit rating, and the unique number of the device's initial trust approval report; Tag profile information includes: a complete set of firmware security tags and a set of historical scenario experience tags (initially empty, to be added during subsequent cross-scenario migrations). The contribution value file includes: initial contribution value (including 0 hours of fault-free operation and 0 hours of edge computing service), which will be dynamically updated based on the device operation data.

[0025] The methods for determining the scene access type include: Obtain the security requirements of the target scenario for the device to be connected (including the minimum trust status of the scenario (e.g., medium trust or above), the preset recommended security tag set (e.g., support for motion detection, hardware encryption, etc., not mandatory, only used as a bonus for adaptation), the preset scenario risk level (e.g., high-risk scenario, medium-risk scenario, etc., used for subsequent policy arbitration weight adjustment), and the preset mandatory security tag set (e.g., hardware encryption, adaptation must meet, otherwise it will fail directly)). Collect device access characteristic data (including the number of devices (statistics based on the actual deployment list, excluding backup devices), network status of the deployment area (such as network stability, weak network environment, offline environment, etc.), and device model uniformity (model duplication rate ≥90% is considered uniform, i.e., ≤1 out of 10 devices are different models)). Based on the combination of device access characteristic data, target scenario security requirements, and initial trusted credentials of the device, the device access scenario is classified according to predefined access type determination rules; The rules for determining the access type are defined in three categories: The criteria for classifying batch access types are: the number of devices is greater than or equal to the expected number (e.g., 10 units) and the models are uniform (e.g., 50 campus cameras of the same model), and the target scene has been configured with a batch access template (the template includes the preset minimum trust status of the scene and recommended security labels). The criteria for classifying edge offline access types are: the device is deployed in a weak network environment or an offline environment (such as a mountain base station or a remote checkpoint), and the device has cached offline data packets of the trust passport (including firmware security tag set and initial trust state) locally, and has cached offline rule packets of target scenario security requirements (including minimum trust state and recommended security tags). The criteria for classifying a single online access type are: not meeting any of the conditions for batch access type and edge offline access type; When performing the judgment operation, first verify the matching degree between the device access characteristics and the admission type judgment rules: for batch devices, the model list needs to be read to confirm the uniformity, and for edge devices, the network signal strength needs to be detected (if the signal strength is <-85dBm for 5 consecutive minutes, it is judged as a weak network); for abnormal situations that cannot be automatically identified (such as unclear device model or network status fluctuation), trigger the manual review process, and the judgment result is supplemented after confirmation by the operation and maintenance personnel; Finally, the device scenario access type and the corresponding adaptation prerequisite parameters are obtained (including the template ID to be called for batch access, the cache version number to be verified for edge offline access, and the scenario interface address to be bound for single online access).

[0026] The methods for generating scene adaptation results include: Collect real-time status data of the device, including the device's current online status (online or offline), the network connection quality between the device and the system (e.g., bandwidth ≥10Mbps is good, <10Mbps is poor), and the device's hardware operating status (e.g., CPU utilization <80% is normal, ≥80% is overload). Based on the access type, the corresponding scenario adaptation process is executed, specifically: For batch admission scenarios, the adaptation operation is to perform batch automated adaptation. Specifically: Based on the template ID in the adaptation pre-parameters, load the batch access template for the corresponding scenario (e.g., batch template for park monitoring). Based on the list of devices to be adapted (including device SN code and trust passport identifier), associate the initial trusted credentials of each device, and then verify them one by one, including trust status verification and tag matching verification; Among them, the trust status verification is to determine whether the initial trust status of the device is greater than or equal to the minimum trust status of the scenario (e.g., medium trust is greater than or equal to medium trust to pass); the tag matching verification is to determine whether the firmware security tag of the device trust passport contains the security tag required by the scenario (e.g., support for TLS1.3 and the presence of motion detection are both required to pass). The verification results are categorized as pass or fail: For scenarios that pass the verification, a scenario access permit is automatically generated, and the device information is entered into the target scenario's device management list. The scenario experience tag set of the trust passport is updated synchronously (adding tags for the target scenario name and access time). For scenarios that fail the verification, a batch of abnormal device work orders are generated for the reasons for failure (e.g., insufficient trust status, missing required tags). The work orders clearly indicate the SN code of each abnormal device, the reason for failure, and the rectification requirements (e.g., insufficient trust status requires upgrading the firmware to V2.3). The batch of abnormal equipment work orders will be pushed to the real-name authenticated contact person of the unit to which the equipment belongs, and copied to the system operation and maintenance team at the same time. The contact person must complete the rectification within the time limit (e.g., 7 days) and upload supporting materials (e.g., firmware upgrade records). After the materials are verified, the adaptation will be retried. For adaptation operations in edge offline access scenarios, the adaptation results are first temporarily stored locally and then automatically reviewed after connecting to the network. Specifically: The device automatically performs local adaptation verification based on the locally cached scenario security requirement offline rule package and trust passport offline data package, including trust status verification and tag matching verification; Among them, the trust status verification is to compare the initial trust status of the device with the minimum trust status of the scene locally; the tag matching verification is to compare the trust passport tag with the scene security tag locally. If the adaptation is successful, an offline temporary access credential will be generated locally; if the adaptation fails, the reason for the failure will be recorded locally and marked in the device's local log. When the device detects that the network has recovered (for example, network availability ≥ 60% for 5 minutes), it automatically synchronizes the local adaptation results (offline access temporary certificate and reason for failure) to the system for review. If the review passes, the system confirms the validity of the temporary credential and that the local verification logic is consistent with the online rules, then converts the offline access temporary credential into a formal scenario access permit and updates the trust passport label. If the review fails, the latest version of the scenario security requirement rule package is pushed to the device, and the device re-executes local adaptation and then synchronizes the results again. If the device fails the review multiple times (e.g., ≥3 times) after connecting to the network, an edge offline device review work order is generated, and the operation and maintenance personnel need to conduct on-site investigations (e.g., check the integrity of cached data and network stability). After the investigation is completed, the re-adaptation is manually triggered. For adaptation operations in single-machine online access control scenarios, real-time adaptation is performed on a single machine. Specifically: The maintenance personnel manually enter the SN code or trust passport identifier of the device to be adapted, and then retrieve the device's initial trusted credentials and real-time status data to perform three verifications, including trust status verification (initial trust status ≥ minimum trust status of the scenario), tag matching verification (firmware security tags include the scenario's required tags), and operating status verification (device online, good network connection, no hardware overload (all three are met to pass)). If the verification passes, a scene access permit for a single device is immediately generated and synchronized to the target scene. If the verification fails, the reason for the failure is displayed in real time (e.g., poor network connection, hardware overload). After the maintenance personnel make adjustments according to the prompts (e.g., optimize the network, reduce the device load), the verification is triggered again through re-adaptation. In addition, regardless of whether the adaptation passes or fails, a single device adaptation log (including adaptation time, verification result, and operator) is recorded. The log is associated with the device trust passport for subsequent auditing and traceability. After all adaptation operations are completed, the final results are summarized to generate standardized scenario adaptation results, including a scenario adaptation result report (containing the total number of adapted devices, the number of successful devices and the success rate, the number of unsuccessful devices and the classification of reasons for failure, and the adaptation time), associated documents (containing batch abnormal device work orders and edge offline device review work orders generated when adaptation fails, and including rectification deadlines, responsible persons, and acceptance standards), device access identifiers (a unique scenario access identifier generated for successfully adapted devices, the identifier being associated with the device SN code, target scenario ID, and access validity period (synchronized with the trust passport validity period)), and trust passport update records (update records of the scenario experience tag set and contribution value file of the trust passport for successfully adapted devices (e.g., adding a new park monitoring scenario access tag, adding a successful scenario access + 10 points record to the contribution value file).

[0027] Methods for converting historical tags using cross-domain tag mapping tables and cleaning up invalid tags according to tag aging rules include: The cross-domain tag mapping table is defined as being pre-configured by the administrator and generated based on industry-unified standards or cross-regional collaboration protocols. It includes the original domain tag, the target domain tag, and the mapping priority. For example, the original domain type is financial domain, the original domain scenario tag is financial branch security, the target domain type is government domain, the target domain scenario tag is government hall security, and the mapping priority is 1 (highest); the original domain type is municipal domain, the original domain scenario tag is municipal river inspection, the target domain type is campus domain, the target domain scenario tag is campus perimeter inspection, and the mapping priority is 2. The device cross-domain migration specification document is defined as being submitted by the user, specifying the original domain type, target domain type, reason for migration (e.g., temporary relocation for campus expansion), and the name of the target scenario to be accessed after migration, which serves as the scenario matching basis for cross-domain tag conversion; Based on the scenario adaptation results and the trust passport, for cross-domain migration devices, the historical scenario experience tag set in the trust passport is extracted using a pre-built cross-domain tag mapping table and migration instructions, and a cross-domain tag conversion operation is performed. Specifically: Extract all historical scene experience tags from the Trust Passport and classify them according to the original domain type (e.g., classify financial branch security and municipal river inspection into the financial domain and municipal domain, respectively). Based on the original domain type and target domain type in the migration instructions, match the corresponding rules in the cross-domain label mapping table. For example, when a device is migrated from the financial domain to the campus domain, the original label "financial branch security" matches the rules of the financial domain → campus domain in the mapping table and is converted to "government hall security" accordingly. (If the target scenario is "smart campus perimeter security", then it is further determined whether "government hall security" is compatible with the target scenario label. If compatible, it is retained; if incompatible, it is marked as pending manual adjustment.) For successfully converted tags, a conversion record (including the original tag, converted tag, mapping rule version, and conversion time) is added to the Trust Passport; for tags that fail to convert (e.g., due to mapping rule priority conflicts (such as multiple target tags corresponding to the same original tag) or incompatibility with the target scenario), a tag conversion exception list is generated and pushed to the operations team, where the final converted tag is determined manually. Update the historical scenario experience tag set of Trust Passport based on the converted tags; Based on the tag aging rules, the transformed historical scene experience tag set is aged and cleaned up, generating a tag cleanup log and an aging tag cleanup report. Specifically: Iterate through all historical scene experience tags after conversion, query the last usage time of the tag, calculate the interval from the current time, set the time interval range, if the interval is greater than or equal to the maximum time interval range (e.g., 24 months), mark it as a tag to be aged; if the interval is greater than or equal to the minimum time interval range (e.g., 20 months) but less than the maximum time interval range, mark it as a tag about to be aged, and push an aging warning reminder to the unit to which the device belongs, reminding the user to reuse the tag as much as possible within a certain period (e.g., 4 months) to avoid aging; For tags marked as awaiting aging, a tag aging and cleanup reminder will be sent to the unit to which the equipment belongs. Users can submit an objection application within a limited period (e.g., 3 days) (i.e., explain the reasons for retention, such as the equipment corresponding to the tag having participated in a major security incident and needing to be retained as historical evidence). If there are no objections, the tags to be aged will be deleted from the historical scene experience tag set of the trusted passport after the deadline has expired. At the same time, the cleaning time, tag name and cleaning reason will be recorded in the tag cleaning log. If there is any objection, the objection application and the information of the tag to be aged will be synchronized to the operation and maintenance team. After manual review, it will be determined whether to retain or forcibly remove it. If it is determined to retain, a retention mark (including the retention period) will be added to the tag. If it is determined to forcibly remove, the removal will be carried out according to the no-objection process. After the cleanup is completed, update the label cleanup log of the Trust Passport and generate an aging label cleanup report, which includes the number of labels cleaned, the number of labels retained, and the results of objection handling. The report is then pushed to the device owner and the maintenance team for record-keeping.

[0028] The methods for determining the inherited trust state and updating the trust passport in light of the new scenario requirements include: Acquire real-time device operation data, including the device's online status (online / offline) after migration to a new scenario, hardware health (e.g., CPU utilization <80% is normal, ≥80% is overload), and fault-free operation time in the recent period (e.g., 7 days) (used to supplement the calculation of inherited trust status). Based on the tag cleanup log and aging tag cleanup report, combined with the target scenario's security requirements and the device's real-time operating data, the target scenario's experience tag matching degree is obtained, and the device's real-time operating data score is used as a bonus. The scenario risk level coefficient is obtained and adjusted to obtain the final trust score for the target scenario. Specifically, extract recommended experience tags for the target scenario (extract the most relevant experience tags based on the business objectives of the target scenario, such as perimeter security experience, video encrypted transmission experience, etc.). Then, iterate through the historical scene experience tag set, count the number of fully matching tags and the number of partially matching tags, and then perform weighted fusion calculation to obtain the experience tag matching score of the target scene (maximum score of 80 points, corresponding to a high-confidence base score). Example: The target scene recommends 2 tags, and the historical tags have 1 exact match and 1 partial match. The score = 1 × 60% + 1 × 40% = 100% (equivalent to 80 points). The score is calculated based on the preset equipment operating status and the real-time operating data of the equipment (maximum score 20 points). The pre-set rules for bonus points for equipment operation are defined as follows: 10 points for ≥168 hours of fault-free operation in the past 7 days (7 full days), 5 points for ≥99% online rate, and 5 points for no hardware overload, with a maximum score of 20 points (corresponding to the upper limit of trust status +1). It should be noted that the rules for bonus points for equipment operation can be freely defined based on the actual situation and expert experience.

[0029] The scenario risk level coefficient is a predefined value. For example, the coefficient for high-risk scenarios is 1.2, the coefficient for medium-risk scenarios is 1.0, and the coefficient for low-risk scenarios is 0.8. The final trust score is obtained by multiplying (experience tag matching degree + device real-time operation data score) by the scenario risk level coefficient. Example: If the target scenario is high-risk (coefficient 1.2), then the final trust score for the target scenario = (80 + 20) × 1.2 = 120 points; The trust status is mapped to the Level 4 approval result based on the range of the final trust score to obtain the inherited trust status of the device in the new scenario; among them, 100-120 points correspond to high trust, 80-99 points correspond to medium trust, 60-79 points correspond to low trust, and <60 points correspond to untrust. If the judgment result is lower than the minimum trust status of the target scenario (e.g., the target scenario requires medium trust, but the judgment result is low trust), an insufficient inheritance trust status work order will be generated, specifying the conditions that need to be supplemented (e.g., one more fully matching recommendation tag needs to be added), and pushed to the unit to which the device belongs. Example: The final score is 120 points, and the judgment result is high trust, while the minimum trust state of the target scenario is medium trust, which meets the admission requirements; For the two highest-level devices with the highest approval results, a formal trust passport update operation will be performed, and the data will be synchronized to the blockchain for storage and archiving. Specifically, for devices identified as highly trusted or moderately trusted, a formal update of the trust passport is performed to ensure that the passport information is compatible with the new scenario. The specific steps are as follows: In the historical scenario experience tag set of the Trust Passport, add the target scenario name + inherited access time tag (e.g., Smart Campus Perimeter Security_20240905). Synchronously update the last usage time of tags, and record the generation time and first reuse time of newly added tags (i.e., the current inheritance admission time). Based on real-time equipment operation data, update the contribution value file: the nearly 7 days of fault-free operation time is added to the total fault-free operation time. If the equipment participates in edge computing power services, the edge computing power contribution time is added simultaneously. Example: The original total fault-free runtime was 600 hours, with an additional 168 hours added, updating to 768 hours; Update the current trust status field in the trust passport from the initial trust status to the inherited trust status of this determination (e.g., from moderately trustworthy to highly trustworthy). Added a new inherited trust status update record, including update time, judgment score, update executor, and associated target scenario ID; The updated trust passport generates a hash value and is synchronized to a blockchain evidence storage system (such as Hyperledger Fabric) to overwrite the original evidence storage record and ensure that the passport information cannot be tampered with. Generate a blockchain-based evidence update certificate, which includes the evidence hash value, update time, and is associated with a unique identifier in the trust passport for subsequent audit and verification.

[0030] Arbitration strategies and methods for generating enforcement orders include: Obtain a pre-defined list of multiple strategies to be executed, generated by the scenario manager. The list includes the strategy name, strategy type (e.g., security isolation - disconnecting non-core device networks, business continuity - ensuring monitoring data transmission, energy efficiency optimization - adjusting device sleep duration), strategy scope (e.g., covering 10 core devices, only affecting edge nodes), and strategy execution conditions (e.g., triggered when network bandwidth < 50Mbps). Based on the pre-set list of multiple strategies to be executed, extract the predefined major strategies (e.g., those affecting ≥10 core devices or involving uninterrupted services) from the list of multiple strategies to be executed. Based on the basic data of the sandbox simulation tool, construct a virtual operating environment consistent with the target scenario to restore the real conditions such as the number of devices, network bandwidth, and service load. Input the major strategies to be executed into the sandbox, simulate the execution time, and monitor key indicators in real time, including business indicators (the running status of uninterrupted services (such as whether video transmission is stuck or data is lost), and service response latency) and equipment indicators (CPU utilization of core devices and network bandwidth usage). If there are no service interruptions, equipment overloads, or other anomalies during the simulation, the simulation is considered successful. If an anomaly occurs (such as a 10-second video transmission interruption), the cause of the anomaly is analyzed (e.g., the network cutoff range is too large, mistakenly including core equipment), the policy parameters are adjusted (e.g., the range of devices cutoff is reduced), and the simulation is repeated until it passes or it is confirmed that the policy cannot be executed in the current scenario. The key indicators, simulation success records, and anomaly handling records are integrated to generate a policy simulation success report and associated with the policy to be executed. Obtain the current global operating mode of the system (manual authorization is required for switching, including daily mode, security mode, and emergency mode), and define the policy arbitration priority rules corresponding to each mode; The priority rules for each mode are predefined and cannot be modified arbitrarily. The specific priority definitions are as follows: In daily operations, the weighting is: Business Continuity (40%) > Energy Efficiency Optimization (30%) > Security Isolation (30%); in security operations, the weighting is: Security Isolation (50%) > Business Continuity (35%) > Energy Efficiency Optimization (15%); and in emergency operations, the weighting is: Security Isolation (60%) > Business Continuity (25%) > Energy Efficiency Optimization (15%). Based on the device's inherited trust state and the updated trust passport, and combined with policy simulation, conflicting policies (such as the contradiction between cutting off the network and ensuring data transmission) are identified through reports. The conflicting policies are then arbitrated according to the policy arbitration priority rules of the current operating mode, generating the final arbitration policy and converting it into standardized execution instructions. Specifically, conflict strategies are first categorized into security isolation, business continuity, and energy efficiency optimization, and the priority weight of each strategy under the current operating mode is marked. If different priority strategies conflict, that is, if the conflicting strategies belong to different types (e.g., security isolation and business continuity), the priority weight of the current operating mode shall be used to determine the higher priority strategy as the candidate arbitration strategy. For example, in the security mode, if the security isolation strategy (weight 50%) > the business continuity strategy (weight 35%), then the security isolation strategy shall be selected. If arbitration is used for policies of the same priority, that is, conflicting policies belong to the highest priority (such as two security isolation policies), then: The first step is to compare the impact range of the strategies and select the strategy that affects fewer core devices. The second step is to compare the device trust status compatibility and select the strategy with a higher coverage ratio of highly trusted devices if the impact range is consistent. The third step, if it still cannot be determined, triggers manual confirmation (pushed to the scene manager), and generates candidate arbitration strategies after manual selection; Check whether the candidate arbitration policy matches the device's inherited trust state (e.g., low-trust devices are not allowed to execute flexible security policies). If they do not match, adjust the policy parameters (e.g., change flexible to fixed) or replace it with a suboptimal priority policy. The final selected arbitration strategy is converted into a standardized execution instruction, which includes instruction ID, a list of executing devices, parameter configuration (e.g., network disconnection duration of 2 hours, bandwidth allocation threshold of 10Mbps), and an exception callback mechanism (e.g., automatically triggering a backup strategy when execution fails). This ensures that low-trust devices only execute fixed security policies, while high-trust devices can execute flexible policies. The entire arbitration process and enforcement instructions will be recorded as an audit log and simultaneously stored on the blockchain for evidence. Specifically, audit logs should include log ID, recording time, conflict policy pair, priority determination basis, simulation report summary, and execution instruction details; The logs are hashed and synchronized to a blockchain evidence storage system (such as Hyperledger Fabric) to overwrite the original records and generate log evidence certificates (including evidence hash and time).

[0031] The methods for updating trust passports and vendor credit ratings, and optimizing trust approval and policy arbitration rules include: Acquire full-cycle operational data of the device (fault-free runtime, edge computing service duration, number of abnormal alarms, and historical update records of trust passport contribution value within a recent period (e.g., the last 3 months); Simultaneously, obtain the vendor's rectification completion status after executing the vendor's emergency rectification work order and vendor's regular governance work order (including the processing status of the vendor's emergency rectification work order and vendor's regular governance work order (completed / incomplete), the rectification supporting materials submitted by the vendor (such as vulnerability remediation plan, new qualification documents), and the system verification results (passed / failed)); Based on the equipment's full lifecycle operation data and the manufacturer's rectification completion status, the contribution value label of the trust passport is updated according to predefined rules, and the credit rating is adjusted according to the manufacturer's rectification results; Specifically, the predefined contribution value update rule logic is defined as follows: add or subtract points based on fault-free uptime, edge computing service time, and number of abnormal alarms; Example update rules: 5 points for every 100 hours of trouble-free operation, 3 points for every 50 hours of edge computing service, and 2 points for every reduction in abnormal alarms, with a maximum score of 50 points (exceeding the maximum score is recorded as 50 points). For example: 300 hours of trouble-free operation (+15 points) + 100 hours of computing service (+6 points) + 2 reductions in alarms (+4 points), for a total of 25 points, the original score of 30 points is updated to 50 points; The manufacturer credit rating adjustment rule logic is defined as follows: If the rectification meets the standards and there are no new risks within a certain period of time (such as 3 months), the original rating will be automatically restored (such as A-level → B-level temporary downgrade followed by restoration to A-level), and the matching weight of its equipment tags will be increased simultaneously (0.9 → 1.0); for manufacturers that have not completed rectification or have failed verification, the credit rating will be downgraded by another level (such as C-level → D-level), and a longer period of prohibition will be added, such as a 6-month restriction on the access of new equipment; Obtain audit logs (including arbitration process and execution results) and new scenario requirements (such as vehicle-road collaboration tags for smart transportation); Optimize the trust status approval and policy arbitration rules by combining audit logs with the requirements of new scenarios; Specifically, the trust status approval rules are optimized as follows: if the audit log shows that low-trust devices still frequently trigger alarms when executing policies, the label requirements for the label generation rules are increased (e.g., firmware version changes from V2.3 to V2.4); new label types are added to the dual hard condition matching rules according to new scenario requirements (e.g., vehicle-road cooperative experience labels, low-latency transmission labels), and the label generation rules are clarified (e.g., labels can be generated if the device has participated in vehicle-road cooperative testing for ≥100 hours). The strategy arbitration rules have been optimized as follows: the effectiveness of strategy conflict resolution under different operating modes is statistically analyzed. If the business interruption rate is high in emergency mode, the priority is adjusted (e.g., the business continuity weight is changed from 25% to 30%). In response to the slow response of edge devices, a fast channel for edge devices has been added to the strategy arbitration rules: highly reliable edge devices can skip some sandbox simulation steps (e.g., the simulation time is shortened from 2 hours to 30 minutes) and directly enter the arbitration process. The original label generation rules and the dual hard condition matching rules for trust status determination are updated by optimizing the trust status approval rules; the original policy arbitration priority rules and conflict determination logic are updated by optimizing the policy arbitration rules, forming a closed-loop audit link. Specifically, the optimized trust rules will replace the original tag generation standard (e.g., add vehicle-road cooperative tag generation logic) and update the hard conditions for trust determination (e.g., high trust requires additional satisfaction of the new tag). The optimized arbitration rules update the priority of the mode (such as adjusting the business weight of the emergency mode) and the conflict determination logic (such as prioritizing the matching of fast channel rules for edge devices). For connected devices, if the new rules affect their existing trust status (such as the requirement to upgrade the tag), a reminder to reassess the device's trust status will be pushed. The device will be automatically reassessed according to the new rules within a time limit (such as 15 days). Devices whose trust status drops after the reassessment need to generate a device rectification work order. Associated manufacturer credit → Device trust passport → Scenario adaptation record → Arbitration log → Rule optimization record, generate a trust closed-loop audit report, generate a hash value with the report and full-link data, synchronize it to blockchain for evidence storage (such as Hyperledger Fabric), and open a traceability query portal; If rule injection fails, it will automatically retry. If it fails multiple times (e.g., 3 times), a rule injection failure work order will be generated, and the operation and maintenance personnel will handle it and inject it again. The optimization effect (e.g., equipment failure rate, arbitration success rate) will be statistically analyzed regularly (e.g., every month). If the results do not meet expectations, a new round of optimization will be triggered. Example 2

[0032] Please see Figure 3 As shown, parts not described in detail in this embodiment are described in Embodiment 1. A method for security device management and services based on trusted scenarios is provided, including: S1: Obtain basic information and real-time risk signals from the manufacturer to determine the credit rating; if risk conditions are triggered, execute a temporary downgrade and generate a corresponding rectification work order; simultaneously collect device attributes, verify the initial trust status, issue a trust passport, and form the initial trusted certificate for the device. S2: Based on the initial trusted credentials and scenario security requirements, the scenario access type is determined by combining the batch access template and offline rule package, and differentiated adaptation is performed to generate scenario adaptation results; S3: When a device migrates across scenarios, based on the scenario adaptation results and trust passport, the historical experience tags are converted, invalid and aging tags are cleaned up, the inherited trust status is determined in combination with the requirements of the new scenario, and the trust passport is updated. S4: Based on the inherited trust status and multiple strategies to be executed, perform sandbox simulation on major strategies, arbitrate conflicts according to mode priority, generate arbitration strategies and execution instructions, and record audit logs synchronously. S5: Based on the audit logs and the vendor's rectification completion status, update the trust passport and vendor credit rating, optimize the trust approval and policy arbitration rules, and form a closed-loop audit link. Example 3

[0033] This embodiment discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the operation mode of the security device management and service system based on trusted scenarios described above.

[0034] Since the electronic device described in this embodiment is the electronic device used to implement the trusted scenario-based security device management and service method in this application embodiment, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the trusted scenario-based security device management and service method described in this application embodiment. Therefore, how the electronic device implements the method in this application embodiment will not be described in detail here. Any electronic device used by those skilled in the art to implement the trusted scenario-based security device management and service method in this application embodiment falls within the scope of protection of this application.

[0035] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0036] The above description is merely a preferred embodiment of the present invention, and the scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for users of ordinary technical skills, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A security device management and service system based on trusted scenarios, characterized in that, include: Credit governance and trust building module: Obtain basic information and real-time risk signals from vendors to determine their credit rating; If a risk condition is triggered, a temporary downgrade will be executed, and a corresponding rectification work order will be generated. Simultaneously, device attributes will be collected, the initial trust status will be verified, a trust passport will be issued, and an initial trusted credential for the device will be formed. Scene admission and adaptation execution module: Based on the initial trusted credentials and scene security requirements, combined with the batch admission template and offline rule package, the scene admission type is determined and differentiated adaptation is performed to generate scene adaptation results; Cross-scene tag processing module: When a device migrates across scenes, based on the scene adaptation results and trust passport, it converts historical experience tags, cleans up invalid and aging tags, determines the inherited trust status in combination with the requirements of the new scene, and updates the trust passport; Multi-strategy arbitration audit module: Based on the inherited trust status and multiple strategies to be executed, it performs sandbox simulation on major strategies, arbitrates conflicts according to mode priority, generates arbitration strategies and execution instructions, and records audit logs synchronously; Iterative closed-loop module: Based on audit logs and vendor rectification completion status, update trust passports and vendor credit ratings, optimize trust approval and policy arbitration rules, and form a closed-loop audit link.

2. The security device management and service system based on trusted scenarios according to claim 1, characterized in that, The methods for generating the rectification work order include: Based on the equipment manufacturer's basic information and real-time risk signals, an initial credit rating is given to the manufacturer according to a predefined four-level classification rule that includes a reverse veto item. The system identifies real-time risks for manufacturers by using real-time risk signals. If a risk condition is triggered, the manufacturer's rating is automatically suspended, and the credit rating is temporarily adjusted using temporary downgrade rules to obtain the final credit rating result. Based on the manufacturer's final credit rating, generate a differentiated rectification work order that includes the work order type, triggering conditions, and rectification requirements.

3. The security device management and service system based on trusted scenarios according to claim 2, characterized in that, The method for forming the initial trusted credential of the device includes: Based on the manufacturer's final credit rating, device attribute data is collected, and the device attributes are converted into a firmware security tag set according to predefined tag generation rules. Based on the dual hard condition matching rules of manufacturer credit rating and firmware security tag set, the initial trust status of the device is determined, and a level four approval result is obtained. Based on the initial trust approval results of the equipment, for the two categories of equipment with the lowest approval results, an equipment rectification work order will be triggered; For the two highest-level devices with the highest approval results, a trust passport containing historical scenario experience tags is issued after being stored on the blockchain, forming the initial trusted certificate for the device.

4. The security device management and service system based on trusted scenarios according to claim 3, characterized in that, The methods for determining the scene access type include: The access control types for device access scenarios are divided into three categories: batch access control, edge offline access control, and single online access control, and access control type determination rules are defined for each category. Collect device access characteristic data, obtain the security requirements of the target scenario to which the device is to be connected, combine the device's initial trusted credentials, determine the device scenario access type according to the predefined three types of access type judgment rules, and synchronously generate the corresponding type of adaptation pre-parameters.

5. The security device management and service system based on trusted scenarios according to claim 4, characterized in that, The methods for generating the scene adaptation results include: Perform differentiated adaptation operations based on the access type: For batch access type scenarios, perform batch automated adaptation operations; for edge offline access type scenarios, temporarily store the adaptation results locally and automatically review them after connecting to the network; for single online access type scenarios, perform single real-time adaptation operations. After completing all adaptation operations, the scene adaptation results are summarized and generated.

6. The security device management and service system based on trusted scenarios according to claim 5, characterized in that, The methods for cleaning up invalid and aging tags in the conversion history experience tags include: Based on the scenario adaptation results and the trust passport, for cross-domain migration devices, the historical scenario experience tag set in the trust passport is extracted and cross-domain tag conversion is performed through the pre-set cross-domain tag mapping table and migration instructions. For successfully converted tags, a new conversion record is added to the Trust Passport; for tags that fail to convert, manual processing is performed. By using tag aging rules, the historical scene experience tag set after conversion is aged and cleaned up, generating tag cleanup logs and aging tag cleanup reports.

7. The security device management and service system based on trusted scenarios according to claim 6, characterized in that, The methods for determining the inherited trust state and updating the trust passport in accordance with the requirements of the new scenario include: Based on the tag cleanup log and aging tag cleanup report, combined with the security requirements of the target scenario, the experience tag matching degree of the target scenario is obtained, and the real-time operation data score of the device is used as a bonus. The scenario risk level coefficient is obtained and adjusted to obtain the final trust score of the target scenario. The trust status is mapped to the Level 4 approval result based on the interval of the final trust score to obtain the inherited trust status of the device in the new scenario. For the two highest-level devices with the highest approval results, a formal trust passport update operation will be performed, and the data will be synchronized to the blockchain for storage and archiving.

8. The security device management and service system based on trusted scenarios according to claim 7, characterized in that, The methods for generating the arbitration strategy and enforcement instructions include: Based on a pre-set list of multiple strategies to be executed, sandbox simulation verification is performed on the major strategies in the list. If there are no abnormalities, the simulation is deemed to have passed. If there are risks, abnormal handling operations are performed on the major strategies, and a strategy simulation pass report is generated. Obtain the current global operating mode of the system and define the policy arbitration priority rules corresponding to each mode; Based on the device's inherited trust state and updated trust passport, and combined with policy simulation, conflicting policies are identified through reports. The conflicting policies are then arbitrated according to the policy arbitration priority rules of the current operating mode, generating the final arbitration policy and converting it into standardized execution instructions. The entire arbitration process and enforcement instructions are recorded as an audit log and simultaneously stored on the blockchain.

9. The security device management and service system based on trusted scenarios according to claim 8, characterized in that, The methods for updating trust passports and vendor credit ratings, and optimizing trust approval and policy arbitration rules include: Acquire the equipment's operational data throughout its entire lifecycle, combine it with the manufacturer's rectification completion status, update the Trust Passport Contribution Value label according to predefined rules, and restore the credit rating of manufacturers that have rectified to the standard, while downgrading the credit rating of manufacturers that have not rectified to the standard. Optimize the trust status approval and policy arbitration rules by combining audit logs with the requirements of new scenarios; The original label generation rules and trust status determination dual hard condition matching rules are updated by optimizing the trust status approval rules; the original policy arbitration priority rules and conflict determination logic are updated by optimizing the policy arbitration rules, forming a closed-loop audit link.

10. A method for managing and serving security devices based on trusted scenarios, implemented based on the trusted scenario-based security device management and service system according to any one of claims 1 to 9, characterized in that, include: S1: Obtain basic information about the manufacturer and real-time risk signals to determine the credit rating; If a risk condition is triggered, a temporary downgrade will be implemented, and a corresponding rectification work order will be generated. Synchronously collect device attributes, verify the initial trust status, issue a trust passport, and form the initial trusted certificate for the device; S2: Based on the initial trusted credentials and scenario security requirements, the scenario access type is determined by combining the batch access template and offline rule package, and differentiated adaptation is performed to generate scenario adaptation results; S3: When a device migrates across scenarios, based on the scenario adaptation results and trust passport, the historical experience tags are converted, invalid and aging tags are cleaned up, the inherited trust status is determined in combination with the requirements of the new scenario, and the trust passport is updated. S4: Based on the inherited trust status and multiple strategies to be executed, perform sandbox simulation on major strategies, arbitrate conflicts according to mode priority, generate arbitration strategies and execution instructions, and record audit logs synchronously. S5: Based on the audit logs and the vendor's rectification completion status, update the trust passport and vendor credit rating, optimize the trust approval and policy arbitration rules, and form a closed-loop audit link.

Images