An intelligent auditing method and system based on a vehicle networking security design document

Abstract

The present application relates to the field of security assessment and audit, and particularly relates to an intelligent audit method and system based on a vehicle internet security design document, wherein security design document data is acquired, security elements are extracted therefrom and their correlation is analyzed; meanwhile, a cause-and-effect knowledge graph is constructed according to standard specifications and historical data. Subsequently, the security elements are mapped to the graph, and whether they constitute an indirect cause-and-effect transmission relationship that violates the specifications is identified through graph traversal. If it is preliminarily determined to be compliant, a hypothetical compliance scenario is generated based on the evolution relationship in the graph, and compliance determination is re-executed in this scenario; when the determination result changes from compliance to non-compliance, the corresponding security expression in the document is marked as a potential compliance defect. Finally, an auditable report with complete cause-and-effect evidence chain is generated. The present application realizes automated, in-depth compliance reasoning and forward-looking risk early warning, effectively improving the accuracy, efficiency and traceability of the audit.

Description

Technical Field

[0001] This application relates to the field of security assessment and auditing technology, and in particular to an intelligent auditing method and system based on vehicle network security design documents. Background Technology

[0002] Auditing vehicle-to-everything (V2X) security design documents refers to the systematic review and evaluation of various documents generated during the vehicle development process that describe the cybersecurity design, analysis, and verification of intelligent connected vehicles, in order to ensure that these vehicles meet mandatory cybersecurity regulations (such as UN R155, ISO / SAE 21434). The audit objectives of this type of document audit are to verify whether the design systematically identifies and mitigates cybersecurity risks; whether all security measures are traceable to specific risk sources; and whether the overall solution complies with all provisions of relevant standards.

[0003] In existing technologies, a common approach is to predefine a list of keywords or regular expression templates related to security standard clauses, perform a full-text scan and matching of the document, and output the matching results. Another more advanced approach utilizes a generalized large language model, inputting the document into paragraphs or chapters and obtaining compliance judgments in a question-and-answer format. A common limitation of both methods is that their analysis is limited to the direct semantics or surface patterns of text fragments. They struggle to effectively identify and correlate multiple elements scattered across different parts of the document that describe the same security event or logical chain—for example, linking "cause," "possible consequences," and "countermeasures already taken." Therefore, they are unable to uncover deep logical vulnerabilities caused by missing, insufficient, or mismatched security controls, and have limited ability to detect complex compliance risks.

[0004] Secondly, when identifying security-related entities such as threats, vulnerabilities, and measures from documents, existing automated methods typically focus on extracting the core terms of these entities, easily overlooking or separating key conditional information that modifies or limits them. For example, a system might identify the action "allowing access to memory via the debug interface" but fail to effectively capture the precondition "only when the vehicle is in the factory testing phase." This approach leads to subsequent compliance determinations being made on a simplified model detached from the specific context of the original document. Consequently, reasonable and necessary functional designs in specific scenarios may be incorrectly identified as universally applicable security flaws, generating numerous false alarms requiring manual review and reducing the accuracy and usability of automated audit results.

[0005] Therefore, existing technologies have shortcomings and need to be improved. Summary of the Invention

[0006] To address one or more problems in the existing technology, the main objective of this application is to provide an intelligent auditing method and system based on vehicle network security design documents.

[0007] To achieve the aforementioned objectives, this application proposes an intelligent auditing method based on vehicle network security design documents, the method comprising: Obtain the vehicle-to-everything (V2X) security design document data to be audited; Extract security elements from security design document data, and analyze the correlation between each security element based on the extraction results; Obtain standard specification data and historical audit data of the Internet of Vehicles, and construct a causal knowledge graph based on the standard specification data and historical audit data; The security elements and their relationships are mapped to the causal knowledge graph, and the causal knowledge graph is used to identify whether there are causal transmission relationships between security elements that do not conform to standard specifications. If the result of the causal graph identification is received and the identification result is compliant with the standard, then a hypothetical compliance scenario for the security element is generated based on the evolution relationship in the causal knowledge graph. In the hypothetical compliance scenario, the compliance determination is re-executed. When the determination result changes from compliant to non-compliant, the corresponding security statement in the security design document data is marked as a potential compliance defect statement. Based on the labeled results, an auditable report with a causal chain of evidence is generated.

[0008] This application also provides an intelligent auditing system based on vehicle network security design documents, including: The acquisition module is used to acquire the vehicle network security design document data to be audited; The extraction module is used to extract security elements from security design document data and analyze the correlation between each security element based on the extraction results. The module is used to acquire standard specification data and historical audit data of the Internet of Vehicles, and to construct a causal knowledge graph based on the standard specification data and historical audit data; The mapping module is used to map the security elements and their relationships to the causal knowledge graph, and to identify whether there is a causal transmission relationship between the security elements that does not conform to the standard specifications through the causal knowledge graph; The receiving module is used to receive the results of causal graph identification. If the identification result is compliant with the specifications, a hypothetical compliance scenario for the security element is generated based on the evolution relationship in the causal knowledge graph. The marking module is used to re-execute the compliance determination under the hypothetical compliance scenario. When the determination result changes from compliant to non-compliant, the corresponding security statement in the security design document data is marked as a potential compliance defect statement. The generation module is used to generate an auditable report with a causal chain of evidence based on the labeled results.

[0009] This application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0010] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0011] This application's embodiment of the intelligent auditing method and system based on vehicle-to-everything (V2X) security design documents achieves in-depth logical analysis and dynamic risk warning of security design documents by constructing a computable causal knowledge graph as the core of audit reasoning. This method can not only accurately identify deep compliance defects caused by broken or poorly transmitted causal chains between security elements, but also proactively simulate future scenarios such as technological evolution and standard upgrades, discovering potential vulnerabilities in current compliance designs in advance. By binding each audit conclusion to a complete causal evidence chain, it ensures high transparency of the audit process and reliable traceability of conclusions. Ultimately, while significantly improving audit coverage depth and risk detection capabilities, it greatly enhances audit efficiency, providing integrated intelligent audit support for V2X security design that combines real-time compliance assurance with long-term risk planning. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating an embodiment of the intelligent auditing method based on vehicle network security design documents according to this application. Figure 2 This is a flowchart illustrating an embodiment of the intelligent auditing method based on vehicle network security design documents according to this application. Figure 3 This is a schematic block diagram of the structure of an intelligent auditing system based on vehicle network security design documents according to an embodiment of this application; Figure 4 This is a schematic block diagram of the structure of a computer device according to an embodiment of this application.

[0013] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0015] Reference Figure 1 This application provides an intelligent auditing method based on vehicle network security design documents, the method comprising: S1. Obtain the vehicle network security design document data to be audited; S2. Extract security elements from the security design document data, and analyze the correlation between each security element based on the extraction results; S3. Obtain standard specification data and historical audit data of the Internet of Vehicles, and construct a causal knowledge graph based on the standard specification data and historical audit data; S4. Map the security elements and their relationships to the causal knowledge graph, and use the causal knowledge graph to identify whether there is a causal transmission relationship between the security elements that does not conform to the standard specifications; S5. Receive the result of causal graph identification. If the identification result is compliant with the standard, generate a hypothetical compliance scenario for the security element based on the evolution relationship in the causal knowledge graph. S6. Under the hypothetical compliance scenario, re-execute the compliance determination. When the determination result changes from compliant to non-compliant, mark the corresponding security statement in the security design document data as a potential compliance defect statement. S7. Based on the labeled results, generate an auditable report with a causal chain of evidence.

