Trusted cloud level standardization framework system and quantitative mapping method

Abstract

The application belongs to the technical field of information security, and provides a trusted cloud level standardization framework system and a quantitative mapping method, which is executed by one or more processors deployed on a server or an authentication platform, is based on a predefined trusted cloud level standardization framework system and a unified data security level measurement, and comprises the following steps: a receiving step of receiving qualitative security control items from an external standardization framework; and an automatic process of "parsing-mapping-evaluating-generating" for converting the external qualitative control items into digital levels based on the unified measurement, which not only improves the traditional compliance judgment from binary qualitative to fine quantitative, realizes accurate comparison of security capabilities, but also provides a core technical path for realizing automatic compliance evaluation, generating intuitive and trusted credit scores, and constructing an end-to-end verifiable supply chain trust system.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, specifically a trusted cloud level standardization framework system and quantitative mapping method. Background Technology

[0002] In recent years, with the widespread application of cloud computing technology and the deepening of digital transformation, the security, trustworthiness and compliance of cloud services have become the focus of attention for all industries. To ensure the security of data and applications in the cloud environment, various organizations at home and abroad have successively launched a variety of information security standards, compliance frameworks and technical specifications, such as ISO / IEC 27001, NIST Cybersecurity Framework (CSF) Level Protection 2.0, and Cloud Security Alliance (CSA) Cloud Control Matrix (CCM), forming a situation of multiple systems coexisting. These standards are usually mainly qualitative descriptions, focusing on proposing security control items and requirements, aiming to guide cloud service providers to build and improve security capabilities from multiple dimensions such as management, technology and operation.

[0003] However, existing technologies have also exposed several prominent problems in practical applications. On the one hand, the lack of unified semantic alignment and quantitative benchmarks among different standard systems has led to challenges such as system conflicts, redundant assessments, and ambiguities in understanding when enterprises deal with multiple requirements. On the other hand, most standards are still at the level of qualitative compliance judgment, making it difficult to conduct a refined and comparable quantitative assessment of the security strength of specific cloud service technologies.

[0004] The direct consequences of these problems are that enterprises invest heavily and spend a long time on cloud security compliance, yet find it difficult to obtain accurate and comparable security capability assessments; cloud service users lack intuitive and reliable security level references when selecting services, resulting in high decision-making costs; and regulatory and auditing agencies also find it difficult to achieve automated and standardized compliance checks and continuous supervision.

[0005] To this end, the present invention provides a standardized framework system for trusted cloud levels and a quantitative mapping method. Summary of the Invention

[0006] In order to overcome the shortcomings of the prior art, at least one technical problem raised in the background art is solved.

[0007] The technical solution adopted by this invention to solve its technical problem is: a Trusted Cloud Level Standardization Quantization Mapping Method, which is executed by one or more processors deployed on a server or authentication platform, based on a predefined Trusted Cloud Level Standardization Framework System and a unified data security level measurement standard, and includes the following steps:

[0008] Receiving steps: Receive qualitative security control items from an external standardized framework;

[0009] Parsing and mapping steps: The received qualitative security control items are parsed and semantically analyzed to extract key security requirements, and the requirements are compared and mapped with the Trusted Cloud Level Standardization Framework System;

[0010] Quantitative assessment steps: Combining the specific technical implementation details of the cloud service instance to be assessed, the technical implementation parameters are matched with the corresponding technical points in the underlying technical implementation standards of the Trusted Cloud Level Standardization Framework System, and a quantitative assessment is carried out based on the data security level.

[0011] Generation and output steps: Based on the quantitative assessment results, generate a digital trusted cloud security level for the qualitative security control items and output a structured report.

[0012] As a further aspect of the present invention: the parsing and mapping steps are based on a pre-built, continuously optimized knowledge graph, which establishes semantic associations between external standard control items and the mid-level core mechanisms and underlying specific technical requirements of the Trusted Cloud Level Standardization Framework System.

[0013] The standardized quantitative mapping method for trusted cloud levels includes the following steps:

[0014] It receives qualitative security control item descriptions from external security standards or compliance frameworks, performs semantic parsing, and extracts the demand intensity of these items for N predefined core security capability dimensions based on a pre-built standard-security capability knowledge graph, generating an N-dimensional security requirement vector.

[0015] Obtain the security technical measures implemented by the cloud service to be evaluated to meet the security control items, map the technical measures to the core security capability dimensions, and evaluate the implementation level of each technical measure in each relevant dimension based on the quantitative benchmark in the underlying technology implementation standard of the Trusted Cloud Level Standardization Framework System.

