A network security vulnerability implantation method and related device
By identifying and evaluating key interfaces in the vehicle's digital twin model, configuring attack vectors, and implanting vulnerabilities, the problem of neglecting the network layer in virtual vehicle simulation testing is solved, resulting in more accurate test results.
Patent Information
- Application Number
- CN202411359556.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-27
- Publication Date
- 2026-02-24
- Estimated Expiration
- 2044-09-27
AI Technical Summary
Existing virtual vehicle testing methods focus on simulating the physical characteristics of vehicles, while paying insufficient attention to the network layer, resulting in discrepancies between test results of vehicles in virtual simulation environments and test results of real vehicles in real environments.
By acquiring the vehicle's digital twin model, identifying the key interfaces of the connected module, conducting risk assessments, configuring attack vectors to simulate attacks, calculating attack vector defense coefficients, determining the key interfaces for which vulnerabilities to be implanted, and implanting vulnerabilities into the key interfaces, matching the corresponding vulnerabilities to be implanted.
This ensures that the digital twin model is consistent with the real vehicle in terms of network defense, reducing the deviation between test results in the virtual environment and the real environment, and improving test accuracy.
Smart Images

Figure CN119341786B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of digital twin model technology, specifically to a method and device for implanting cybersecurity vulnerabilities. Background Technology
[0002] With the rapid development of intelligent connected vehicle technology, vehicles are no longer just traditional means of transportation, but intelligent entities integrating complex network systems and advanced sensor technologies. These vehicles exchange data in real time with other vehicles, infrastructure, and cloud services through vehicle-to-everything (V2X) technology, greatly improving the convenience, safety, and comfort of driving.
[0003] However, although there are some methods for testing vehicles based on virtual simulation technology on the market, most of these methods focus on simulating the physical characteristics of the vehicle and do not pay enough attention to the vehicle at the network level. Therefore, it is difficult to accurately simulate the actual operating state of the vehicle in the network environment. Ultimately, the test results of the vehicle in the virtual simulation environment are still significantly different from those of the test results of the real vehicle in the real environment.
[0004] In view of this, the inventors propose a method and related device for implanting network security vulnerabilities. Summary of the Invention
[0005] This application provides a method and related apparatus for implanting network security vulnerabilities, in order to solve the technical problem that existing virtual vehicle simulation testing methods mostly focus on simulating the physical characteristics of vehicles, while not paying enough attention to the network layer of vehicles, resulting in differences between the testing methods for vehicles in virtual simulation environments and the testing results for real vehicles in real environments.
[0006] A first aspect of this application provides a method for implanting a network security vulnerability, the method comprising:
[0007] Obtain a digital twin model of the vehicle;
[0008] Identify the key interfaces of the connected module in the vehicle digital twin model;
[0009] A risk assessment was conducted on the key interfaces of the connected module, and the risk assessment results were obtained, including:
[0010] Configure the flow meter to simulate attack vectors;
[0011] The attack results dataset is obtained by attacking the key interface using attack vector pairs until the key interface is compromised, recording the number of attacks and the state after the attacks.
[0012] Based on the attack result dataset, calculate the attack vector defense coefficient for each of the key interfaces.
[0013] Based on the attack vector defense coefficient, determine the risk assessment results for each of the key interfaces;
[0014] Based on the risk assessment results, the key interfaces to be compromised were identified, including:
[0015] Based on the risk assessment results, the key interfaces of the connected module are identified and their risk levels are assessed to obtain the risk assessment level.
[0016] From the risk assessment levels, a preset number of key interfaces are randomly extracted to obtain a key interface dataset;
[0017] The key interfaces in the key interface dataset are selected as the key interfaces for which vulnerabilities are to be implanted.
[0018] The vulnerability to be implanted is determined based on its key interface.
[0019] The vulnerability to be implanted is implanted into the critical interface of the vulnerability to be implanted.
[0020] Furthermore, identifying the key interfaces of the connected module in the vehicle digital twin model includes:
[0021] Construct a vehicle network topology diagram based on the vehicle digital twin model;
[0022] Based on the vehicle network topology diagram, determine the data transmission parameters between the k initial connected modules in the vehicle digital twin model;
[0023] Based on the data transmission parameters, calculate the importance score values of k initial network modules to obtain a set of importance score values;
[0024] Based on the set of importance scores, m key network modules are determined from the k initial network modules;
[0025] The interface corresponding to each of the m key network modules is identified as a key interface.
[0026] Furthermore, based on the key interfaces of the vulnerability to be implanted, the vulnerability to be implanted is determined, including:
[0027] Extract vulnerability datasets from security vulnerability databases;
[0028] The key interfaces of the vulnerability to be implanted are matched with the vulnerability dataset to obtain matching results;
[0029] Based on the matching results, the vulnerability to be implanted is identified.
[0030] A second aspect of this application provides a network security vulnerability implantation device, the device comprising:
[0031] The first acquisition unit is used to acquire the vehicle's digital twin model;
[0032] The first processing unit is used to identify the key interfaces of the connected module in the vehicle digital twin model;
[0033] The second processing unit is used to perform risk assessment on the key interfaces of the network module and obtain risk assessment results, including:
[0034] Configure the flow meter to simulate attack vectors;
[0035] The attack results dataset is obtained by attacking the key interface using attack vector pairs until the key interface is compromised, recording the number of attacks and the state after the attacks.
[0036] Based on the attack result dataset, calculate the attack vector defense coefficient for each of the key interfaces.
[0037] Based on the attack vector defense coefficient, determine the risk assessment results for each of the key interfaces;
[0038] The third processing unit is used to determine the key interfaces of the vulnerability to be implanted based on the risk assessment results, including:
[0039] Based on the risk assessment results, the key interfaces of the connected module are identified and their risk levels are assessed to obtain the risk assessment level.
[0040] From the risk assessment levels, a preset number of key interfaces are randomly extracted to obtain a key interface dataset;
[0041] The key interfaces in the key interface dataset are selected as the key interfaces for which vulnerabilities are to be implanted.
[0042] The fourth processing unit is used to determine the vulnerability to be implanted based on the key interface of the vulnerability to be implanted.
[0043] The fifth processing unit is used to implant the key interface of the vulnerability to be implanted according to the vulnerability to be implanted.
[0044] A third aspect of this application provides an electronic device including a processor, an input device, an output device, and a memory, wherein the processor, input device, output device, and memory are interconnected, wherein the memory is used to store a machine program, the machine program including program instructions, and the processor is configured to invoke the program instructions to execute the network security vulnerability implantation method as described in the first aspect.
[0045] Beneficial effects:
[0046] This embodiment provides a security vulnerability implantation method and related apparatus. The method first identifies the network model of an acquired vehicle digital twin model, identifying key interfaces of the network model. Then, a risk assessment is performed on these identified key interfaces to obtain the risk assessment results. Based on these results, the key interfaces for which vulnerabilities to be implanted are determined. Next, corresponding vulnerabilities are matched according to the characteristics of the key interfaces of the vulnerabilities to be implanted. Finally, the vulnerabilities to be implanted are implanted. This setup allows system vulnerabilities that may exist in real vehicles to be replicated in the digital twin model, making the network defense environment of the digital twin model as consistent as possible with that of real vehicles. This makes the digital twin model closer to real vehicles, thus addressing the technical problem that existing virtual vehicle simulation testing methods mostly focus on simulating the physical characteristics of vehicles, while neglecting the network layer, resulting in differences between testing methods in virtual simulation environments and testing results of real vehicles in real environments. Attached Figure Description
[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0048] Figure 1 This application provides a schematic diagram of the overall process of a network security vulnerability implantation method.
[0049] Figure 2 This application provides a schematic diagram illustrating the process of identifying key interfaces in a network security vulnerability implantation method.
[0050] Figure 3 This application provides a schematic diagram illustrating the risk assessment process for critical interfaces in a network security vulnerability implantation method.
[0051] Figure 4 This application provides a schematic diagram illustrating the process of determining the key interface of the vulnerability to be implanted in a network security vulnerability implantation method.
[0052] Figure 5 This application provides a schematic diagram illustrating the process of determining the vulnerability to be implanted based on its key interface in a method for implanting a network security vulnerability, as provided in this embodiment.
[0053] Figure 6This application provides a schematic diagram of the structure of a network security vulnerability implantation device.
[0054] Figure 7 This application provides a schematic diagram of the structure of an electronic device.
[0055] Figure label:
[0056] First acquisition unit-001, first processing unit-002, second processing unit-003, third processing unit-004, fourth processing unit-005, fifth processing unit-006. Detailed Implementation
[0057] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0058] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.
[0059] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.
[0060] To better understand the network security vulnerability implantation method provided in this application embodiment, the scenarios in which this method is applied are briefly introduced below. The application scenario of this embodiment mainly involves adjusting a vehicle digital twin model after it has been constructed. This vehicle digital twin model is used to simulate real-world vehicle testing. Before applying the method provided in this embodiment, the constructed vehicle digital twin model focused on simulating the vehicle's physical characteristics during modeling, without considering the simulation of the vehicle's network. Therefore, the final test results may deviate from the actual test results.
[0061] In summary, to address the technical problem that existing virtual vehicle simulation testing methods mostly focus on simulating the physical characteristics of vehicles while neglecting the network layer, resulting in discrepancies between testing methods in virtual simulation environments and testing real vehicles in real-world environments, such as... Figure 1 As shown, this embodiment provides a method for implanting a network security vulnerability, including:
[0062] S1. Obtain the vehicle's digital twin model;
[0063] S2. Identify the key interfaces of the network module in the vehicle digital twin model. In this embodiment, preferably, as follows: Figure 2 As shown, it specifically includes:
[0064] S201. Construct a vehicle network topology diagram based on the vehicle digital twin model.
[0065] S202. Based on the vehicle network topology diagram, determine the data transmission parameters between the k initial connected modules in the vehicle digital twin model, wherein the data transmission parameters include data transmission frequency, data size, data priority, data transmission sensitivity, and data transmission real-time performance indicators.
[0066] S203. Calculate the importance score values of k initial network modules based on the data transmission parameters to obtain a set of importance score values;
[0067] S204. Based on the set of importance scores, m key network modules are determined from the k initial network modules. Therefore, by comparing the comprehensive importance scores, the interfaces that have the greatest impact on the vehicle network modules can be identified. These interfaces are confirmed as key interfaces, which can reduce the deviation between the test results of the vehicle in the virtual environment and the test results of the real vehicle by the digital twin model while reducing the processing load.
[0068] S205. The interface corresponding to each of the m key network modules is determined as a key interface.
[0069] As another preferred embodiment, in addition to steps S201-S205 provided in this embodiment being a demonstration method, other methods such as data flow analysis, communication protocol analysis, interface protocol analysis, interface specification review, functional safety analysis, attack surface analysis, expert review, and historical data analysis can also be used to identify and analyze critical interfaces. The use of importance assessment methods for identification in this embodiment is only an example and is not intended to be limiting.
[0070] S3. Perform a risk assessment on the key interfaces of the network module to obtain the risk assessment results. In this embodiment, preferably, as follows: Figure 3 As shown, it includes:
[0071] S301, Configure the flow meter to simulate attack vectors;
[0072] S302. Obtain the number of times the key interface is attacked using attack vector pairs until the key interface is compromised, and the state after the attack, to obtain the attack result dataset.
[0073] S303. Based on the attack result dataset, calculate the attack vector defense coefficient for each of the key interfaces.
[0074] S304. Based on the attack vector defense coefficient, determine the risk assessment results of each of the key interfaces.
[0075] S4. Based on the risk assessment results, determine the key interfaces to be implanted with vulnerabilities, as the preferred solution in this embodiment, including:
[0076] S401. Based on the risk assessment results, determine the key interfaces of the connected module and conduct a risk level assessment to obtain the risk assessment level;
[0077] S402. Randomly extract a preset number of key interfaces from the risk assessment levels to obtain a key interface dataset;
[0078] S403. The key interfaces in the key interface dataset are selected as the key interfaces to be implanted with vulnerabilities. In this embodiment, the key interfaces to be implanted with vulnerabilities are preferably the DSRC communication interface of the V2X module, the OBD-II diagnostic interface, the software update mechanism interface of the CCU, and the Wi-Fi interface of the in-vehicle infotainment system.
[0079] S5. Based on the key interfaces of the vulnerability to be implanted, determine the vulnerability to be implanted. Specifically, in this embodiment, it is preferred to include:
[0080] S501. Extract vulnerability datasets from the security vulnerability database;
[0081] S502. Match the key interface of the vulnerability to be implanted with the vulnerability dataset to obtain a matching result. Specifically, the matching process includes: first, analyzing the characteristics of the target system to understand the function and architecture of the target component of the current joint interface; then considering the attack surface and threat model; studying the historical vulnerability data and trends of the current joint interface; finally, assessing the potential impact, then evaluating the vulnerability based on the potential impact, and then matching the exploitable vulnerability with the current key interface to obtain a matching result.
[0082] S503. Based on the matching results, determine the vulnerability to be implanted.
[0083] S6. The vulnerability to be implanted is implanted into the key interface of the vulnerability to be implanted. In this embodiment, preferably, the implantation process of four vulnerabilities is shown as follows:
[0084] For the injection of vulnerabilities into the interface of the Wi-Fi module in connected vehicles, this embodiment preferably uses the GNU debugger to inject vulnerabilities, including:
[0085] First, identify the key functions in the Wi-Fi protocol stack that process input data in order to locate the target;
[0086] Intentionally ignoring input length checks in data processing functions to create vulnerability conditions;
[0087] Use a predefined size buffer to store input data, or allocate a fixed buffer.
[0088] Using an unsafe string copy function allows writing data beyond the buffer boundaries, thus copying unsafe data.
[0089] To ensure proper functioning, other processing logic for the Wi-Fi module in connected vehicles remains unchanged.
[0090] Vulnerabilities were implanted into the interface of the V2X-DSRC message authentication module, including:
[0091] First, identify the key functions responsible for verifying V2X messages;
[0092] Replace existing strong encryption methods with weak encryption algorithms;
[0093] Embed a fixed encryption key in the code, instead of using secure key management;
[0094] Remove and / or simplify some verification steps, and use timestamp checks or replay protection;
[0095] Ensure the modified function interface is identical to the original function to avoid modifications elsewhere in the system and ensure stability. This embodiment preferably includes the following specific implementation steps:
[0096] Open the binary file of the V2X program that needs to be modified using IDA Pro;
[0097] Locate the key function responsible for verifying V2X messages in IDA Pro, such as VerifyMessage;
[0098] Open the source code file related to this function in Visual Studio Code;
[0099] Locate the code block responsible for verification in the source code file, such as if (VerifySignature(message,signature));
[0100] Replace the VerifySignature function with a function that uses a weak encryption algorithm, such as VerifySignature_Weak;
[0101] Implement a weak encryption algorithm, such as RC4, in the VerifySignature_Weak function;
[0102] Replace the fixed encryption key with a hard-coded key;
[0103] Simplify the verification process, such as removing timestamp checks or replay protection;
[0104] Keep the interface consistent; make the modified function interface the same as the original function.
[0105] Save the modified source code file and recompile it to generate a new binary file.
[0106] In this preferred embodiment, for the OBD-II interface, an access control deficiency vulnerability is implanted, specifically including:
[0107] Open the hardware design file that contains the OBD-II interface design.
[0108] Locate the OBD-II interface connection point in the design documents and check for any physical locking or shielding mechanisms.
[0109] If it exists, remove or bypass it.
[0110] Locate any additional circuit elements in the design documents that may be used to restrict access, and remove or simplify them.
[0111] Ensure that the modified interface design still complies with the OBD-II standard to maintain basic functionality.
[0112] Remove any descriptions or requirements regarding access control from the design documents.
[0113] Save the modified design file.
[0114] As a preferred embodiment, the CCU software update signature verification vulnerability is implanted, including:
[0115] Open the binary file of the CCU program that needs to be modified using IDA Pro.
[0116] In IDA Pro, find the function responsible for verifying the signature of the software update package, such as VerifySignature.
[0117] Open the source code file related to this function in Visual Studio Code.
[0118] Locate the code block responsible for verification in the source code file, such as if (VerifySignature(package)).
[0119] Add a conditional statement to the function to check if the file size meets a specific threshold.
[0120] If the file size meets the threshold, signature verification is skipped.
[0121] Choose a threshold that seems reasonable but can actually lead to security problems, such as a file size exceeding 2KB.
[0122] Add logic to the conditional judgment to retain the original signature verification logic for cases where special conditions are not met.
[0123] Add misleading comments to the code to explain this "optimization" and make it look like a performance improvement.
[0124] Save the modified source code file and recompile it to generate a new binary file.
[0125] As a preferred embodiment, it also includes:
[0126] S7. Perform vulnerability verification tests. Verify each implanted vulnerability. For the four implanted vulnerabilities mentioned above, the verification process is as follows:
[0127] a) Wi-Fi buffer overflow:
[0128] Use Wireshark to capture Wi-Fi traffic and determine the IP address and port of the in-vehicle infotainment system.
[0129] Write a Python script to generate an excessively long Wi-Fi data packet that exceeds the Wi-Fi protocol's data packet size limit.
[0130] Use a Wi-Fi emulator tool to send the generated extra-long data packets to the in-vehicle infotainment system.
[0131] Observe whether the system crashes or executes arbitrary code, and record relevant logs or memory dump files.
[0132] Analyze logs or memory dump files to determine if a buffer overflow vulnerability exists.
[0133] b) V2X-DSRC certification bypass:
[0134] Use Wireshark or a similar tool to capture V2X messages.
[0135] Analyze the captured V2X messages to understand their format and structure.
[0136] Forged V2X messages are generated using a known fixed key, ensuring that their format is consistent with the captured V2X messages.
[0137] Use Wireshark to send forged V2X messages to the vehicle's V2X module.
[0138] Observe the vehicle's response to verify whether it has accepted a forged V2X message.
[0139] c) Unauthorized access to OBD-II:
[0140] Physical connection to OBD-II port
[0141] Attempting to send diagnostic commands and read sensitive data
[0142] Confirm whether access is possible without authentication.
[0143] d) CCU update vulnerability:
[0144] It is possible to use Python scripts to construct malicious update packages exceeding 1MB in size.
[0145] Using invalid signatures includes: using incorrect or expired signature keys, using randomly generated signatures, and using unauthorized signature keys to sign malicious update packages.
[0146] Attempt to install the update package to the CCU via OTA or wired flashing.
[0147] Verify whether the signature check has been bypassed.
[0148] S8. Record the vulnerabilities and mark them for explanation. This embodiment uses the above four vulnerability processes as examples, as follows:
[0149] Example documentation (for Wi-Fi vulnerabilities):
[0150] Vulnerability ID: CVE-2023-XXXX
[0151] Target component: In-vehicle infotainment system Wi-Fi module
[0152] Vulnerability Type: Buffer Overflow (CWE-120)
[0153] Description: A stack buffer overflow vulnerability exists in the processing of Wi-Fi packets. An attacker could trigger this vulnerability by sending a specially crafted Wi-Fi packet.
[0154] Impact: May lead to denial of service or remote code execution.
[0155] CVSS score: 8.8 (high).
[0156] Exploitation conditions: The attacker needs to be within range of the vehicle's Wi-Fi.
[0157] Detection method: By sending extremely long Wi-Fi data packets and monitoring the system response.
[0158] Mitigation measures: Update Wi-Fi firmware to add input verification and length checks.
[0159] S9. Implement mitigation strategies for each vulnerability. In this preferred embodiment, examples are given for the four vulnerabilities mentioned above, including:
[0160] a) Wi-Fi buffer overflow:
[0161] Update your Wi-Fi driver to add input length check.
[0162] Implement Address Space Layout Randomization (ASLR)
[0163] Enable Data Execution Protection (DEP).
[0164] b) V2X-DSRC authentication vulnerability:
[0165] Implement dynamic key exchange based on public key infrastructure (PKI)
[0166] Add message timestamps and anti-replay mechanism
[0167] Rotate encryption keys periodically
[0168] c) Unauthorized access to OBD-II:
[0169] Add physical access control, such as locking mechanisms.
[0170] Implement role-based access control (RBAC).
[0171] Add abnormal access detection and alarm mechanisms
[0172] d) CCU update vulnerability:
[0173] Fixed the signature verification logic to ensure that all update packages are verified.
[0174] Implement a multi-factor authentication mechanism
[0175] Added an update package integrity check.
[0176] S10. Based on the discovered vulnerabilities and established mitigation strategies, update the system security baseline, including:
[0177] Software development standards: Mandatory requirements for buffer overflow protection measures, specifically including:
[0178] a) Buffer overflow protection:
[0179] Force the use of safe string and memory handling functions (such as strncpy, snprintf, etc.).
[0180] All array operations must include bounds checks.
[0181] Force compiler warnings and error checking to be enabled (such as the -Wall -Wextra -Werror options for gcc).
[0182] All code must be examined using static code analysis tools such as Coverity or SonarQube.
[0183] b) Input validation:
[0184] All external inputs must undergo rigorous validation and cleanup.
[0185] Define and use a secure input processing library.
[0186] c) Error handling:
[0187] All function return values must be checked and handled appropriately.
[0188] Detailed error information should not be exposed in the production environment.
[0189] d) Secure coding training:
[0190] All developers are required to attend at least one secure coding training session per year.
[0191] Cryptography usage policy: Hard-coded keys are prohibited; strong encryption algorithms are required, specifically including:
[0192] a) Key Management:
[0193] Hard-coded keys are prohibited in the code.
[0194] All keys must be stored in a secure hardware module (such as a TPM or HSM).
[0195] Implement an automatic key rotation mechanism, rotating the key at least every 90 days.
[0196] b) Encryption algorithm:
[0197] The regulations stipulate that only verified strong encryption algorithms (such as AES-256, RSA-2048 or higher) can be used.
[0198] Encryption algorithms known to have vulnerabilities (such as MD5 and SHA-1) are prohibited.
[0199] Physical security requirements: Add physical access control provisions for diagnostic interfaces, specifically including:
[0200] a) Diagnostic interface control:
[0201] All OBD-II interfaces must have a physical locking mechanism.
[0202] The rules stipulate that only authorized personnel can access the diagnostic interface, and all accesses must be logged.
[0203] b) Equipment safety:
[0204] All critical hardware components (such as ECUs) must have anti-tampering mechanisms.
[0205] The regulations stipulate the use of safety screws and seals to prevent unauthorized physical access.
[0206] c) Storage media security:
[0207] All removable storage media must be encrypted.
[0208] The regulations stipulate that safety cleaning must be performed when scrapping equipment.
[0209] Software update process: Mandatory integrity and signature verification is required for all update packages, specifically including:
[0210] a) Update package verification:
[0211] All update packages must be digitally signed.
[0212] The regulations stipulate the use of a multi-factor authentication mechanism, including hash verification and version control.
[0213] b) Update process:
[0214] A rollback mechanism is required to address update failures.
[0215] The regulations stipulate that important updates must be approved by multiple people.
[0216] c) Test requirements:
[0217] The rule stipulates that all updates must undergo full testing in an isolated environment.
[0218] Automated regression testing is required.
[0219] Network security architecture: Implement a defense-in-depth strategy, increasing network segmentation, specifically including:
[0220] Network segmentation:
[0221] The requirement is to divide the in-vehicle network into multiple security domains (such as infotainment, driving control, and diagnostics).
[0222] The regulations stipulate that communication between different security domains must be subject to strict control and monitoring.
[0223] b) Firewall configuration:
[0224] Firewalls must be deployed at critical network interfaces.
[0225] The rule stipulates that the principle of least privilege should be implemented, and only necessary ports and services should be opened.
[0226] c) Wireless security:
[0227] All wireless communications (such as Wi-Fi and Bluetooth) must use strong encryption.
[0228] The rule is to change the wireless network password regularly.
[0229] Security monitoring: Deploy intrusion detection systems (IDS) and security information and incident management (SIEM) systems, including:
[0230] a) Intrusion Detection System (IDS):
[0231] The requirement is to deploy IDS on critical network nodes.
[0232] The regulations stipulate that IDS must be able to detect both known and unknown threats.
[0233] b) Security Information and Incident Management (SIEM):
[0234] The deployment of a SIEM system is required to centrally manage and analyze security logs.
[0235] The requirement is that SIEM must be able to generate real-time alerts and periodic reports.
[0236] c) Log Management:
[0237] All systems and applications are required to generate detailed security logs.
[0238] Logs must be kept for at least 6 months and backed up regularly.
[0239] Regular security assessments: A comprehensive security vulnerability scan and penetration test is required every quarter.
[0240] This embodiment provides a method for implanting security vulnerabilities. First, the network model of the acquired vehicle digital twin model is identified to pinpoint key interfaces of the network connectivity model. Then, a risk assessment is performed on these identified key interfaces to obtain the risk assessment results. Based on these results, the key interfaces for which vulnerabilities to be implanted are determined. Next, corresponding vulnerabilities are matched according to the characteristics of the key interfaces of the vulnerabilities to be implanted. Finally, the vulnerabilities to be implanted are implanted. This setup allows system vulnerabilities that may exist in real vehicles to be replicated in the digital twin model, making the network defense environment of the digital twin model as consistent as possible with that of a real vehicle. This approach makes the digital twin model closer to a real vehicle, addressing the technical problem that existing virtual vehicle simulation testing methods mostly focus on simulating the physical characteristics of vehicles, while neglecting the network layer, resulting in discrepancies between testing methods in virtual simulation environments and testing results of real vehicles in real environments.
[0241] For examples consistent with the above embodiments, please refer to... Figure 7 , Figure 7 A schematic diagram of the structure of an electronic device provided in this application embodiment is shown in the figure. It includes a processor, an input device, an output device, and a memory. The processor, input device, output device, and memory are interconnected. The memory is used to store a computer program, which includes program instructions. The processor is configured to call the program instructions. The program includes instructions for performing the following steps.
[0242] S1. Obtain the vehicle's digital twin model;
[0243] S2. Identify the key interfaces of the connected module in the vehicle digital twin model;
[0244] S3. Conduct a risk assessment on the key interfaces of the network module and obtain the risk assessment results;
[0245] S4. Based on the risk assessment results, identify the key interfaces for which vulnerabilities to be implanted;
[0246] S5. Determine the vulnerability to be implanted based on the key interface of the vulnerability to be implanted;
[0247] S6. Implant the vulnerability to be implanted into the key interface of the vulnerability to be implanted.
[0248] The above primarily describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the electronic device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0249] This application embodiment can divide the terminal into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.
[0250] For those consistent with the above, please refer to Figure 6 , Figure 6 This application provides a schematic diagram of a network security vulnerability implantation device. Figure 6 As shown, the device includes:
[0251] The first acquisition unit 001 is used to acquire the vehicle digital twin model;
[0252] The first processing unit 002 is used to identify the key interfaces of the network module in the vehicle digital twin model;
[0253] The second processing unit 003 is used to perform risk assessment on the key interfaces of the network module and obtain the risk assessment results.
[0254] The third processing unit 004 is used to determine the key interface of the vulnerability to be implanted based on the risk assessment results.
[0255] The fourth processing unit 005 is used to determine the vulnerability to be implanted based on the key interface of the vulnerability to be implanted.
[0256] The fifth processing unit 006 is used to implant the vulnerability to be implanted into the key interface of the vulnerability to be implanted.
[0257] This application also provides a computer storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments.
[0258] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program that causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments.
[0259] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.
[0260] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0261] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.
[0262] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0263] Furthermore, the functional units in the various embodiments of the application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.
[0264] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.
[0265] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: a flash drive, a read-only memory, a random access memory, a magnetic disk, or an optical disk, etc.
[0266] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A method for implanting a network security vulnerability, characterized in that, include: Obtain a digital twin model of the vehicle; Identify the key interfaces of the connected module in the vehicle digital twin model; A risk assessment was conducted on the key interfaces of the connected module, and the risk assessment results were obtained, including: Configure the flow meter to simulate attack vectors; The attack results dataset is obtained by attacking the key interface using attack vector pairs until the key interface is compromised, recording the number of attacks and the state after the attacks. Based on the attack result dataset, calculate the attack vector defense coefficient for each of the key interfaces. Based on the attack vector defense coefficient, determine the risk assessment results for each of the key interfaces; Based on the risk assessment results, the key interfaces to be compromised were identified, including: Based on the risk assessment results, the key interfaces of the connected module are identified and their risk levels are assessed to obtain the risk assessment level. From the risk assessment levels, a preset number of key interfaces are randomly extracted to obtain a key interface dataset; The key interfaces in the key interface dataset are selected as the key interfaces for which vulnerabilities are to be implanted. The vulnerability to be implanted is determined based on its key interface. The vulnerability to be implanted is implanted into the critical interface of the vulnerability to be implanted.
2. The network security vulnerability implantation method according to claim 1, characterized in that, Identify the key interfaces of the connected module in the vehicle digital twin model, including: Construct a vehicle network topology diagram based on the vehicle digital twin model; Based on the vehicle network topology diagram, determine the data transmission parameters between the k initial connected modules in the vehicle digital twin model; Based on the data transmission parameters, calculate the importance score values of k initial network modules to obtain a set of importance score values; Based on the set of importance scores, m key network modules are determined from the k initial network modules; The interface corresponding to each of the m key network modules is identified as a key interface.
3. The network security vulnerability implantation method according to claim 1, characterized in that, Based on the key interfaces of the vulnerability to be implanted, the vulnerability to be implanted is identified, including: Extract vulnerability datasets from security vulnerability databases; The key interfaces of the vulnerability to be implanted are matched with the vulnerability dataset to obtain matching results; Based on the matching results, the vulnerability to be implanted is identified.
4. A network security vulnerability implantation device, characterized in that, The device includes: The first acquisition unit is used to acquire the vehicle's digital twin model; The first processing unit is used to identify the key interfaces of the connected module in the vehicle digital twin model; The second processing unit is used to perform risk assessment on the key interfaces of the network module and obtain risk assessment results, including: Configure the flow meter to simulate attack vectors; The attack results dataset is obtained by attacking the key interface using attack vector pairs until the key interface is compromised, recording the number of attacks and the state after the attacks. Based on the attack result dataset, calculate the attack vector defense coefficient for each of the key interfaces. Based on the attack vector defense coefficient, determine the risk assessment results for each of the key interfaces; The third processing unit is used to determine the key interfaces of the vulnerability to be implanted based on the risk assessment results, including: Based on the risk assessment results, the key interfaces of the connected module are identified and their risk levels are assessed to obtain the risk assessment level. From the risk assessment levels, a preset number of key interfaces are randomly extracted to obtain a key interface dataset; The key interfaces in the key interface dataset are selected as the key interfaces for which vulnerabilities are to be implanted. The fourth processing unit is used to determine the vulnerability to be implanted based on the key interface of the vulnerability to be implanted. The fifth processing unit is used to implant the key interface of the vulnerability to be implanted according to the vulnerability to be implanted.
5. An electronic device, characterized in that, The device includes a processor, an input device, an output device, and a memory, which are interconnected. The memory is used to store a machine program, which includes program instructions. The processor is configured to invoke the program instructions to execute the network security vulnerability implantation method as described in any one of claims 1-3.
6. A computer storage medium, characterized in that, The computer storage medium stores a computer program for electronic data interchange, which causes the computer to perform some or all of the steps of the cybersecurity vulnerability implantation method as described in any one of claims 1-3.
Citation Information
Patent Citations
Digital twinning test system for intelligent network connection automobile and control method
CN113050455A
Network security vulnerability analysis method and system based on digital twin
CN116015983A