[0016] As described in steps S1-S4 above, S1 is the data input interface. Vehicle network security design documents typically exist in unstructured or semi-structured electronic document formats, such as PDF and Word, containing various modalities of information including text descriptions, tables, and flowcharts. This raw data is obtained through a file upload interface or an integration API with a document management system. For example, format unification and encoding conversion are performed, and the data is loaded into memory or a temporary database to prepare for deep analysis. Transforming physical documents into data objects that can be processed by the computing system enables the system to handle large-scale, multi-format engineering documents, eliminating reliance on paper documents or fixed templates. S2 implements deep semantic analysis and structuring of the document. The system uses a technology that integrates visual and text analysis to understand the document layout and locate key sections. Through a domain-optimized information extraction model, core security entities, such as potential threats, system weaknesses, and protective measures, are identified from the text. Furthermore, the contextual semantics are analyzed to construct logical connections between these entities, such as "a certain weakness may be exploited by a certain threat" or "a certain protective measure is designed to counter a certain threat." Unstructured natural language descriptions are transformed into a machine-understandable and computable semantic network. She achieved precise capture of design intent and security logic. Suppose that when processing the aforementioned gateway document, the text description "deploy access control lists between the re-diagnostic interface and the internal network" was identified. Three security elements were extracted: "diagnostic interface," "internal network," and "access control list," and the relationship "access control lists are used to isolate the diagnostic interface from the internal network" was analyzed. S3 constructs the domain knowledge base upon which auditing relies. Information is obtained from industry standard libraries and historical case libraries. First, a knowledge representation framework is designed, defining concept types such as "threat," "protection," and "clause," as well as semantic relationships between concepts such as "cause" and "mitigate." Then, written industry requirements are transformed into deterministic rule nodes and relationships in the knowledge base. Simultaneously, typical findings from past audits are incorporated as empirical knowledge into the knowledge base in the form of confident patterns, forming a dynamically expandable causal network. For example, when building the knowledge base, the system creates a rule node for a general industry requirement: "strong authentication should be performed on access from outside." Simultaneously, a historical case study revealed that "using only a preset password for access control of the vehicle communication bus was deemed insufficient in the assessment." The "preset password authentication" node was linked to the "not satisfied" relationship and the "strong identity authentication" rule node, using this case as supporting evidence. The automated reasoning process in S4 involves semantic matching and mapping of the structured elements extracted in S2 with the knowledge base constructed in S3. Subsequently, a search algorithm is executed on the graph structure to explore whether a logical path exists from the identified weak or threat node to its corresponding protection node. More importantly, the terminal determines whether this logical path ultimately conflicts with the general requirement nodes recorded in the knowledge base.If a complete path exists from the source of the problem to the protective measures, ultimately conflicting with general requirements, then the current design is deemed to have a logical compliance flaw. This step can uncover deep-seated problems hidden in the design, caused by broken causal chains or mismatched measures. It enables cross-document content correlation analysis, detecting design vulnerabilities that appear compliant but are logically inconsistent. For example, mapping the two elements extracted from the document, "remotely updating gateway firmware via mobile network" and "using CRC checksum to ensure data integrity," and their relationship, to a knowledge base. Knowledge base retrieval reveals that for high-value operations like "remote firmware updates," the general requirement is "the use of an integrity protection mechanism with tamper-resistant capabilities," while "CRC checksum," as a common check, has a "non-compliance" relationship with the aforementioned requirement. Therefore, it is determined that the design does not meet the general requirements in terms of causal logic.

[0017] As described in steps S5-S7 above, step five achieves proactive risk detection. When step four determines that a design meets current general requirements, it proactively queries the knowledge base to see if an "evolution" relationship exists. This relationship represents the development trend of technical measures or requirements. Using these relationships, a virtual scenario under future or more stringent conditions is proactively constructed, such as assuming that the currently used technology becomes outdated due to evolution, or assuming that general requirements have been upgraded to a new version. This transforms the audit from a static compliance check to a dynamic risk warning. It can identify designs that are compliant in the current context but may face risks after technological development or increased requirements, helping to make forward-looking plans. For example, for the description in the document "using the AES-128 algorithm to encrypt vehicle location information," step four determines that it meets current general requirements. However, the system finds an evolution relationship in the knowledge base: "AES-128 may evolve to AES-256." Based on this, the system generates a hypothetical scenario: "Assuming that industry best practices evolve to require the use of AES-256, will the current design still meet the requirements?" Step six concretizes the virtual scenario generated in step five, for example, by temporarily adjusting the attributes or requirement levels of relevant technical nodes within the reasoning context of the knowledge base. Then, under this newly set condition, a reasoning judgment similar to step four is re-executed. If the design changes from "compliant" to "non-compliant" in this virtual scenario, it proves that its compliance foundation is fragile and dependent on the current temporary conditions. This state change is recorded, and the original description in the document that triggered the detection is precisely located for risk labeling. This effectively identifies vulnerable designs that are "currently compliant but may be non-compliant in the future," revealing the technical debt and future risks hidden behind "meeting the minimum requirements," and providing clear guidance for design hardening. The design is then re-evaluated in a virtual scenario requiring the use of AES-256. Since the original design used AES-128, it is judged as non-compliant in the new scenario. The system then marks the original document text "using AES-128 encryption" with the following explanation: "Potential risk: Encryption strength may become insufficient with technological evolution; it is recommended to pay attention to standard dynamics and assess the necessity of upgrading to AES-256." Step seven involves synthesizing and traceably outputting the audit conclusions. This is achieved by summarizing the explicit defects identified in Step four and the potential risks identified in Step six. For each finding, a complete chain of criteria is assembled. This chain includes: the specific design elements involved, the logical path they form in the knowledge base, the meaning of each node in the path, the referenced general requirements or best practices, and relevant historical case studies. The final report is presented in a structured and interactive manner, ensuring that every step of the audit conclusion derivation is transparent and traceable. For example, consider generating a final audit report on the vehicle gateway design document. The report explicitly identifies "using CRC checksums to protect remote firmware updates" as an explicit defect.The reviewer can click on this item to expand and view a detailed chain of evidence diagram, which clearly shows the logical derivation process from "remote update" to "CRC check not meeting strong integrity requirements." The report also includes a warning in the "Recommendations and Warnings" section stating that "AES-128 encryption has future strength risks." The entire report provides a clear and reliable basis for design improvements and decision-making.