[0016] By aggregating and calculating the implementation levels of all technical measures across all dimensions, a security supply vector is generated that has the same dimensions as the security requirement vector and represents the actual security capabilities of the cloud service.

[0017] Based on the security demand vector and the security supply vector, the dynamic correlation matching degree between the two is calculated through a penalty matching algorithm, and the dynamic correlation matching degree is converted into a quantifiable trusted cloud security level through a preset mapping rule.

[0018] The output includes a quantitative security assessment report containing the trusted cloud security level and dynamic correlation matching degree.

[0019] As a further aspect of the present invention: the process of obtaining the security requirement vector:

[0020] The qualitative safety control item description text is preprocessed and subjected to deep semantic parsing to extract the safety action object, safety action and constraint conditions;

[0021] The extracted safety action objects, safety actions, and constraints are used as query inputs for matching and reasoning in a pre-built standard-safety capability knowledge graph.

[0022] Based on the query results, the knowledge graph outputs the demand intensity value of the control item for each core security capability dimension;

[0023] Aggregate the intensity values ​​of the requirements for all core security capability dimensions to form a security requirement vector.

[0024] As a further aspect of the present invention: the process of obtaining the security supply vector:

[0025] Obtain the specific safety technical measures implemented to meet safety control requirements;

[0026] Based on a predefined technical measure-capability dimension mapping table, each technical measure is deconstructed and mapped to one or more core security capability dimensions;

[0027] For each technical measure, an independent score is given based on the quantitative benchmark in the underlying technical implementation standard of the Trusted Cloud Level Standardization Framework System for each dimension it maps to obtain a single-dimensional implementation level value.

[0028] For each core security capability dimension, a preset aggregation strategy is applied to aggregate and calculate the single-dimensional implementation level values ​​of all technical measures contributing to that dimension, thereby obtaining the comprehensive capability level value for the corresponding dimension.

[0029] The comprehensive capability level values ​​of all dimensions are aggregated to form the security supply vector.

[0030] As a further aspect of the present invention: the process of obtaining dynamic association matching degree:

[0031] Calculate the similarity coefficient between the security demand vector and the security supply vector, i.e., the cosine similarity between the security demand vector and the security supply vector;

[0032] For each dimension, the overall weakness level is represented by a value based on the demand intensity value and the actual capability level value.

[0033] The dynamic association matching degree is calculated based on the similarity coefficient, the overall weakness degree characterization value, and the preset penalty coefficient.

[0034] As a further aspect of the present invention: calculate the difference between the demand intensity value and the actual capability level value; if the difference is positive, it is identified as a weakness.

[0035] Calculate the average difference between the dimensions of the shortest board and use it as a characterization of the overall degree of shortness.

[0036] As a further aspect of the present invention: the preset penalty coefficient is multiplied by the overall weakness characterization value, and the penalty factor is obtained by subtracting the product value from 1;

[0037] The dynamic association matching degree is the product of the similarity coefficient and the penalty factor.

[0038] A Trusted Cloud Level Standardization Framework System, wherein the system is a data framework and processing engine with a three-layer logical structure stored on a computer-readable medium, comprising:

[0039] A top-level objective framework is used to define the macro-level set of objectives for a trusted cloud and to define alignment with the principles of authoritative industry technology organizations.

[0040] The mid-layer core mechanism standard is used to standardize and classify the core technology concepts of Trusted Cloud Root, Trusted Cloud Kernel, Trusted Cloud Management Unit, and Trusted Cloud Hierarchy.

[0041] The underlying technology implementation standards are used to provide specific and operable technical implementation guidance for the implementation of the mid-level core mechanism standards.

[0042] As a further aspect of the present invention: the standardized framework system is configured as a quantitative mapping engine, which receives qualitative security control items from an external standardized framework, compares and semantically maps the requirements of the qualitative security control items with the mid-layer core mechanism standards and the underlying technology implementation standards, and generates a digital trusted cloud security level as a quantitative evaluation result based on a unified measurement standard for data security level.

[0043] The beneficial effects of this invention are as follows:

[0044] This invention constructs a unified framework that covers macro-level compliance objectives, clarifies core technical requirements, and provides specific implementation guidelines through a three-layer standardized design of top-level objectives, mid-level core mechanisms, and bottom-level technical implementation. It integrates various security requirements that were originally scattered and qualitative into a clear, hierarchical, and scalable organic whole, fundamentally solving the system chaos and compliance duplication problems caused by the coexistence of multiple standards, and providing a unified language and benchmark for global cloud security assessment.