[0018] As described above, by constructing a computable causal knowledge graph as the core of audit reasoning, this method enables in-depth logical analysis and dynamic risk warning of security design documents. This approach can not only accurately identify deep compliance defects caused by broken or poorly transmitted causal chains between security elements, but also proactively simulate future scenarios such as technological evolution and standard upgrades, identifying potential vulnerabilities in current compliance designs in advance. By binding each audit conclusion to a complete causal evidence chain, it ensures high transparency in the audit process and reliable traceability of conclusions. Ultimately, while significantly improving audit coverage depth and risk detection capabilities, it greatly enhances audit efficiency, providing integrated intelligent audit support for connected vehicle security design that combines real-time compliance assurance with long-term risk planning.

[0019] Reference Figure 2 In one embodiment, the step of mapping the security elements and their relationships to the causal knowledge graph, and identifying whether there is a non-compliant causal transmission relationship between the security elements through the causal knowledge graph, includes: S41. Map the security elements and their relationships to corresponding nodes and edges in the causal knowledge graph; S42. In the mapped map, determine whether there are preceding nodes corresponding to security elements that represent threats or vulnerabilities, and determine whether there are remedial nodes corresponding to security elements that represent control measures. S43. If the preceding node and the remedy node exist, then search for whether there is a directed connected path from the preceding node to the remedy node. S44. If there exists a directed connected path from the preceding node to the remedy node, then the causal logic represented by the directed connected path is compared with the standard specification requirements recorded in the causal knowledge graph for consistency. S45. If the comparison results are inconsistent, it is determined that there is a causal transmission relationship between the current security elements that does not conform to the standard specifications.

[0020] As described above, S41, based on semantic similarity calculation or predefined mapping rules, finds corresponding standardized concept nodes and relationship edges in a pre-constructed causal knowledge graph for the specific security entities and their relationships extracted from the document. This achieves the transformation from instantiated descriptions to standardized knowledge, unifying diverse document expressions into a structured reasoning framework, ensuring that subsequent analysis is based on consistent semantics, and avoiding misunderstandings caused by terminology differences. S42 is a structured verification and role identification of the mapping results. It identifies which nodes representing problem sources (threats or vulnerabilities) are used as preceding nodes, and which represent solutions (control measures) are used as remedial nodes, and confirms whether both exist simultaneously. This step defines the scope of causal analysis, ensuring that subsequent reasoning is performed on a complete security logical unit, i.e., a risk measure pair. The absence of any type of node may trigger other audit warnings. S43 is a verification of causal logical reachability. Starting from the identified preceding nodes and ending at the remedial nodes, a graph traversal algorithm is executed in the graph to find directed paths connected by causal relationship edges. This can detect broken chains in the design logic. If no path exists, it indicates that the measures cannot effectively mitigate the risk; if a path exists, it provides a specific logical chain for subsequent compliance assessment. S44 is an in-depth assessment of the adequacy of the measures. The retrieved complete causal path is treated as a logical scenario and compared with the more binding standard specification nodes stored in the knowledge graph to assess whether the measures' attributes meet the requirements. This achieves a qualitative change from whether measures exist to whether the measures are good enough, accurately identifying deep-seated compliance issues such as substandard or non-compliant measures. S45 is the final judgment and output of the defect. When it is found that the measures do not meet the specification requirements, the system formally determines that there is a non-compliant causal transmission relationship between the identified risk and the adopted measures. This step produces clear, specific, and traceable audit findings, providing precise direction and basis for design rectification. The assumption is: taking the OTA firmware upgrade security design audit as an example. The document describes downloading the firmware package via a mobile network and verifying its integrity using MD5. This method first maps the network download to a vulnerability node and the MD5 verification to a control measure node. Then it confirms that the two are the preceding node and the remedial node, respectively. Knowledge graph retrieval revealed a logical path: network downloads lead to data tampering threats, which can be mitigated by integrity verification measures. This path was then compared to the specification requirements documented in the graph, which mandates that remotely downloaded software packages use collision-resistant cryptographic hash algorithms for integrity protection. The MD5 checksum was determined to be insufficiently collision-resistant. Ultimately, the document concluded that the relationship between downloading firmware packages via mobile networks and verifying their integrity using MD5 constituted a non-standard causal link, highlighting a deficiency in the strength of the measures.

[0021] In one embodiment, the step of re-executing the compliance determination under the hypothetical compliance scenario, and marking the corresponding security statement in the security design document data as a potential compliance defect statement when the determination result changes from compliant to non-compliant, includes: Based on the hypothetical compliance scenario, determine the evolutionary relationships to be evaluated in the causal knowledge graph; Based on the changes in conditions indicated by the evolutionary relationship to be evaluated, modify the control measure attributes or intensity values ​​represented by the corresponding nodes in the graph to construct a scenario-based graph subgraph. On the scenario-based atlas subgraph, the path retrieval from the preceding node to the remedy node and the consistency comparison with the standard specification are re-executed to obtain the scenario-based judgment result; Compare the scenario-based judgment result with the initial compliance judgment result; if the initial result is compliant and the scenario-based result is non-compliant, then a compliance status reversal is determined. When a compliance status reversal is determined, the original security statement that triggered the construction of the scenario is located in the security design document data based on the mapping relationship on which the hypothetical compliance scenario was generated, and it is marked as a potential compliance defect statement.

[0022] As described above, Step One aims to identify technological evolution trends related to the current design that may affect its future compliance. It analyzes the hypothetical compliance scenarios generated above, which typically imply predictions of potential changes to a technology or standard. Based on this, the system queries the causal knowledge graph for evolutionary relationship edges connected to the control measure nodes involved in the current design. These evolutionary relationships typically exist in the form of semantic edges, such as "will evolve to," "may be replaced in the future," "strength will be increased," etc., connecting nodes representing the current technology with nodes representing more advanced or stringent future requirements. Step Two modifies a partial copy of the current causal knowledge graph based on the semantics implied by the identified evolutionary relationships. The modification targets the control measure nodes adopted in the current design. For example, if the evolutionary relationship indicates "encryption strength should be increased from A to B," the system modifies the strength attribute value associated with that node from A to B; if the evolutionary relationship indicates "a technology will be replaced by another technology," the node type or its key attributes may be temporarily replaced. This modification does not permanently alter the main knowledge base, but rather generates a scenario-based atlas subgraph specifically for simulation, reflecting possible future states. This allows the system to simulate the evolved state of technology or standards without affecting the integrity of the original knowledge base, thereby assessing the robustness of the current design in the new environment. Step three involves re-running the complete compliance reasoning in the simulated future environment. On the scenario-based atlas subgraph constructed in step two, all or part of the processes defined above are re-executed with the same logic. This includes re-identifying the preceding and remedial nodes related to the current design, retrieving the causal paths between them, and comparing the logic represented by these paths with the (possibly evolved) standard and specification requirements recorded in the scenario-based subgraph. The conclusion drawn from this comparison is the compliance status of the design in the hypothetical future scenario. Step four identifies the inherent vulnerabilities of the design by comparing its compliance status in two different knowledge environments: the "current" and the "future." The scenario-based judgment result obtained in step three is compared with the initial compliance judgment result obtained above. A key warning sign is "state reversal," where an initial assessment of compliance is deemed compliant, but under a hypothetical scenario, it is deemed non-compliant. This reversal indicates that the current design's compliance is heavily dependent on currently effective technical conditions or standard versions; once these conditions change, compliance will be immediately lost. Step five completes the closed loop from risk identification to problem localization. When a compliance state reversal is detected, this technical discovery needs to be accurately mapped back to the original design document. The system backtracks to check the "trigger point" that generated the hypothetical scenario—that is, which specific security statement in the document (e.g., a sentence mentioning a specific strength of encryption algorithm) initially triggered the evaluation of a particular evolutionary relationship. By maintaining the mapping relationship between the original document statements and graph nodes, the corresponding paragraphs, sentences, or graph elements in the document can be precisely located.Subsequently, a clear marker or annotation is added at this location, indicating the potential compliance deficiency and briefly explaining the nature of the risk, such as "This measure may not meet requirements after future standard upgrades." This ensures the operability and traceability of the audit conclusions. It not only identifies risks at the logical level but also directly links them to specific locations in the design document, providing designers with clear and intuitive modification targets, greatly enhancing the practical value of the audit results. Specifically, consider a design document describing the security of communication between an in-vehicle infotainment system and cloud services. The document states that the communication link uses the TLS 1.2 protocol and RSA-2048 keys for authentication. In the initial audit, the design was determined to comply with current common security specifications. Subsequently, a proactive risk detection process was initiated. Based on evolutionary trends in the industry knowledge base, a hypothetical scenario was generated: assuming that industry best practices have evolved to require the use of the TLS 1.3 protocol and RSA-3072 or higher strength keys. Based on this scenario, relevant evolutionary relationships were identified in the causal knowledge graph, such as "TLS 1.2 will evolve to TLS 1.3" and "RSA-2048 will evolve to RSA-3072". Next, a scenario-based subgraph was created, modifying the attributes of the "TLS 1.2" and "RSA-2048" nodes in the original design to "TLS 1.3" and "RSA-3072" respectively. Compliance reasoning was then re-executed on this modified subgraph. It was found that in the new context, the communication security design described in the original document cannot fully meet the specification requirements of the nodes corresponding to higher security levels recorded in the subgraph, resulting in a scenario-based "non-compliant" judgment. Comparing this result with the initial "compliant" result, a compliance state reversal was observed. This means that the current design carries a risk of non-compliance during future standard upgrades. Based on the mapping relationship, the original description paragraph in the document regarding "adopting TLS 1.2 and RSA-2048" is precisely located, and a prominent note is added next to it, generating a note similar to the following: "Potential compliance flaw: The current protocol and key strength are expected to fail to meet communication security requirements after the industry standard is upgraded to TLS 1.3 and RSA-3072 in the future. It is recommended to plan the technology upgrade path in advance." In one embodiment, based on the evolutionary relationships in the causal knowledge graph, a hypothetical compliance scenario for the security element is generated, specifically including: From the aforementioned standard and specification data, the effective time of future clauses related to current security elements is extracted and used as the target projection time; Analyze the predefined intensity attenuation attributes of each control measure node in the causal knowledge graph; Based on the target simulation time and the predefined intensity attenuation attribute of each control measure node in the causal knowledge graph, calculate the predicted intensity value of each control measure at the target simulation time point; The calculated predicted intensity value is compared with the compliance intensity threshold associated with the corresponding control measure node; Based on the comparison results, when the predicted intensity value of a control measure node is lower than its compliance intensity threshold, the evolution relationship in the causal knowledge graph that starts from the control measure node and satisfies the time condition is triggered. Based on the target node pointed to by the triggered evolution relationship, a hypothetical compliance scenario is constructed in which the target node replaces the original control measure node.

[0023] As mentioned above, firstly, the system automatically identifies and extracts clearly announced future time requirements from the integrated standard specification database, such as "from January 1, 2026, new car models must meet a certain new clause," thus determining a specific time target for subsequent analysis. Secondly, a "weakening effect over time" model is pre-defined for different types of security control measures in the knowledge graph, such as encryption algorithms and access control mechanisms. This is not predicting when a specific key will be cracked, but rather estimating the general trend of a type of technology's protective capability potentially decreasing over time based on general laws of technological development, such as the rate of increase in computing power and the lifecycle of common vulnerabilities. Next, the future time points obtained in the first step are substituted into this "weakening effect" model to calculate the expected remaining protective capability of each security measure at that time point, such as obtaining a quantitative result like "by the target time point, the strength of this encryption algorithm is expected to decrease to 70% of its initial value." Then, this calculated future strength value is compared with the "minimum security standard" that the measure must meet, recorded in the knowledge graph. If the predicted value is lower than this standard threshold, an alert is automatically triggered. Subsequently, the knowledge graph is used to find feasible upgrade or replacement paths (i.e., "evolutionary relationships") for the soon-to-be-defunct measure, and technical options that are already available at the target time point are selected to automatically generate upgrade suggestions. Finally, based on the found upgrade paths, a "virtual design scheme" is logically constructed to replace the old measure with the new one. This scheme serves as input for subsequent processes to verify whether it can truly solve the problem, thus forming a complete closed loop from risk prediction to providing a solution.

[0024] It's worth noting that building this "attenuation model" is more like a process of learning patterns from historical experience, rather than "training" a complex AI model with massive amounts of data in the usual sense. Its core idea is to summarize and generalize based on objective facts. The process involves: first, extensively collecting the "lifecycle records" of various security technologies, such as encryption algorithms and authentication methods, over the past decade or even longer. These records come from publicly available industry reports, in-depth analyses from technical communities, vulnerability lifecycle data released by authoritative organizations, and the time points when these technologies were phased out or replaced in numerous real-world products. The focus is on analyzing these records to identify common "aging" patterns. For example, it might discover how many years, on average, after a certain encryption algorithm's theoretical weakness is first discovered, actual attack tools emerge. It might also reveal how the approximate cost of breaking fixed-length passwords decreases year by year with the general improvement in computing chip performance. And how long does it typically take for a vehicle communication protocol to go from release to being replaced by a new generation of protocols in mainstream new cars? Finally, it summarizes "empirical formulas": based on these historical patterns, the system summarizes simple "empirical formulas" or attenuation curves for different types of technologies. For example, it might conclude: "For this type of computationally complex encryption algorithm, its relative protection strength naturally decreases by about 10% every 24 months due to advancements in computing power." The model's learning results are not a "fortune-telling tool" that can accurately predict "a certain key will be picked next March," but rather a set of quantifiable empirical criteria based on a large amount of historical data to assess the potential generalization risk level of a certain type of technology at future points in time. This allows the system to say with evidence: "Based on the performance patterns of similar technologies in the past, this design is likely to have insufficient security margin in five years."