[0045] This invention, through an automated process of "analysis-mapping-evaluation-generation," transforms external qualitative control items into digital levels based on a unified standard of measurement. This not only elevates traditional compliance judgments from binary qualitative to refined quantitative, enabling precise comparison of security capabilities, but also provides verifiable technical evidence for the evaluation results. This provides a core technical path for achieving automated compliance assessment, generating intuitive and credible credit scores, and building an end-to-end verifiable supply chain trust system.

[0046] This invention deconstructs external qualitative control items into security requirement vectors and cloud service technology implementations into security supply vectors, transforming the complex many-to-many mapping problem of control items and mechanisms into a problem of quantitative matching in a multi-dimensional vector space. This fundamentally optimizes the dilemma of coarse mapping granularity and incomplete coverage caused by relying on static rules or fixed weights. It can characterize the differentiated requirements of a control item for multiple security dimensions, as well as the composite contribution of a technical measure to multiple dimensions.

[0047] This invention calculates the overall similarity, and more importantly, applies a quantitative penalty to any weaker dimension in the supply vector that is lower than the demand intensity. This limits the final matching degree to the weakest link, effectively suppressing the one-sidedness of the evaluation results and ensuring the balance and comprehensiveness of security capabilities.

[0048] This invention uses structured and quantifiable data for the input, intermediate results, and final output of the evaluation process. The output evaluation report not only includes simple rating numbers but also provides a detailed comparative analysis of demand and supply across various core security capability dimensions. This greatly enhances the transparency of the evaluation process, the credibility of the results, and the interpretability of the conclusions. It facilitates users' in-depth understanding of the strengths and weaknesses of security capabilities and provides a clear basis for subsequent security improvements and accurate decision-making. Attached Figure Description

[0049] The invention will now be further described with reference to the accompanying drawings.

[0050] Figure 1 This is a module architecture diagram of Embodiment 1 of the present invention;

[0051] Figure 2 This is a flowchart of the steps in Embodiment 2 of the present invention;

[0052] Figure 3 This is a flowchart of the steps in Embodiment 3 of the present invention. Detailed Implementation

[0053] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0054] Example 1: Please refer to Figure 1 As shown in the embodiments of the present invention, the Trusted Cloud Level Standardization Framework System is a data framework and processing engine stored on a computer-readable medium with a clear logical structure. The system aims to provide a unified and quantifiable benchmark for cloud security and compliance assessment. The core architecture includes the following three layers:

[0055] Top-level goal framework:

[0056] The top-level objective framework serves as the guiding principle for the entire Trusted Cloud Degree Standardization Framework System (TCDSS), defining the set of macro-level objectives that a trusted cloud needs to achieve. These objectives include, but are not limited to:

[0057] Security: Ensuring the core capabilities of cloud services in terms of confidentiality, integrity, and availability;

[0058] Trustworthiness: Establish a verifiable and measurable chain of trust from the hardware root to application services;

[0059] Compliance: Ensure that the technical practices of cloud services meet or reflect the requirements of laws, regulations and industry standards globally and in various regions;

[0060] Interoperability: Ensures secure interaction and collaboration between cloud services implemented using different technologies and conforming to this framework;

[0061] The top-level framework does not exist in isolation, but rather clearly defines alignment with the principles advocated by authoritative industry technology organizations such as the Trusted Computing Group (TCG), the Cloud Security Alliance (CSA), the China Cloud Computing Standards Association, and the Cloud Native Computing Foundation (CNCF), thereby ensuring the framework's advanced nature and broad acceptance.

[0062] Mid-level core mechanism standards:

[0063] The mid-layer core mechanism standard is the key layer in TCDSS that transforms core concepts into assessable and tiered requirements. It standardizes and tiers definitions of a series of core technical concepts that constitute the foundation of a trusted cloud, mainly including:

[0064] Trusted Root Cloud (TCDR): Defines the source for establishing initial trust, covering different types such as hardware root of trust (such as TPM, HSM) and software root of trust, and provides hierarchical regulations for security attributes (such as password strength and anti-attack capabilities) and the entire lifecycle management process.

[0065] Trusted Cloud Kernel (TCDKN): Defines the security and trust requirements that the core infrastructure of a cloud platform (such as hypervisors and container runtimes) must meet;

[0066] Trusted Cloud Management Unit (TCDMU): Defines the security standards of at least one component or subsystem in a cloud service that is responsible for managing identity, access, configuration, and key security elements;

[0067] Trusted Cloud Classification (TCDization): Defines a general methodology and criteria for assessing the security levels of the aforementioned core mechanisms and other cloud objects (such as networks, applications, and data);