[0025] This embodiment addresses an inherent and pressing pain point in the security auditing of connected vehicles and similar long-lifecycle complex systems: how to predict and address compliance risks arising from technological obsolescence and standard evolution that inevitably occur throughout the product's lifecycle (potentially exceeding 15 years) during the product design and finalization phase. Existing technologies are completely incapable of handling this issue; they are essentially "static," only able to answer "based on current knowledge, is it compliant now?" This embodiment, however, introduces dynamic temporal projection capabilities, based on well-founded future anchor points: extracting mandatory effective dates from standards, making the projections regulatoryly necessary rather than subjective speculation. A quantified security decay model transforms the vague concept of "technology obsolescence" into a calculable intensity decay curve, making the predictions scientific and interpretable. A closed-loop early warning and upgrade recommendation system automatically links future compliance gaps with predetermined technology evolution paths in the graph, directly outputting recommended solutions. For example, a current in-vehicle network architecture designed for a new car model uses communication security protocols that comply with current standards. The methodology reveals that this standard version will be mandatory for upgrades in the 5th year after a vehicle's launch, and based on a decay model, the strength of the currently used encryption components will fall below the security threshold in 10 years. The system automatically triggers an evolutionary relationship, constructing a hypothetical compliance scenario of "switching to the new standard protocol in the 5th year and upgrading the encryption module before the 10th year." This allows companies to plan their future OTA upgrade roadmap from the early design stages, mitigating collective compliance crises and recall risks caused by technology in the later stages of product development.

[0026] In one embodiment, the step of mapping the security elements and their relationships to corresponding nodes and edges in the causal knowledge graph includes: Extract the contextual description information that defines the security element from the security design document data, wherein the contextual description information is used to characterize the effective conditions and scope of application of the security element; The security elements, relationships, and corresponding contextual descriptions are mapped and stored as conditional nodes in the causal knowledge graph; wherein the conditional nodes include the ontological attributes of the security elements and the associated contextual attributes.

[0027] As mentioned above, the first step is a deep and refined analysis of the document's semantics. After identifying the core security elements, the semantic structure of the sentences, paragraphs, and even chapters containing these elements is further analyzed to locate and extract the natural language descriptions that modify, limit, or explain the effective environment and boundary conditions of these elements. This involves the analysis of grammatical structures such as conditional adverbs, prepositional phrases, and relative clauses. For example, time adverbs such as "within three minutes after vehicle startup," location adverbs such as "within an authorized service center," conditional adverbs such as "when a cyberattack is detected," and subject restrictions such as "access limited to diagnostic tools" are identified. This information is transformed into a structured contextual description to precisely define when, where, to whom, and under what circumstances the security element takes effect. This achieves a complete capture of the security design intent. It not only knows what security measures are specified in the document but also understands under what specific constraints and scenarios these measures are permitted or required. The second step is an innovative extension of the traditional knowledge graph node model. When mapping security elements and their relationships to the graph, instead of creating isolated, universal conceptual nodes, a composite entity encapsulating a specific context—a conditional node—is constructed. This node internally distinguishes and stores two types of attributes: one is the ontology attribute of the security element, describing its inherent technical characteristics, such as the name of the encryption algorithm and the key length; the other is the associated context attribute, which records the effective conditions and scope of application extracted in step one in key-value pairs or more complex structures. For example, for the element of accessing the debug interface, if the document specifies that it should be performed by an authorized technician in the after-sales diagnostic mode, the conditional node generated by the mapping will simultaneously include the ontology of accessing the debug interface, as well as context attributes such as the mode being diagnostic and the subject being an authorized technician. This achieves the solidification and association of contextual information at the knowledge representation level. It tightly binds the originally easily separable contextual information with the security element ontology, storing it as a whole in the knowledge graph.

[0028] In this embodiment, existing automated methods, when extracting security elements, typically focus only on core actions or objects, ignoring or discarding crucial limiting conditions. This leads to subsequent compliance judgments based on an oversimplified model detached from the original document context. For example, debugging functions enabled only during factory testing are universally identified as security vulnerabilities, resulting in numerous false alarms requiring manual review. This solution, through context-aware element extraction and conditional node modeling, enables the automated audit system to perform contextual understanding and refined reasoning regarding security designs. For instance, a security design document for an in-vehicle communication gateway states that, in vehicle transportation mode, to facilitate logistics tracking, periodic uploading of vehicle location information is allowed via a specific wireless interface, and this interface only allows one-way data uploads in this mode. Existing technology might simply extract the element of allowing location information uploads via the wireless interface and map it to a common threat node that could lead to location privacy leaks, thus generating a non-compliant audit finding. This is clearly a false alarm because this function is strictly limited to the special, temporary lifecycle phase of transportation mode and access is restricted.

[0029] This embodiment extracts contextual information such as transport mode, specific wireless interface, and one-way upload only, and creates a conditional node containing these attributes. In subsequent audit inference, when the terminal assesses the user's location privacy protection requirements during the usage phase, the controllable, scenario-specific function will not be deemed a violation because the contextual transport mode does not match the user's usage phase. This significantly improves the accuracy and usability of the audit results.

[0030] In one embodiment, before the step of comparing the causal logic represented by the directed connected path with the standard specification requirements recorded in the causal knowledge graph if a directed connected path exists from the predecessor node to the remedy node, the method further includes: Extract the context attributes associated with each conditional node from the conditional nodes that constitute the directed connected path. The extracted context attributes are subjected to compatibility analysis with the applicable conditions preset by the standard specification requirements to determine whether the conditions for consistency comparison are met. When the context attribute is compatible with the applicable conditions, it is determined that the conditions for performing a consistency comparison are met; Based on the judgment result, the causal logic representing the directed connected path is compared with the standard specification requirements recorded in the causal knowledge graph for consistency.

[0031] As described above, Step One serves as the logical starting point for initiating a refined audit. Upon retrieving a directed path connecting a preceding node and a remedial node, the adequacy of measures is not immediately compared; instead, all nodes involved in the path are first examined. Since these nodes are constructed conditional nodes, they not only contain the security element ontology but also encapsulate their effective contextual attributes. Each node on the path is traversed, and its stored set of contextual attributes is read. These attributes record specific constraints such as vehicle operating status, lifecycle stage, and operating entity in a structured form. Step Two locates the standard specification requirement node to be used for comparison in the knowledge graph and reads the applicable conditions associated with that node. These applicable conditions clearly define the specific scenario scope targeted by the specification. For example, a specification regarding prohibiting unauthorized access might explicitly limit its applicable conditions to vehicles in normal driving mode. A logical judgment needs to be performed: whether the actual contextual attributes extracted from the design documents fall within the scope of the applicable conditions preset by the specification. This involves comparing conditions across multiple dimensions, such as determining whether the operating mode in the design matches the mode the specification focuses on. By introducing a proactive, scenario-based compliance checkpoint, it first answers a fundamental question: Is this specification applicable to the current design scenario being evaluated? If the answer is no, then subsequent detailed comparisons regarding the adequacy of measures lose their premise and meaning, thus directly avoiding erroneous judgments caused by misusing specifications in irrelevant scenarios. Step three is the generation of compatibility analysis conclusions. If, after analysis, the effective scenarios of the security measures described in the design document are logically compatible or match the applicable scenarios targeted by the standard specification, then the specification clause is determined to be applicable to the current evaluation, and the next stage of in-depth technical detail comparison can proceed. For example, if the design scenario is communication in a production mode, and the specification also addresses security requirements in a production mode, then it is determined to be compatible. This provides explicit execution permission for subsequent resource-intensive in-depth causal logic consistency comparisons. It ensures that all subsequent complex calculations and reasoning only occur in the correct and relevant context, greatly improving the efficiency of the entire system's processing and the relevance of the conclusions. Step four is condition-triggered in-depth auditing. The system determines the execution process based on the judgment results of step three. The system only invokes and executes the original path logic and specification requirements consistency comparison process when the context is compatible, assessing the adequacy of control measures from a technical detail perspective. If the context is incompatible, the system skips this detailed comparison and will not generate any non-compliant conclusions based on this specification. This achieves layered and precise audit logic. A two-stage judgment mechanism has been constructed: the first stage reviews the relevance of the scenario, and the second stage reviews the adequacy of the technology. This ensures that audit conclusions will neither be misattributed due to ignoring the scenario nor overlook technical defects in the correct scenario.