[0068] For each core mechanism, this layer specifies clear, tiered security requirements, management processes, and essential conditions, providing a direct basis for quantitative assessment.

[0069] Underlying technology implementation standards:

[0070] The underlying technical implementation standards constitute the practical layer of TCDSS, aiming to provide specific and actionable technical guidance for the engineering implementation of the mid-layer core mechanism standards. This layer mainly includes:

[0071] The Single Technology Security Mechanism (TCDTSM) guide clarifies that any complex security mechanism can be broken down into specific, assessable single technology points (e.g., key length for a particular algorithm, certificate issuance strategy, etc.), and provides methods for assessing the level of these technology points.

[0072] Security Configuration List: Provides security configuration benchmarks that meet the requirements of different TCDx levels for mainstream cloud platform components, operating systems, and middleware;

[0073] Secure Coding Standards and Test Cases: Provides a guide to secure coding practices for cloud service development, along with corresponding secure test cases to verify whether the implementation meets the framework requirements;

[0074] Furthermore, the standardized framework system is configured as a quantitative mapping engine. The engine can receive qualitative security control items from external standardized frameworks (such as ISO / IEC 27001, NIST Cybersecurity Framework (CSF), Cloud Security Alliance (CSA) Cloud Control Matrix (CCM), etc.). The engine's internal processing logic intelligently compares and semantically maps the textual requirements of the external control items with the predefined mid-level core mechanism classification and underlying technical implementation requirements in TCDSS. The core logic of the mapping process is based on a unified and objective core metric, Data Security Level (DSL). DSL is a five-level scale (DSL1 Public to DSL5 Top Secret) that objectively classifies data based on a common data sensitivity baseline (rather than specific ownership or scenario). Through the mapping and quantification process, the engine ultimately generates corresponding digital Trusted Cloud Security Levels (TCDx) for the external qualitative control items as accurate quantitative assessment results.

[0075] This embodiment constructs a unified framework that covers macro-level compliance objectives, clarifies core technical requirements, and provides specific implementation guidelines through a three-tiered standardized design of top-level objectives, mid-level core mechanisms, and bottom-level technical implementation. It integrates various previously scattered and qualitative security requirements into a clear, hierarchical, and scalable organic whole, fundamentally solving the system chaos and compliance duplication problems caused by the coexistence of multiple standards, and providing a unified language and benchmark for global cloud security assessment.

[0076] Example 2: Based on the foregoing examples, please refer to... Figure 2 As shown, the Trusted Cloud Level Standardization Quantization Mapping Method described in this embodiment of the invention can be executed by one or more processors deployed on a server or authentication platform. The method includes the following steps:

[0077] Step S10: Receive external qualitative control items;

[0078] It receives one or more qualitative security controls from the first standardized framework as input, either from the user or automatically crawled.

[0079] The first type of standardization framework can be an international standard (such as ISO / IEC 27001), a national or industry framework (such as NIST CSF, Cybersecurity Classified Protection 2.0), or an industry organization standard (such as CSA CCM). The input format can be a structured control item ID and description text (for example, input “NIST CSF PR.AC-4: Access Control to External Systems” and detailed requirements text).

[0080] Step S20: Parse and map to the TCDSS framework;

[0081] One or more processors perform natural language parsing and semantic analysis on the received qualitative control items to extract key security requirements;

[0082] The processor compares and maps the extracted requirements with TCDSS, which is the second standardization framework;

[0083] Specifically, the mapping process is based on a pre-built, continuously optimized rule base and knowledge graph;

[0084] Among them, the knowledge graph establishes the relationship between external standard control items and the core mechanisms of TCDSS (such as TCDAC access control, TCDCA authentication, and TCDIS isolation) and the specific technical requirements at the underlying level;

[0085] For example, for the requirement of access control to external systems, the processor may simultaneously map it to multiple core mechanism standards of TCDSS, such as "TCDAC (access control mechanism)," "TCDCA (authentication mechanism)," and "TCDIS (network isolation)."

[0086] Step S30: Conduct a quantitative evaluation based on technical implementation;

[0087] The processor does not only perform text mapping; it also needs to be evaluated in conjunction with the technical implementation details of the specific cloud service instance to be evaluated.

[0088] It can receive or query the specific technical measures adopted by the cloud service to meet the control items in step S10;

[0089] Optional specific technical measures include: whether to adopt a hardware root of trust, whether to implement multi-factor authentication, the completeness of audit logs, and whether to use confidential computing technology, etc.