[0032] This embodiment addresses the context-sensitivity and overgeneralization flaws in existing technologies. The root of these flaws lies in the fact that current automated auditing isolates security elements from their specific contexts and performs reasoning based on a universal knowledge model. This results in its inability to distinguish between a reasonably necessary function under specific constraints and a dangerous vulnerability under general conditions. For example, during the vehicle quality inspection phase after factory production, quality inspectors are allowed to read all sensor data streams through the vehicle's diagnostic interface to verify functionality. Existing technologies might extract the element "reading all sensor data through the diagnostic interface," map it to the threat node of "unauthorized access to sensitive data," and, due to a lack of sufficiently strong access control measures, determine that it does not comply with data confidentiality standards, generating a high-severity false alarm.

[0033] In this embodiment, the conditional nodes first include contextual attributes such as "factory quality inspection stage" and "authorized quality inspector." Then, before consistency comparison, a compatibility analysis is performed on these contexts with data confidentiality specifications (typically pre-defined as the "vehicle usage stage after delivery to the user"). Since the "factory quality inspection stage" does not belong to the "user usage stage," the context is determined to be incompatible, thus skipping non-compliance checks based on this specification and avoiding false positives. Alternatively, other relevant specifications applicable to the "production testing environment" may be invoked for evaluation.

[0034] In one embodiment, the step of performing a compatibility analysis between the extracted contextual attributes and the applicable conditions preset by the standard specification requirements includes: The context attributes and the applicable conditions are compared on multiple predefined context dimensions; wherein, the context dimensions include vehicle operation mode, product lifecycle stage, and access subject role. For each context dimension, based on preset compatibility judgment rules, it is determined whether the value of the context attribute matches the limitation of the applicable condition on the corresponding context dimension; The system analyzes the matching results across all contextual dimensions and outputs the final compatibility analysis conclusions.

[0035] As mentioned above, the first step is to establish a foundational framework for refined comparison. Instead of treating the context and applicable conditions as a whole for a general similarity comparison, it decomposes them into a series of predefined, independent evaluation dimensions crucial for connected vehicle security auditing. These dimensions reflect the core scenario elements upon which security attributes are based. The vehicle operating mode dimension covers different states such as normal driving, diagnostics, and factory flashing; the product lifecycle stage dimension includes different periods such as R&D, testing, production, after-sales, and scrapping; and the access subject role dimension distinguishes different entities such as vehicle owners, visitors, repair technicians, back-end services, and potential attackers. For each dimension, specific values ​​from the design context are extracted and compared one-to-one with the limitations in the applicable conditions of the standard specifications for that dimension. This achieves a structured and transparent comparison process. It ensures that compatibility analysis comprehensively covers all key scenario factors, avoiding judgment biases caused by focusing on a single dimension. For example, even if the operating modes match, mismatched lifecycle stages may still lead to overall incompatibility. Step two involves determining the matching accuracy for each context dimension based on pre-configured specific rules. These rules are explicit and computable logical expressions. Rules may include: Strict equality rules: The design context value must be exactly the same as the specified value in the applicable conditions of the specification. For example, if the specification applies to "normal driving mode," then the design context must also be "normal driving mode" to match. Set inclusion rules: The applicable conditions of the specification define a set of allowed values; the design context value is considered a match if it falls within this set. For example, if the specification applies to "production and after-sales phase," then the design context is "after-sales phase," which matches. Logical negation rules: Used for prohibitive clauses, requiring the design context value to be outside the scope limited by the specification. For example, if the specification requires "non-developers are not allowed access," then the design context subject is "test engineer," which is considered a mismatch. The appropriate rule is selected based on the dimension characteristics, and Boolean logic judgments are performed to arrive at a clear conclusion of "match" or "mismatch" for that dimension. Objective and consistent rules replace subjective and vague judgments. This makes each step of the compatibility analysis interpretable and traceable, greatly improving the rigor and reliability of the entire audit process. As long as the rules are clearly defined, the judgment results will be consistent across different times and instances. Step three collects independent matching results across all predefined context dimensions. Then, based on a pre-defined aggregation decision strategy, these results are synthesized to generate a final, binary compatibility conclusion. The aggregation strategy can be a "full matching strategy," where all dimensions must match to determine overall compatibility; it can also be a "key dimension veto strategy," where certain dimensions are designated as core dimensions, and if they do not match, incompatibility is directly determined; or it can be a more complex weighted voting strategy. This provides a flexible and controllable decision-making mechanism.It allows for customization of how to weigh the importance of different dimensions based on varying audit needs or standard characteristics. The final output is a clear directive that directly determines whether to initiate subsequent in-depth technical detail consistency comparisons, thereby precisely controlling the branches of the audit process.

[0036] In one feasible embodiment, it further includes: Construct a product compliance timeline from the current time to the preset lifecycle end time, and mark multiple assessment time points on the timeline; wherein, the assessment time points include multiple future clause effective time points parsed from the standard specification data, and planned technology upgrade time points extracted from the security design document data; For each assessment time point, a compliance status simulation process is executed: based on the chronological relationship between the assessment time point and the most recent planned technology upgrade time point, the version of the control measure node that takes effect at the assessment time point is determined; using the assessment time point as the target simulation time, the predicted intensity value of the effective control measure node version at the target simulation time point is calculated; the predicted intensity value is compared with the corresponding compliance intensity threshold to determine the simulated compliance status at the assessment time point. Connect the simulated compliance statuses at all assessment points in chronological order to form a trajectory of product lifecycle compliance status changes. Analyze the trajectory of the compliance status changes, identify non-compliance windows consisting of consecutive non-compliance statuses, and calculate the start time, end time, duration, and overall risk level of each non-compliance window.