[0090] The processor matches the specific technical measures parameters with the corresponding technical points in the TCDSS underlying technical implementation standard for level assessment. The assessment process strictly follows the unified standard of data security level (DSL).

[0091] For example, for access control of DSL4 (confidential) level data, if the technical implementation includes strong authentication and two-way filtering based on hardware root of trust, then according to the underlying TCDSS standard, the implementation can be rated as a higher TCD4 level.

[0092] Step S40: Generate and output the quantization level results;

[0093] Based on the evaluation results of step S30, the processor generates a final, quantifiable, and digitized Trusted Cloud Security Level (TCDx) for the external qualitative control items.

[0094] The evaluation results replace the traditional binary judgment of "compliant / non-compliant", and the output can be in the form of a structured report;

[0095] Example: Output report: For the [NIST CSF PR.AC-4] control item, the current service implementation has reached TCD4 level after quantitative evaluation by the TCDSS framework;

[0096] This rating has a clear meaning, indicating that it can provide verifiable security guarantees of a corresponding strength for data at a specific DSL level.

[0097] The method described in this embodiment can be further extended to end-to-end trusted supply chain authentication. By applying the above-mentioned quantitative mapping method to each layer (hardware, virtualization, platform, application) of the cloud service supply chain, and then taking the lowest value of each layer's level according to the "barrel principle", the overall Trusted Cloud Service Level (TCDSVCx) of the cloud service can be calculated. The TCDSVCx level can serve as an intuitive cloud service "credit score", providing end users with a clear and comparable reference for security capabilities, thereby reducing the user's selection and evaluation costs.

[0098] This embodiment transforms external qualitative control items into digital grades (TCDx) based on the Unified Standard (DSL) through an automated process of "parsing-mapping-evaluation-generation". This not only upgrades the traditional compliance judgment from binary qualitative to refined quantification and enables accurate comparison of security capabilities, but also provides the evaluation results (TCDx grades) with verifiable technical evidence. This provides a core technical path for achieving automated compliance assessment, generating intuitive and credible credit scores, and building an end-to-end verifiable supply chain trust system.

[0099] Example 3: Based on the foregoing examples, please refer to... Figure 3 As shown in the embodiment of the present invention, the Trusted Cloud Level Standardization Quantization Mapping Method, when mapping external qualitative security control items to the Trusted Cloud Level Standardization Framework System (TCDSS), suffers from inherent defects in traditional rule-based or static weight-based mapping methods due to the complex many-to-many relationship between external control items and internal core mechanisms. These defects include coarse mapping granularity, incomplete dimensional coverage, and easily biased evaluation results. A further optimized implementation scheme is provided, which reconstructs and enhances the "parsing and mapping" step (S20) and the "quantization evaluation" step (S30).

[0100] It also includes the following steps:

[0101] Step 1: Accept qualitative security control item descriptions from external security standards or compliance frameworks, perform semantic parsing, and extract the demand intensity for N predefined core security capability dimensions based on a pre-built standard-security capability knowledge graph to generate an N-dimensional security requirement vector.

[0102] The specific execution process of step one is as follows: receive qualitative security control item description text from user input, automatic collection or standardized interface, preprocess the text, including format standardization, irrelevant character filtering and extraction of structured fields (such as control item ID, name, description text);

[0103] A natural language processing engine powered by one or more processors performs deep semantic analysis on the preprocessed descriptive text;

[0104] Specifically, the parsing process includes word segmentation, part-of-speech tagging, dependency parsing, and domain keyword identification to extract the security action objects (such as data, systems, and users), security actions (such as encryption, control, monitoring, and auditing), and constraints (such as mandatory, risk-based, and continuous) involved in the control items.

[0105] The extracted safety action objects, safety actions, and constraints are used as query inputs and matched and reasoned in a pre-built and continuously updated standard-safety capability knowledge graph.

[0106] Specifically, the standard-security capability knowledge graph stores the semantic relationships and strength weights between external standard control items, security concepts, and N core security capability dimensions in a graph structure.

[0107] Each core security capability dimension is an orthogonal security capability atomic unit defined based on the systematic deconstruction and abstraction of the mid-level core mechanisms and underlying technical implementation standards of the Trusted Cloud Level Standardization Framework (TCDSS). These include, but are not limited to: cryptographic strength (C1), access control granularity (C2), isolation enforcement (C3), audit integrity (C4), and identity protection strength (C5).

[0108] Based on the query results, the knowledge graph outputs the demand intensity value of each core security capability dimension for the control item. The demand intensity value is a quantified value within a predefined range (such as [0,1]), which represents the degree of dependence of this control item on the capability of this dimension.

[0109] Aggregate the demand intensity values ​​for all N core security capability dimensions to form an ordered N-tuple, which constitutes the security demand vector for that control item. Where r is the demand intensity value and N is the number of dimensions;

[0110] For example, for the qualitative security control item "implement end-to-end encryption for all sensitive data in transit", after processing, the security requirement vector may be R=(0.95, 0.1, 0.7, 0.3, 0.2); this indicates that: this control item has extremely high requirements for cryptographic strength (C1) (0.95), is highly correlated with data isolation (C3) (0.7), and has weak correlation with access control (C2), auditing (C4), and identity strength (C5). The security requirement vector is calculated by inputting the parsed key elements (object: "sensitive data in transit", action: "encryption", constraint: "end-to-end") into the knowledge graph, and by the predefined semantic association rules and weights within the graph.

[0111] Step one introduces semantic parsing and vectorized representation based on knowledge graphs to transform the original unstructured, qualitative text descriptions into structured, multi-dimensional quantitative demand vectors. This fundamentally optimizes the problem of coarse mapping granularity and inability to accurately depict the multi-dimensional security connotations of control items caused by relying on simple keyword matching or fixed rules.

[0112] Step 2: Obtain the security technical measures implemented by the cloud service to be evaluated to meet the security control items. Based on the security capability dimension in the security requirement vector, map the technical measures to the corresponding dimensions, and evaluate the implementation level of each technical measure in each relevant dimension according to the quantitative benchmark in the TCDSS underlying technical implementation standard.

[0113] The specific execution process of step two is as follows: obtain the set of specific security technical measures declared by the cloud service provider to be evaluated in order to meet the security control items;

[0114] The methods for obtaining the set of security technical measures include, but are not limited to: automatically collecting and analyzing security configuration documents and architecture diagrams submitted by service providers through standardized security capability declaration interfaces, or having the certification body conduct technical interviews and on-site verifications during the assessment process. All obtained technical measures must be verified for authenticity and effectiveness to ensure that they have been deployed and are effective in the actual operating environment.

[0115] Each verified security technical measure is analyzed and deconstructed to identify one or more core security capability dimensions that directly contribute. This process is based on a predefined "technical measure-capability dimension" mapping table, which is an important component of the underlying technical implementation standards of the TCDSS framework.

[0116] For example: A technical measure of "encrypting stored data using the AES-256-GCM algorithm" has a primary contribution dimension of cryptographic strength (C1) and may have a secondary contribution to data isolation (C3);

[0117] For example: A measure to “implement a role-based access control policy in which all permission changes require two-person approval” primarily contributes to access control granularity (C2) and audit integrity (C4).

[0118] For each core security capability dimension mapped to each technical measure, the implementation level of the measure in that dimension is independently scored based on the quantitative benchmark defined in the TCDSS underlying technical implementation standard corresponding to that dimension.

[0119] Quantitative benchmarks typically include objective technical parameter thresholds, necessary management processes, or specific configurations that meet specific DSL (Data Security Level) requirements;

[0120] For example, for the cryptographic strength (C1) dimension, the benchmark may specify that the encryption algorithm strength must reach AES-256 or equivalent or higher to protect DSL4 data; for the audit integrity (C4) dimension, the benchmark may specify that audit records must be tamper-proof, centrally stored and retained for at least 180 days.

[0121] The evaluation result represents the achievement level of this technical measure in terms of dimensions;

[0122] Among them, the achievement level value is usually a scalar based on the degree of compliance with the benchmark (for example, 0 indicates that the minimum requirement is not met, 1 indicates that the benchmark requirement is fully met, and 0.5 indicates that it is partially met).

[0123] Output a structured dataset that records the mapping relationship between each technical measure and the core security capability dimensions it contributes, as well as the single-dimensional implementation level value of the corresponding measure in each corresponding dimension.

[0124] Step 3: Through the aggregation calculation of all technical measures in each dimension, a security supply vector that is identical in dimension to the security requirement vector and represents the actual security capability of the cloud service is generated;

[0125] The specific execution process of step three is as follows: For each core security capability dimension, obtain the single-dimensional implementation level value of all technical measures contributing to that dimension;

[0126] Based on the characteristics of each dimension, a preset aggregation strategy is applied to calculate the comprehensive capability level value of that dimension, thereby generating a security supply vector.

[0127] Example of aggregation strategy:

[0128] Maximum value strategy: Applicable to capability-enhancing dimensions, where multiple measures can improve the same capability in parallel;