[0037] As mentioned above, the first step is to establish a spatiotemporal framework for multi-point projection. Based on the typical lifecycle of connected vehicle products (e.g., 15 years), a timeline is constructed extending from the current time to the end of the preset lifecycle. On this axis, key time markers are automatically added from two authoritative sources: one is the effective date of all future mandatory clauses related to the current design, parsed from the standards and specifications database; the other is the timeline for technology upgrades or changes that the company has clearly planned, extracted from the audited design documents. This forms a complete time baseline that integrates external regulatory requirements and internal technical roadmaps. The second step is to perform discretized and dynamic state projection along the timeline. Each evaluation point on the timeline is traversed. For each point, a "technology baseline judgment" is first performed: based on the order of this point and the most recent technology upgrade plan recorded in the document, it is determined which version of the control measures should be adopted as the evaluation object (e.g., the pre-upgrade version or the post-upgrade version). Then, this point is substituted into the intensity decay model established above to calculate the predicted intensity value of this version of the control measures at this future point in time. Finally, the calculated strength value is compared with the compliance strength threshold required by the standard in effect at this moment, resulting in a binary state conclusion of "compliant" or "non-compliant". This achieves "snapshot" intensive sampling of future compliance status. It can capture the instantaneous changes in the design compliance status at key nodes such as before and after technology upgrades and before and after standard implementation, providing sufficient data points for depicting continuous change trajectories. Step three is to synthesize discrete state points into a continuous trend view. By connecting and interpolating the simulated compliance status obtained in step two at all evaluation time points in chronological order, an intuitive compliance status curve spanning the entire product lifecycle is generated. This curve can clearly show when the status jumps from "compliant" to "non-compliant" and when it returns to "compliant" due to planned upgrades. This elevates fragmented compliance judgments to a holistic characterization of the design's compliance resilience throughout its entire lifecycle. It transforms "compliance" from a static attribute into a function that evolves dynamically over time, providing decision-makers with an unprecedented global perspective. Step four is the in-depth analysis of the change trajectory and risk quantification. By analyzing the state change trajectory generated in step three, the periods during which all "non-compliant" states continuously occur are identified, i.e., "non-compliance windows." For each window, its start and end times and total duration are precisely calculated. More importantly, the risk level within this window is comprehensively assessed. Assessment factors may include: the extent to which control measures fall below the threshold during this period, the criticality of the assets involved, and the stage of the product lifecycle during this period (e.g., whether it is during peak mass production and sales). This achieves precise positioning and quantitative classification of forward-looking risks. It not only answers "Will there be problems in the future?" but also precisely answers "When will the problems begin, how long will they last, and how severe will they be?"This enables companies to make decisions on whether to adjust their technology upgrade plans to shorten or eliminate high-risk windows based on accurate risk cost analysis.

[0038] This embodiment addresses the challenge of identifying dynamic compliance risks arising from the extremely long product lifecycles in existing technologies, particularly the "compliance state oscillation" problem that single-point extrapolation models cannot capture. Existing linear extrapolation is like predicting whether the weather will be sunny or rainy on a "specific day," failing to predict the pattern and duration of alternating sunshine and rain throughout the "whole rainy season." For connected vehicle products with development cycles spanning several years and service lives exceeding ten years, the value of such single-point predictions is limited. Enterprises need to understand how compliance risks fluctuate over the entire product lifecycle. By introducing a conceptual model of a "timeline" and a "state trajectory," a complete time view of the product lifecycle is constructed within automated auditing, and compliance is modeled as a state function along this timeline. This achieves a fusion of "planning" and "extrapolation": uniquely incorporating the enterprise's planned upgrade timelines into the extrapolation model, ensuring that the predicted results are not pessimistic "inevitable declines" but rather reflect "potential risks under given plans," providing more practical guidance. For example, a car manufacturer designed a smart cockpit that supports over-the-air (OTA) updates and plans to upgrade its communication protocol from TLS 1.2 to TLS 1.3 in 2026. The requirement is to mandate the use of TLS 1.3 from 2027 onwards. This solution constructs a timeline, incorporating the planned upgrade point in 2026 and the regulatory implementation point in 2027. Simulations show that if the upgrade proceeds as planned, the status in 2027 will be "compliant." However, the system, through a strength decay model, finds that the encryption strength of TLS 1.3 will fall below the new security threshold after 2032, creating a new non-compliance window (2032 - product obsolescence). The system calculates that this window is as long as 5 years, falling within the middle of vehicle usage, and the risk level is "medium-high." The final report recommends: "Upgrading as planned can meet the 2027 regulations, but attention should be paid to the next-generation protocol standard around 2030, and a second upgrade should be planned to avoid medium- to long-term risks."

[0039] Reference Figure 3 This application also provides an intelligent auditing system based on vehicle network security design documents, including: Module 1 is used to acquire the vehicle network security design document data to be audited; Extraction module 2 is used to extract security elements from security design document data and analyze the correlation between each security element based on the extraction results; Module 3 is used to acquire standard specification data and historical audit data of the Internet of Vehicles, and to construct a causal knowledge graph based on the standard specification data and historical audit data; Mapping module 4 is used to map the security elements and their relationships to the causal knowledge graph, and to identify whether there is a causal transmission relationship between the security elements that does not conform to the standard specifications through the causal knowledge graph; The receiving module 5 is used to receive the result of causal graph identification. If the identification result is compliant with the standard, a hypothetical compliance scenario for the security element is generated based on the evolution relationship in the causal knowledge graph. The marking module 6 is used to re-execute the compliance determination under the hypothetical compliance scenario. When the determination result changes from compliant to non-compliant, the corresponding security statement in the security design document data is marked as a potential compliance defect statement. Module 7 is used to generate an auditable report with a causal chain of evidence based on the labeled results.

[0040] As described above, it is understood that each component of the intelligent auditing system based on vehicle network security design documents proposed in this application can realize the function of any one of the intelligent auditing methods based on vehicle network security design documents as described above, and the specific structure will not be repeated.

[0041] Reference Figure 4 This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores monitoring data and other data. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements an intelligent auditing method based on a vehicle networking security design document.

[0042] The processor described above executes the intelligent auditing method based on vehicle-to-everything (V2X) security design documents, including: acquiring V2X security design document data to be audited; extracting security elements from the security design document data and analyzing the correlation between each security element based on the extraction results; acquiring standard specification data and historical audit data of V2X, and constructing a causal knowledge graph based on the standard specification data and historical audit data; mapping the security elements and correlations to the causal knowledge graph, and identifying whether there is a causal transmission relationship between security elements that does not conform to the standard specification through the causal knowledge graph; receiving the result of the causal graph identification, and if the identification result is compliant with the specification, generating a hypothetical compliance scenario for the security element based on the evolution relationship in the causal knowledge graph; re-executing the compliance determination under the hypothetical compliance scenario, and marking the corresponding security statement in the security design document data as a potential compliance defect statement when the determination result changes from compliant to non-compliant; and generating an auditable report with a causal evidence chain based on the marking result.

[0043] One embodiment of this application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements an intelligent auditing method based on a vehicle network security design document, including the following steps: acquiring vehicle network security design document data to be audited; extracting security elements from the security design document data and analyzing the correlation between each security element based on the extraction results; acquiring standard specification data and historical audit data of the vehicle network, and constructing a causal knowledge graph based on the standard specification data and historical audit data; mapping the security elements and correlations to the causal knowledge graph, and identifying whether there is a causal transmission relationship between the security elements that does not conform to the standard specification through the causal knowledge graph; receiving the result of the causal graph identification, and if the identification result is compliant with the specification, generating a hypothetical compliance scenario for the security element based on the evolution relationship in the causal knowledge graph; re-executing the compliance determination under the hypothetical compliance scenario, and marking the corresponding security statement in the security design document data as a potential compliance defect statement when the determination result changes from compliant to non-compliant; and generating an auditable report with a causal evidence chain based on the marking result.

[0044] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0045] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0046] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An intelligent auditing method based on vehicle network security design documents, characterized in that, The method includes: Obtain the vehicle-to-everything (V2X) security design document data to be audited; Extract security elements from security design document data, and analyze the correlation between each security element based on the extraction results; Obtain standard specification data and historical audit data of the Internet of Vehicles, and construct a causal knowledge graph based on the standard specification data and historical audit data; The security elements and their relationships are mapped to the causal knowledge graph, and the causal knowledge graph is used to identify whether there are causal transmission relationships between security elements that do not conform to standard specifications. If the result of the causal graph identification is received and the identification result is compliant with the standard, then a hypothetical compliance scenario for the security element is generated based on the evolution relationship in the causal knowledge graph. In the hypothetical compliance scenario, the compliance determination is re-executed. When the determination result changes from compliant to non-compliant, the corresponding security statement in the security design document data is marked as a potential compliance defect statement. Based on the labeled results, an auditable report with a causal chain of evidence is generated.

2. The intelligent auditing method based on vehicle network security design documents according to claim 1, characterized in that, The step of mapping the security elements and their relationships to the causal knowledge graph, and identifying whether there are causal transmission relationships between security elements that do not conform to standard specifications through the causal knowledge graph, includes: The security elements and their relationships are mapped to corresponding nodes and edges in the causal knowledge graph; In the mapped graph, determine whether there are preceding nodes corresponding to security elements that characterize threats or vulnerabilities, and determine whether there are remedial nodes corresponding to security elements that characterize control measures. If the preceding node and the remedy node exist, then search for whether there is a directed connected path from the preceding node to the remedy node; If a directed connected path exists from the preceding node to the remedy node, then the causal logic represented by the directed connected path is compared with the standard specification requirements recorded in the causal knowledge graph for consistency. If the comparison results are inconsistent, it is determined that there is a causal relationship between the current security elements that does not conform to the standard specifications.

3. The intelligent auditing method based on vehicle network security design documents according to claim 2, characterized in that, The step of re-executing the compliance determination under the hypothetical compliance scenario, and marking the corresponding security statement in the security design document data as a potential compliance defect statement when the determination result changes from compliant to non-compliant, includes: Based on the hypothetical compliance scenario, determine the evolutionary relationships to be evaluated in the causal knowledge graph; Based on the changes in conditions indicated by the evolutionary relationship to be evaluated, modify the control measure attributes or intensity values ​​represented by the corresponding nodes in the graph to construct a scenario-based graph subgraph. On the scenario-based atlas subgraph, the path retrieval from the node to the remedy node and the consistency comparison with the standard specification are re-executed to obtain the scenario-based judgment result; Compare the scenario-based judgment result with the initial compliance judgment result; if the initial result is compliant and the scenario-based result is non-compliant, then a compliance status reversal is determined. When a compliance status reversal is determined, the original security statement that triggered the construction of the scenario is located in the security design document data based on the mapping relationship on which the hypothetical compliance scenario was generated, and it is marked as a potential compliance defect statement.

4. The intelligent auditing method based on vehicle network security design documents according to claim 1, characterized in that, The step of generating hypothetical compliance scenarios for the security elements based on the evolutionary relationships in the causal knowledge graph includes: From the aforementioned standard and specification data, the effective time of future clauses related to current security elements is extracted and used as the target projection time; Analyze the predefined intensity attenuation attributes of each control measure node in the causal knowledge graph; Based on the target simulation time and the predefined intensity attenuation attribute of each control measure node in the causal knowledge graph, calculate the predicted intensity value of each control measure at the target simulation time point; The calculated predicted intensity value is compared with the compliance intensity threshold associated with the corresponding control measure node; Based on the comparison results, when the predicted intensity value of a control measure node is lower than its compliance intensity threshold, the evolution relationship in the causal knowledge graph that starts from the control measure node and satisfies the time condition is triggered. Based on the target node pointed to by the triggered evolution relationship, a hypothetical compliance scenario is constructed in which the target node replaces the original control measure node.

5. The intelligent auditing method based on vehicle network security design documents according to claim 2, characterized in that, The step of mapping the security elements and their relationships to corresponding nodes and edges in the causal knowledge graph includes: Extract the contextual description information that defines the security element from the security design document data, wherein the contextual description information is used to characterize the effective conditions and scope of application of the security element; The security elements, relationships, and corresponding contextual descriptions are mapped and stored as conditional nodes in the causal knowledge graph; wherein the conditional nodes include the ontological attributes of the security elements and the associated contextual attributes.

6. The intelligent auditing method based on vehicle network security design documents according to claim 5, characterized in that, Before the step of comparing the causal logic represented by the directed connected path with the standard specification requirements recorded in the causal knowledge graph if a directed connected path exists from the predecessor node to the remedy node, the method further includes: Extract the context attributes associated with each conditional node from the conditional nodes that constitute the directed connected path. The extracted context attributes are subjected to compatibility analysis with the applicable conditions preset by the standard specification requirements to determine whether the conditions for consistency comparison are met. When the context attribute is compatible with the applicable conditions, it is determined that the conditions for performing a consistency comparison are met; Based on the judgment result, the causal logic representing the directed connected path is compared with the standard specification requirements recorded in the causal knowledge graph for consistency.

7. The intelligent auditing method based on vehicle network security design documents according to claim 6, characterized in that, The step of performing a compatibility analysis between the extracted context attributes and the applicable conditions preset by the standard specification requirements includes: The context attributes and the applicable conditions are compared on multiple predefined context dimensions; wherein, the context dimensions include vehicle operation mode, product lifecycle stage, and access subject role. For each context dimension, based on preset compatibility judgment rules, it is determined whether the value of the context attribute matches the limitation of the applicable condition on the corresponding context dimension; The system analyzes the matching results across all contextual dimensions and outputs the final compatibility analysis conclusions.

8. An intelligent auditing system based on vehicle network security design documents, characterized in that, include: The acquisition module is used to acquire the vehicle network security design document data to be audited; The extraction module is used to extract security elements from security design document data and analyze the correlation between each security element based on the extraction results. The module is used to acquire standard specification data and historical audit data of the Internet of Vehicles, and to construct a causal knowledge graph based on the standard specification data and historical audit data; The mapping module is used to map the security elements and their relationships to the causal knowledge graph, and to identify whether there is a causal transmission relationship between the security elements that does not conform to the standard specifications through the causal knowledge graph; The receiving module is used to receive the results of causal graph identification. If the identification results are in compliance with the specifications, a hypothetical compliance scenario for the security element is generated based on the evolution relationship in the causal knowledge graph. The marking module is used to re-execute the compliance determination under the hypothetical compliance scenario. When the determination result changes from compliant to non-compliant, the corresponding security statement in the security design document data is marked as a potential compliance defect statement. The generation module is used to generate an auditable report with a causal chain of evidence based on the labeled results.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images