[0129] The minimum value (barrel principle) strategy is applicable to basic security dimensions, where the weakness of any link will determine the upper limit of the overall capability.

[0130] Logic and strategy: Applicable to mandatory requirements that must be fully satisfied;

[0131] Weighted average strategy: Applicable to capabilities composed of multiple measures, weights can be assigned according to the importance or coverage of the measures;

[0132] Performing the above aggregation calculation on all N core security capability dimensions yields ordered N-tuples, which constitute the security provision vector of the cloud service for the current control item. Where S is the comprehensive ability level value;

[0133] The security supply vector comprehensively characterizes the actual capability level of cloud services across all core security capability dimensions in order to meet this control item.

[0134] Step 4: Based on the security demand vector and the security supply vector, calculate the dynamic correlation matching degree between the two through a penalty matching algorithm, and convert the calculated dynamic correlation matching degree into a quantifiable trusted cloud security level through a preset mapping rule.

[0135] The specific execution process of step four is as follows: using the security demand vector and security supply vector generated above as input, the dynamic correlation matching degree between the two is calculated through a penalty matching algorithm;

[0136] The calculation process of dynamic association matching degree is as follows: the similarity coefficient is obtained by calculating the sum of the numerical products of the security demand vector and the security supply vector in each corresponding dimension and then performing a ratio operation with the product of the magnitudes of the two vectors.

[0137] The similarity coefficient reflects the degree of conformity between the security capabilities of cloud services and the security requirements of standard control items in their overall structure.

[0138] For each dimension, the difference between the demand intensity value and the actual capability level value is calculated. If the difference is positive, it indicates that there is a weakness. The system calculates the average of all differences for all dimensions with weaknesses, which is used as the overall weakness degree characterization value.

[0139] The product of the preset penalty coefficient and the overall weakness degree characterization value is calculated, and the product value is subtracted from 1 to obtain the penalty factor.

[0140] The dynamic association matching degree is obtained by multiplying the similarity coefficient and the penalty factor.

[0141] The calculated dynamic correlation matching degree is input into a preset mapping rule table and converted into a discrete and quantifiable trusted cloud security level.

[0142] The mapping rule table defines the correspondence between the matching degree numerical range and the final grade;

[0143] For example, a complete five-level mapping rule can be defined as follows:

[0144] When the dynamic association matching degree is greater than or equal to 0.9, it is mapped to the highest level 5 (TCD5), indicating that the security capabilities of the cloud service fully and at a high level meet the requirements of the control items, with no significant shortcomings.

[0145] When the dynamic association matching degree is greater than or equal to 0.8 but less than 0.9, it is mapped to the fourth level (TCD4), indicating that the security capability basically meets the requirements, but there are slight gaps in some non-core dimensions or implementation strength.

[0146] When the dynamic association matching degree is greater than or equal to 0.6 but less than 0.8, it is mapped to the third level (TCD3), indicating that the security capability has met the main requirements, but there are perceptible deficiencies in several dimensions.

[0147] When the dynamic association matching degree is greater than or equal to 0.4 but less than 0.6, it is mapped to the second level (TCD2), indicating that it can only meet the most basic and core requirements of the control items, and there is a significant shortcoming in security capabilities.

[0148] When the dynamic correlation matching degree is less than 0.4, it is mapped to the lowest first level (TCD1), indicating that there is a serious gap between the security capabilities and the standard requirements, and most dimensions have not been effectively met.

[0149] The output includes a quantitative security assessment report that includes the trusted cloud security level and dynamic correlation matching degree.

[0150] This embodiment deconstructs external qualitative control items into security requirement vectors and cloud service technology implementations into security supply vectors, transforming the complex many-to-many mapping problem of control items and mechanisms into a problem of quantitative matching in a multi-dimensional vector space. This fundamentally optimizes the dilemma of coarse mapping granularity and incomplete coverage caused by relying on static rules or fixed weights, and can characterize the differentiated requirements of a control item for multiple security dimensions, as well as the composite contribution of a technical measure to multiple dimensions.

[0151] This embodiment calculates the overall similarity, and more importantly, applies a quantitative penalty to any weaker dimension in the supply vector that is lower than the demand intensity. This limits the final matching degree (and the mapping level) to the weakest link, effectively suppressing the one-sidedness of the evaluation results and ensuring the balance and comprehensiveness of security capabilities.

[0152] This embodiment uses structured and quantifiable data for the input (demand vector), intermediate results (supply vector, scores for each dimension), and final output (matching degree, level) of the evaluation process. The output evaluation report not only includes simple level numbers, but also provides a detailed comparative analysis of demand and supply across various core security capability dimensions. This greatly enhances the transparency of the evaluation process, the credibility of the results, and the interpretability of the conclusions, making it easier for users to deeply understand the strengths and weaknesses of security capabilities and providing a clear basis for subsequent security improvements and accurate decision-making.

[0153] It should be noted that Embodiments 2 and 3 above respectively demonstrate different implementation granularities of the quantization mapping method of the present invention. Those skilled in the art will understand that Embodiment 2 provides a general and efficient implementation path, while Embodiment 3 provides an optimized path that pursues higher accuracy and interpretability. In actual systems, the above methods can be flexibly selected or combined according to the complexity and real-time requirements of the evaluation scenario.

[0154] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A standardized quantitative mapping method for trusted cloud levels, characterized by: The method is executed by one or more processors deployed on a server or authentication platform, based on a predefined trusted cloud level standardization framework system and a unified data security level metric, and includes the following steps: The system receives qualitative security control item descriptions from the standard security framework and performs semantic parsing. Based on a pre-built standard-security capability knowledge graph, it extracts the demand intensity of the qualitative security control items for N predefined core security capability dimensions and generates an N-dimensional security demand vector. The knowledge graph establishes a semantic association between the standard security control items and the mid-layer core mechanisms and underlying technology implementation standards of the Trusted Cloud Level Standardization Framework System. Obtain the security technical measures implemented by the cloud service to be evaluated to meet the security control items, map the technical measures to the core security capability dimensions, and evaluate the implementation level of each technical measure in each relevant dimension based on the quantitative benchmark in the underlying technology implementation standard of the Trusted Cloud Level Standardization Framework System. By aggregating and calculating the implementation levels of all technical measures across all dimensions, a security supply vector is generated that has the same dimensions as the security requirement vector and represents the actual security capabilities of the cloud service. Based on the security demand vector and the security supply vector, the dynamic correlation matching degree between the two is calculated through a penalty matching algorithm, and the dynamic correlation matching degree is converted into a quantifiable trusted cloud security level through a preset mapping rule. The output includes a quantitative security assessment report containing the trusted cloud security level and dynamic correlation matching degree.

2. The trusted cloud level standardized quantization mapping method according to claim 1, characterized in that: The process of obtaining the security requirement vector: The qualitative safety control item description text is preprocessed and subjected to deep semantic parsing to extract the safety action object, safety action and constraint conditions; The extracted safety action objects, safety actions, and constraints are used as query inputs for matching and reasoning in a pre-built standard-safety capability knowledge graph. Based on the query results, the knowledge graph outputs the demand intensity value of the control item for each core security capability dimension; Aggregate the intensity values ​​of the requirements for all core security capability dimensions to form a security requirement vector.

3. The standardized quantitative mapping method for trusted cloud levels according to claim 1, characterized in that: The process of obtaining the security supply vector: Obtain the specific safety technical measures implemented to meet safety control requirements; Based on a predefined technical measure-capability dimension mapping table, each technical measure is deconstructed and mapped to one or more core security capability dimensions; For each technical measure, an independent score is given based on the quantitative benchmark in the underlying technical implementation standard of the Trusted Cloud Level Standardization Framework System for each dimension it maps to obtain a single-dimensional implementation level value. For each core security capability dimension, a preset aggregation strategy is applied to aggregate and calculate the single-dimensional implementation level values ​​of all technical measures contributing to that dimension, thereby obtaining the comprehensive capability level value for the corresponding dimension. The comprehensive capability level values ​​of all dimensions are aggregated to form the security supply vector.

4. The trusted cloud level standardized quantization mapping method according to claim 2, characterized in that: The process of obtaining dynamic association matching degree: Calculate the cosine similarity between the security demand vector and the security supply vector, and use it as the similarity coefficient; For each dimension, the overall weakness level is represented by a value based on the demand intensity value and the actual capability level value. The dynamic association matching degree is calculated based on the similarity coefficient, the overall weakness degree characterization value, and the preset penalty coefficient.

5. The trusted cloud level standardized quantization mapping method according to claim 4, characterized in that: Calculate the difference between the demand intensity value and the actual capacity level value. If the difference is positive, it is identified as a weakness. Calculate the average difference between the dimensions of the shortest board and use it as a characterization of the overall degree of shortness.

6. The trusted cloud level standardized quantization mapping method according to claim 4, characterized in that: The penalty factor is obtained by multiplying the preset penalty coefficient with the overall weakness severity value and subtracting the product value from 1. The dynamic association matching degree is the product of the similarity coefficient and the penalty factor.

Images