Security countermeasure system and security countermeasure method
The security countermeasure system automatically generates and deploys response rules to address cyberattacks by simulating vehicle conditions and evaluating countermeasures, providing rapid and effective protection against evolving threats.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-07-07
- Publication Date
- 2026-03-26
AI Technical Summary
Existing technologies struggle to rapidly generate optimal response rules for diverse vehicle conditions and evolving cyberattacks, requiring manual expert intervention and failing to address new threats effectively.
A security countermeasure system that automatically generates response rules by simulating attacks on a vehicle model, analyzing vehicle state changes, and evaluating countermeasures to determine optimal initial responses, which are then distributed to electronic control units for immediate implementation.
Enables rapid, automated response to new cyberattacks by generating and deploying optimal countermeasure rules, ensuring vehicle safety and functionality.
Smart Images

Figure JP2025024293_26032026_PF_FP_ABST
Abstract
Description
Security Countermeasure System and Security Countermeasure Method ,
[0006] ,
[0005] ,
[0001] The present invention relates to a security countermeasure system and a security countermeasure method.
[0002] In recent years, connected cars (hereinafter referred to as vehicles) in which electronic control units (ECUs: Electronic Control Units) mounted on vehicles are constantly connected to the Internet have become widespread, and the threat of cyberattacks on vehicles (hereinafter referred to as attacks) is increasing. If an attack is carried out on a running vehicle, the control of the vehicle may be taken over, and it is assumed that the operation of the vehicle will be affected. Therefore, there is a demand for primary countermeasures that automatically deal with attacks on the vehicle within a short time after the electronic control unit (ECU: Electronic Control Unit) detects the attack.
[0003] In the following description, provisional countermeasures that invalidate an attack by bringing the vehicle into a safe state when an attack occurs are referred to as "primary countermeasures". By means of primary countermeasures, the vehicle stops safely or some functions of the vehicle (for example, the acceleration function) are restricted. Incidentally, the fundamental countermeasures by the V-SOC (Vehicle - Security Operation Center) are referred to as "secondary countermeasures". Secondary countermeasures include, for example, applying a patch distributed to the ECU of the vehicle by the V-SOC, changing authentication information, and the like.
[0004] Since it is impossible for the driver of the vehicle himself / herself to detect an attack or take primary countermeasures during the operation of the vehicle, it is necessary for the electronic control unit to quickly respond to the attack. Therefore, there has been a technology in which the electronic control unit automatically implements safe primary countermeasures according to the situation of the vehicle based on predetermined countermeasure rules.
[0005] For example, Patent Document 1 describes that "it includes a storage unit that stores logs, an abnormality detection unit that detects an abnormality related to communication and stores the logs related to the detection of the abnormality in the storage unit, and a provisional countermeasure control unit that restricts the functions of the vehicle when the abnormality detection unit detects an abnormality." <00000Patent Document 2 states that "a comprehensive evaluation result of the security measures and availability of the target of evaluation is generated based on the simulated attack results detected by the first detection unit and the availability evaluation results detected by the second detection unit."
[0007] Japanese Patent Publication No. 2018-62320 Japanese Patent Publication No. 2023-97605
[0008] Traditionally, experts manually generated response rules. Vehicle conditions and driving situations are extremely diverse. Developing response rules that enable optimal initial responses to such diverse vehicle conditions and driving situations required specialized knowledge and considerable effort from experts. Furthermore, because automakers produce numerous vehicle models, experts had to continuously update response rules applicable to all of these models, which was time-consuming and laborious.
[0009] On the other hand, attack methods and vehicle-related technologies are evolving daily, and human resources alone may not be able to keep up with responding quickly to new attacks. The technology disclosed in Patent Document 1 is used to deal with anomalies that experts have anticipated in advance, and it is difficult to deal with new attacks, and conventionally it has not been possible to automatically generate response rules. Furthermore, the technology disclosed in Patent Document 2 is specific to vehicle security measures and does not plan and implement the optimal initial response for each type of attack and the operating status of the vehicle at the time of implementation.
[0010] This invention was made in view of these circumstances, and aims to enable rapid response to new attacks by automatically generating response rules.
[0011] The security countermeasure system according to the present invention comprises: a countermeasure analysis unit that attacks a target model, which is a model of a vehicle system to be evaluated, in a simulated environment and analyzes the results of executing multiple countermeasures against the attack on the target model; a vehicle state information acquisition unit that acquires vehicle state information indicating the vehicle state of the target model before and after the execution of each of the multiple countermeasures; a countermeasure evaluation unit that outputs an evaluation result of evaluating the multiple countermeasures based on the amount of change in the vehicle state information before and after the execution of the countermeasures; and a countermeasure rule generation unit that generates a countermeasure rule that associates vehicle state information, an attack, at least one of the multiple countermeasures against the attack, and a countermeasure start condition in which the conditions for initiating the countermeasure are defined by the vehicle state information, based on the evaluation result. The above security countermeasure system is one aspect of the present invention, and a security countermeasure method that reflects one aspect of the present invention is configured in the same way as the above security countermeasure system.
[0012] According to the present invention, automatically generated response rules enable rapid response to new attacks. Other issues, configurations, and effects will be revealed by the following description of embodiments.
[0013] This is a block diagram showing an example of the overall configuration of a vehicle and security system according to one embodiment of the present invention. This is a block diagram showing an example of the hardware configuration of a computer according to one embodiment of the present invention. This is a block diagram showing the part related to the countermeasure rule generation process of the security system according to one embodiment of the present invention. This is a flowchart showing an example of the countermeasure rule generation process according to one embodiment of the present invention. This is a diagram showing an example of the change in the driving speed of an attacked vehicle according to one embodiment of the present invention. This is a diagram showing an example of the configuration of a countermeasure rule according to one embodiment of the present invention. This is a block diagram showing the process of modifying a countermeasure rule in a security system according to one embodiment of the present invention. This is a flowchart showing an example of the countermeasure rule modification process according to one embodiment of the present invention. This is a block diagram showing the part related to the automatic countermeasure process of an electronic control device according to one embodiment of the present invention. This is a flowchart showing an example of the automatic countermeasure process according to one embodiment of the present invention. This is a diagram showing an example of the display of a notification screen shown on a vehicle display device according to one embodiment of the present invention. This is a block diagram showing the process of updating and deploying a countermeasure rule in a security system according to one embodiment of the present invention. This is a flowchart showing an example of the process of updating and deploying a countermeasure rule according to one embodiment of the present invention.
[0014] Hereinafter, embodiments for carrying out the present invention will be described with reference to the accompanying drawings. In this specification and drawings, components having substantially the same function or configuration are denoted by the same reference numerals, and redundant descriptions are omitted. The present invention is applicable, for example, to a vehicle control computing device that can communicate with an in-vehicle ECU (Electronic Control Unit) for an Advanced Driver Assistance System (ADAS) or Autonomous Driving (AD).
[0015] In this specification, the model designation assigned to a vehicle is referred to as the vehicle type to distinguish it from other vehicles. The model designation is a classification index assigned to vehicles that have the same structure, equipment, and performance, and is classified using a combination of alphanumeric characters such as "XXX-YYYZZZ". The "XXX" part is the "identification symbol for automobile exhaust gas regulations and low-emission vehicle certification" as defined by the Ministry of Land, Infrastructure, Transport and Tourism of Japan, and the "YYYZZZ" part after the hyphen is the "symbol determined by the automobile manufacturer, etc." For example, if the "XXX" part is "AAA", it indicates that it is a hybrid vehicle that complies with the 2005 regulations.
[0016] [One Embodiment] Figure 1 is a block diagram showing an example of the overall configuration of a vehicle 1 and a security system 30. The vehicle 1 is equipped with an electronic control unit 10 and a vehicle system 20. The electronic control unit 10 is provided with various functional units for dealing with attacks. The vehicle system 20 includes various systems such as the vehicle 1's drive system, onboard battery control system, and electrical control system, as well as sensors for detecting the operation of each system and device. The operation of the vehicle 1 via the vehicle system 20 is controlled by a vehicle control unit 18, which will be described later.
[0017] A security system 30 is configured on a cloud server on the web. The electronic control unit 10 and the security system 30 are connected via the internet 50 to enable them to send and receive various types of data from each other. A vehicle 1 in which the vehicle system 20 (electronic control unit 10) is constantly connected to the security system 30 via the internet 50 is referred to as a vehicle in operation 1.
[0018] The security system 30 evaluates countermeasures against anticipated attacks on vehicle 1 and outputs the best countermeasure as a countermeasure rule applicable to vehicle system 20. In the following explanation, the process of neutralizing attacks against vehicle system 20 that are anticipated in advance by vehicle system experts (hereinafter referred to as "experts") is called a "countermeasure." The process of neutralizing attacks that are actually carried out against vehicle system 20 while it is in operation is called a "countermeasure." A countermeasure includes one or more countermeasures, and a countermeasure rule includes one or more countermeasures.
[0019] <Example of Electronic Control Unit Configuration> First, an example of the configuration of the electronic control unit 10 will be described. The vehicle 1 on which the electronic control unit 10 is installed is constantly connected to the internet 50 via a wireless communication path 51 and is also called a connected car. The electronic control unit 10 comprises a communication unit 11, a security function unit 12, an HMI (Human Machine Interface) control unit 17, a vehicle control unit 18, and a response rule storage unit 19.
[0020] The communication unit 11 has a communication function for connecting to the Internet 50 via the wireless communication path 51. Actual data such as the processing results of the electronic control unit 10, data representing the status of the vehicle, and the results of initial countermeasures against actual attacks are transmitted by the communication unit 11 to the security countermeasure system 30 via the wireless communication path 51. In addition, the countermeasure rule R1 received from the security countermeasure system 30 is stored in the countermeasure rule storage unit 19.
[0021] The security function unit 12 is responsible for security functions of the vehicle 1 and performs initial response to attacks from external sources. The security function unit 12 includes an attack detection unit 13, a vehicle status information acquisition unit 14, an automatic response implementation unit 15, and a response rule update unit 16.
[0022] The attack detection unit 13 detects attacks on the vehicle 1. The attacks are carried out by external third parties via the internet 50, and when attacked, the vehicle system 20 may malfunction. The attack detection unit 13 detects attacks by, for example, detecting malfunctions in the vehicle system 20. Alternatively, the attack detection unit 13 can detect attacks by combining signatures registered in the virus definition database with the operation of the vehicle system 20. The attack detection unit 13 can also detect attacks caused by the execution of programs stored in portable memory.
[0023] The vehicle status information acquisition unit 14 acquires vehicle status information that represents the operating status of vehicle 1. Vehicle status information is information detected by various sensors mounted on vehicle 1. Examples of the operating status of vehicle 1 include engine start, stationary, driving (acceleration, coasting, deceleration, cornering), reversing, compressor start or stop, or door lock or unlock. A compressor is, for example, one used in an air conditioner. If the temperature inside the vehicle rises due to abnormal operation of the compressor, it can cause overheating, so the operating status of the compressor is managed. In addition, if there is a function to determine whether there is a person inside the vehicle using a door lock sensor, the locking or unlocking of the doors is also managed as an operating status.
[0024] The automated response unit 15 automatically performs an initial response to the attack based on the response rule R1 read from the response rule storage unit 19 based on the vehicle status information, and transmits the response result along with the vehicle status information to the security countermeasure system 30. The result of the initial response is transmitted from the communication unit 11 to the security countermeasure system 30 along with the vehicle status information at the time of the attack. Alternatively, the results of the initial response may be stored in the non-volatile storage 67 (see Figure 2 described later) of the electronic control unit 10, and the results of the initial response may be transmitted to the security countermeasure system 30 all at once in a location with stable communication.
[0025] The response rule update unit 16 updates the response rule R1 stored in the response rule storage unit 19 using the response rule R1 distributed from the security countermeasure system 30. At this time, the response rule update unit 16 searches the response rule storage unit 19 using the identification ID assigned to the response rule R1 and updates the response rule R1 for which the identification ID matches. If the response rule update unit 16 does not find an identification ID in the response rule storage unit 19 that matches the identification ID of the response rule R1 distributed from the security countermeasure system 30, it adds it to the response rule storage unit 19 as a new response rule R1.
[0026] The HMI control unit 17 controls the display of various information about the vehicle 1 on the vehicle 1's display device. The HMI control unit 17 also controls the broadcasting of voice guidance and other sounds from the in-vehicle speakers. In addition to information such as the vehicle 1's speed and mileage, the HMI control unit 17 also provides the driver with information such as attack information detected by the attack detection unit 13 and the results of the initial response by the automatic response implementation unit 15.
[0027] The vehicle control unit 18 controls, for example, the driving, steering, and stopping of the vehicle 1. In addition, in automatic driving mode, the vehicle control unit 18 controls the vehicle 1 to drive automatically to the destination, and in manual driving mode, it controls the vehicle to assist the driver's driving operations. Furthermore, the vehicle control unit 18 also controls the vehicle 1 to gradually decelerate or move the vehicle 1 to a safe location, based on instructions from the automatic response unit 15 that has performed initial countermeasures against the attack.
[0028] If vehicle 1 malfunctions, vehicle 1, which is controlled by the vehicle control unit 18, may not operate correctly. In this case, the vehicle control unit 18 can determine, using conventional determination techniques, that a malfunction in vehicle 1 has caused an abnormality in the operation of vehicle 1. If the vehicle control unit 18 determines that a malfunction in vehicle 1 is the cause, it will provide the driver with information on the location of the malfunction and take control such as stopping vehicle 1.
[0029] The countermeasure rule storage unit 19 stores the countermeasure rule R1 distributed from the security countermeasure system 30 and received by the communication unit 11 via the internet 50 and wireless communication path 51. Alternatively, the countermeasure rule R1 may be stored in a portable memory. This memory can also be plugged into a connector in the vehicle 1, and the security function unit 12 can read the countermeasure rule R1 from the memory and store it in the countermeasure rule storage unit 19. If there is a new attack case, the updated countermeasure rule R1 is distributed to the vehicle 1, and the countermeasure rule R1 in the countermeasure rule storage unit 19 is updated.
[0030] <Example Configuration of Security Measures System> Next, an example configuration of the security measures system 30 will be described. The security measures system 30 comprises a communication unit 31, an automatic countermeasure analysis unit 32, a countermeasure rule distribution unit 38, a security measures system operation unit 39, an attack case storage unit 40, and a countermeasure rule deployment unit 41.
[0031] The communication unit 31 has a communication function for connecting to the internet 50 via the communication bus 52. The communication unit 31 collects actual data from the electronic control unit 10, including countermeasures taken in accordance with countermeasure rule R1 in response to an attack on the operational vehicle system 20, and vehicle status information of the vehicle system 20 as a result of the execution of countermeasure rule R1, stores it in the attack case storage unit 40, and outputs it to the automatic countermeasure analysis unit 32. The communication unit 31 also distributes the countermeasure rule R1, which is generated by the automatic countermeasure analysis unit 32 and distributed by the countermeasure rule distribution unit 38, to the electronic control unit 10 via the communication bus 52 and the internet 50.
[0032] The automated countermeasure analysis unit 32 automatically analyzes countermeasures to generate countermeasure rule R1 based on attack cases of the vehicle system 20, and generates countermeasure rule R1 based on the best countermeasure. The automated countermeasure analysis unit 32 comprises a countermeasure analysis input unit 33, a countermeasure analysis unit 34, a vehicle status information acquisition unit 35, a countermeasure evaluation unit 36, and a countermeasure rule generation unit 37.
[0033] The Countermeasure Analysis Unit Input Unit 33 outputs vehicle design information of vehicle 1, input information from experts, and attack cases read from the Attack Case Storage Unit 40 to the Countermeasure Analysis Unit 34 via the Communication Unit 31.
[0034] The countermeasure analysis unit 34 analyzes attacks and countermeasures based on various information input from the countermeasure analysis unit input unit 33. The countermeasure analysis unit 34 inputs vehicle state information given by the attack-defined scenario into the evaluation target model. The scenario includes information for executing simulations, such as accelerating or decelerating vehicle 1 at a constant acceleration or driving a predetermined course at a constant speed. Then, as shown in Figure 3 described later, the countermeasure analysis unit 34 attacks the evaluation target model, which is a model of the vehicle system of vehicle 1M, the vehicle under evaluation, in a simulated environment that simulates the real world in cyberspace.
[0035] Next, the countermeasure analysis unit 34 analyzes the results of implementing multiple countermeasures on the model under evaluation against attacks carried out in cyberspace. Based on past attack cases read from the attack case storage unit 40, the countermeasure analysis unit 34 analyzes the attacks given to the model under evaluation, the model's behavior in response to the attacks, and the countermeasures. At this time, the countermeasure analysis unit 34 analyzes how the countermeasures against the attacks affect the operating status of the vehicle 1, based on the attack information given to the model under evaluation and the design information of the vehicle 1. The attack information includes, for example, the damage situation at the time of the attack, the attack detection method, known primary countermeasures, and the results of the implementation of primary countermeasures.
[0036] The vehicle status information acquisition unit 35 acquires vehicle status information indicating the vehicle status of the evaluation target model before and after the implementation of each of the multiple countermeasures. For example, the vehicle status information acquisition unit 35 acquires numerical data indicating changes in the operating status of vehicle 1 in cyberspace as vehicle status information. Changes in the speed, acceleration, and rotation speed of various gears of vehicle 1 running in cyberspace are output as numerical data, and this numerical data is acquired as vehicle status information. The vehicle status information also includes data such as whether various devices mounted on vehicle 1 are on or off.
[0037] The countermeasure evaluation unit 36 outputs evaluation results for multiple countermeasures based on the amount of change in vehicle status information before and after the implementation of the countermeasures. For example, the countermeasure evaluation unit 36 evaluates countermeasures for attack cases based on the configuration information and vulnerability information of the vehicle system 20, and the operating status of various vehicles 1 and vehicle systems 20 estimated in cyberspace. The countermeasure evaluation unit 36 then extracts countermeasures in which the amount of change in vehicle status information falls within the threshold range set for each scenario. The "threshold" is the upper or lower limit of the degree of impact on the vehicle status caused by the implementation of the countermeasures.
[0038] The countermeasure evaluation unit 36 evaluates the movement of vehicle 1 for each countermeasure applied to vehicle 1 and extracts countermeasures that ensure vehicle 1 operates within a predetermined threshold range. For example, the countermeasure evaluation unit 36 extracts multiple countermeasures that do not affect vehicle 1's operation, or have a minor and acceptable impact on vehicle 1's operation. If there are multiple countermeasures that allow vehicle 1 to operate within a predetermined threshold range, the countermeasure evaluation unit 36 extracts the best countermeasure that enables vehicle 1 to operate safely.
[0039] The response rule generation unit 37 generates a response rule R1 based on the evaluation results from the countermeasure evaluation unit 36, associating vehicle status information, an attack, at least one countermeasure from a plurality of countermeasures against this attack, and a response start condition defined by the vehicle status information, which is the condition under which the countermeasure is initiated. The response rule R1 enables the attacked vehicle system 20 to automatically take initial countermeasures. The contents of the response rule R1 are shown in Figure 6, which will be described later. The response rule generation unit 37 can also generate manual response rules based on the driver's manual operation.
[0040] The countermeasure rule distribution unit 38 distributes the countermeasure rule R1 to the electronic control unit 10 installed in the vehicle 1, which is equipped with the vehicle system 20 that serves as the basis for the model under evaluation and is operating the vehicle system 20. The countermeasure rule R1 distributed by the countermeasure rule distribution unit 38 is transmitted to the electronic control unit 10 of the vehicle 1 via the communication unit 31.
[0041] The security system operation unit 39 receives input from an operator who directly operates the security system 30. The operator may be one of the experts mentioned above. Based on the information entered by the operator, the automatic countermeasure analysis unit 32 generates a countermeasure rule R1. The operator can also review the contents of the countermeasure rule R1 before it is distributed to the vehicle 1. If the operator determines that there is a problem with the countermeasure rule R1, they can correct the input values through the security system operation unit 39, causing the automatic countermeasure analysis unit 32 to regenerate the countermeasure rule R1.
[0042] The attack case memory unit 40 stores, as past attack cases, attacks given to the vehicle system 20 during past operation and the vehicle state information of the vehicle system 20 to which the attacks were given. The attack case memory unit 40 is an example of a database that stores, as attack cases, not only the actually occurred attacks but also the attack cases of attacks simulated in the cyber space.
[0043] The countermeasure rule deployment unit 41 generates a similar system countermeasure rule R2 (an example of the second countermeasure rule shown in FIG. 12 described later) that enables other vehicles configured with similar systems having a vehicle configuration similar to that of the vehicle system 20 to use the countermeasure rule R1 generated by the automatic countermeasure analysis unit 32. The countermeasure rule deployment unit 41 includes a vehicle configuration similarity determination unit 42 and a similar system countermeasure rule generation unit 43.
[0044] The vehicle configuration similarity determination unit 42 is an example of a determination unit that makes a decision to generate a countermeasure rule applicable to a specific vehicle type based on the vehicle configuration information, the attack cases read from the attack case memory unit 40, and the analysis results of the attack cases by experts. Here, the vehicle configuration similarity determination unit 42 determines whether to refine the distributed countermeasure rule R1 or distribute the similar system countermeasure rule R2 to a vehicle system similar to the vehicle system 20 related to the evaluation target model. For this determination, information on the identity or similarity of the configuration of the vehicle including the configuration information indicating the hardware configuration of the vehicle system 20 and the version information indicating the software version of the software used in the vehicle system 20 is used.
[0045] The vehicle system 20 includes, for example, control software that controls the electronic control unit 10. The software configuration of the vehicle system 20 is version-controlled, and normally, if the vehicle model is the same, the hardware and software configurations of each vehicle are the same. In the future, the spread of software-defined vehicles (SDVs) is expected, and even with the same hardware configuration, different types of software may result in different functions. Therefore, even with the same model, different software versions may result in different vehicle functions. On the other hand, differences of only minor versions may result in the same functions. For this reason, the vehicle configuration similarity determination unit 42 determines whether the hardware and software configurations of vehicles for each vehicle model are the same, and then determines whether the different configurations have the same functions. A vehicle system that has the same functions and exhibits the same behavior as the vehicle system related to the model under evaluation is called an "identical system". A vehicle system that has some configurations that differ from the vehicle system related to the model under evaluation, and exhibits different behavior due to these configurations, is called a "similar system".
[0046] Let's take vehicle type A of vehicle 1 that was attacked during operation, and vehicle types B to D, which are similar to vehicle type A, as examples. The vehicle configuration similarity determination unit 42 determines the identical and similar parts of vehicle type A and vehicle types B to D based on the hardware and software configurations included in the vehicle configuration information of vehicle 1. The vehicle configuration similarity determination unit 42 then instructs the automatic countermeasure analysis unit 32 to refine and update the countermeasure rule R1 for the same system installed in vehicle type A, which is the same as the attacked vehicle 1, and which has the same function. Therefore, if the vehicle configuration similarity determination unit 42 determines that the vehicle configuration is the same and that the distributed countermeasure rule R1 should be refined, the countermeasure analysis unit 34, vehicle status information acquisition unit 35, countermeasure evaluation unit 36, and countermeasure rule generation unit 37 generate the refined countermeasure rule R1. The countermeasure rule distribution unit 38 distributes the refined countermeasure rule R1 to the electronic control device 10 of the same system, and updates the countermeasure rule R1.
[0047] On the other hand, the vehicle configuration similarity determination unit 42 expands the countermeasure rules generated for vehicle type A for similar systems of vehicle types B to D, which are similar to vehicle type A and have functions different from those of vehicle type A. Therefore, the vehicle configuration similarity determination unit 42 causes the electronic control unit 10 of the same system to generate countermeasure rules that can be expanded to the similar system. The countermeasure rules generated by the similar system countermeasure rule generation unit 43 (an example of the second countermeasure rule generation unit) are referred to as "similar system countermeasure rules".
[0048] When the vehicle configuration similarity determination unit 42 determines that the vehicle configurations are similar and distributes the similar system countermeasure rule R2 (refer to FIG. 12 described later) to a similar system (an example of the second vehicle system) similar to the vehicle system related to the evaluation target model, the similar system countermeasure rule generation unit 43 generates the similar system countermeasure rule R2. For example, the similar system countermeasure rule generation unit 43 generates the similar system countermeasure rule R2 to be deployed to vehicle types B to D in accordance with the configurations similar to vehicle type A determined by the vehicle configuration similarity determination unit 42, based on the already created countermeasure rule R1. The similar system countermeasure rule R2 may be the same for vehicle types B to D or may be different for each of vehicle types B to D.
[0049] Then, the countermeasure rule distribution unit 38 distributes the similar system countermeasure rule R2 to a second electronic control unit (not shown) mounted on a vehicle (an example of the second vehicle) operating the similar system. In this way, since the similar system countermeasure rule generation unit 43 can automatically generate the similar system countermeasure rule R2 based on the countermeasure rule R1, it is possible to reduce the labor and time required for experts to analyze attacks and countermeasures for each vehicle type for the similar system.
[0050] <Example of Computer Hardware Configuration> Next, the hardware configuration of the computer 60 that constitutes the electronic control unit 10 and the security countermeasure system 30 will be described.
[0051] Figure 2 is a block diagram showing an example of the hardware configuration of the computer 60. The computer 60 is an example of hardware used as a computer capable of operating as the electronic control unit 10 and security countermeasure system 30 according to this embodiment. In the security countermeasure system 30 according to this embodiment, each functional block is configured by the computer 60 executing a program, and each functional block works in cooperation to realize the countermeasure rule generation method shown in Figure 4, which will be described later.
[0052] The computer 60 includes a CPU (Central Processing Unit) 61, a ROM (Read Only Memory) 62, and a RAM (Random Access Memory) 63, each connected to a bus 64. Furthermore, the computer 60 includes a display device 65, an input device 66, a non-volatile storage 67, and a network interface 68.
[0053] The CPU 61 reads the program code of the software that implements each function according to this embodiment from the ROM 62, loads it into the RAM 63, and executes it. Variables and parameters that occur during the calculation process of the CPU 61 are temporarily written to the RAM 63, and these variables and parameters are read out by the CPU 61 as appropriate. However, an MPU (Micro Processing Unit) or GPU (Graphics Processing Unit) may be used instead of the CPU 61, or the CPU 61 and GPU (Graphics Processing Unit) may be used in combination. The processing of each functional unit of the electronic control device 10 and security countermeasure system 30 shown in Figure 1 is realized using the CPU 61, ROM 62, and RAM 63.
[0054] The display device 65 is, for example, a liquid crystal display monitor, which displays the results of processing performed by the computer 60 to the user. The input device 66 uses, for example, a keyboard, mouse, etc., and the user can perform predetermined operations and give instructions. In the security system 30, the user is an expert. In the electronic control unit 10, the user is the driver of the vehicle 1.
[0055] Examples of non-volatile storage 67 include HDDs (Hard Disk Drives), SSDs (Solid State Drives), flexible disks, optical disks, magneto-optical disks, CD-ROMs, CD-Rs, magnetic tapes, or non-volatile memory. This non-volatile storage 67 stores the OS (Operating System), various parameters, and programs necessary for the computer 60 to function. The ROM 62 and non-volatile storage 67 store programs and data necessary for the CPU 61 to operate. In other words, the ROM 62 and non-volatile storage 67 are used as examples of computer-readable, non-transient storage media that store programs executed by the computer 60. The countermeasure rules R1 generated by the security countermeasure system 30, attack cases, and the countermeasure rules R1 received by the electronic control unit 10 are stored in the storage units of each system and device.
[0056] For example, a Network Interface Card (NIC) can be used for the network interface 68. The network interface 68 can transmit and receive various types of data between devices via a LAN (Local Area Network), dedicated line, etc., connected to the terminals of the NIC. The functions of the communication units 11 and 31 shown in Figure 1 are realized by the network interface 68.
[0057] <Example of the process for generating countermeasure rules in a security system> Next, an example of the process for generating countermeasure rules in the security system 30 will be explained with reference to Figures 3 to 6. Here, the process for generating countermeasure rule R1 first will be explained. Figure 3 is a block diagram showing the part of the security system 30 that is involved in the process for generating countermeasure rules. Figure 4 is a flowchart showing an example of the process for generating countermeasure rules. Figure 4, and Figures 8, 10, and 13, which will be described later, are flowcharts for explaining the security countermeasure method according to this embodiment.
[0058] First, based on the vehicle design information, the experts create configuration information, vulnerability information, and estimated vehicle operating status for each vehicle type and vehicle system 20 (S11). This information is input to the countermeasure analysis input unit 33 of the automatic countermeasure analysis unit 32 via the communication unit 31.
[0059] Here, we will explain the vehicle operating status. For example, when the driver accelerates vehicle 1, they press the accelerator pedal. As a result of this operation, various devices configured within vehicle 1 are activated in conjunction, and the status of the vehicle system 20 changes. This change in the vehicle system 20 is shown as the vehicle operating status. For example, when the accelerator pedal is pressed, an acceleration signal is input to the electronic control unit 10, and when the electronic control unit 10 outputs a command to increase the engine speed, the rotational speed of the gears changes, and the rotational speed of the tires also changes. Data showing this series of changes in the vehicle system 20 is used as the vehicle operating status. In addition, the state of vehicle 1 obtained by the acceleration of vehicle 1 is, for example, the driving speed of vehicle 1, and numerical data showing this driving speed is obtained as vehicle state information.
[0060] Next, the attack scenarios anticipated by the expert are registered in the attack scenario storage unit 40 via the communication unit 31 (S12). In addition, past attack scenarios (hereinafter referred to as "past scenarios") are also registered in the attack scenario storage unit 40. If an attack scenario is already registered in the attack scenario storage unit 40, the expert does not need to register it again.
[0061] Next, the expert sets up past attack cases and multiple countermeasures for those past cases registered in the attack case memory unit 40 in the security countermeasure system 30 (S13). The multiple countermeasures are devised by the expert. The multiple countermeasures are input to the countermeasure analysis unit input unit 33 via the communication unit 31.
[0062] Next, the Countermeasure Analysis Unit Input Unit 33 inputs configuration information, vulnerability information, and estimated vehicle operating status of the vehicle system 20, reads attack cases, or inputs multiple countermeasures (S14). The vehicle operating status data input to the Countermeasure Analysis Unit Input Unit 33 is output to the Countermeasure Evaluation Unit 36 and the Countermeasure Rule Generation Unit 37.
[0063] Next, the countermeasure analysis unit 34 simulates attacks and countermeasures against vehicle 1 in a cyberspace environment that simulates vehicle 1 in actual operation, and performs a countermeasure analysis to analyze the results of the implementation of the countermeasures (S15). In the simulation that simulates attacks and countermeasures, a scenario created by an expert is used.
[0064] Next, the vehicle status information acquisition unit 35 acquires vehicle status information as a result of the analysis performed by the countermeasure analysis unit 34 (S16). The analysis results include, for example, numerical data showing changes in the vehicle's operating status for each countermeasure. Therefore, the vehicle status information acquisition unit 35 acquires data showing how each function of the vehicle 1 behaves when countermeasures A, B, C, etc. are executed while attack α is being carried out against the vehicle 1 in cyberspace.
[0065] Here, an example of vehicle status information will be explained with reference to Figure 5. Figure 5 shows an example of the change in the driving speed of vehicle 1 that was under attack. In Figure 5, the horizontal axis represents time [seconds], and the vertical axis represents driving speed [km / h].
[0066] Assume that the attack detection unit 13 detects an attack α occurring at 14 seconds against vehicle 1, which is being driven in cyberspace. Attack α hijacks the commands output to the engine of vehicle 1, increasing the driving speed by 5 km / h per second, and ultimately accelerating vehicle 1 to 120 km / h. The electronic control unit 10 of vehicle 1, which has been subjected to attack α, will exhibit behavior that increases the vehicle speed of vehicle 1, for example, by increasing the number of ignition commands to the engine.
[0067] Even if attack α occurs, if the electronic control unit 10 of vehicle 1 can neutralize attack α, the driving speed indicated as the driver's input value will be represented as a normal value, shown by a thin solid line in the figure. The threshold range for the driving speed of vehicle 1 is between the lower and upper thresholds, shown with a shadow in the figure, and there is no problem with the operation of vehicle 1 as long as it is within this range.
[0068] Let's assume that countermeasures A through C were used. With countermeasure A, as shown by the dashed line in the figure, the change in travel speed remains within the threshold range. Therefore, countermeasure A is appropriate.
[0069] In countermeasure B, as shown by the dashed line in the figure, the driving speed becomes slower than the lower threshold. When countermeasure B is used, the ignition commands are reduced, so the vehicle speed of vehicle 1 increases gradually. However, if the vehicle speed does not increase as much as the driver expects, the driver may press the accelerator pedal hard, so countermeasure B is not appropriate.
[0070] In countermeasure C, as shown by the thick solid line in the figure, the driving speed exceeds the upper threshold. When countermeasure C is used, acceleration due to attack α is allowed for a while, and when the speed exceeds a certain value (for example, 75 km / h), control is implemented to maintain a constant speed and decelerate. However, countermeasure C that causes acceleration unintended by the driver is not appropriate.
[0071] The vehicle status information acquisition unit 35 acquires data indicating the behavior for each of these countermeasures A to C (in the example in Figure 5, this is driving speed data) as vehicle status information, and outputs the contents of countermeasures A to C, along with the vehicle status information and vehicle operating status, to the countermeasure evaluation unit 36.
[0072] Returning to the explanation of Figure 4, after step S16, the countermeasure evaluation unit 36 evaluates the countermeasures based on the vehicle status information and vehicle operating status acquired by the vehicle status information acquisition unit 35 and the configuration information of the vehicle system 20 input from the countermeasure analysis unit input unit 33. Then, based on the vehicle operating status for each countermeasure, the countermeasure evaluation unit 36 extracts countermeasures that do not affect the operating status of vehicle 1, or that have only a minor and acceptable impact (S17). Based on the vehicle operating status of vehicle 1, the countermeasure evaluation unit 36 determines whether the operation of vehicle 1 exceeds an acceptable threshold range. Then, from among multiple countermeasures in which the operation of vehicle 1 does not exceed an acceptable threshold range, the countermeasure evaluation unit 36 selects the countermeasure that has the least impact on vehicle 1. For this reason, countermeasures that cause vehicle 1 to suddenly accelerate or suddenly stop are not extracted.
[0073] In the example in Figure 5, only countermeasure A keeps the driving speed within the threshold range. Therefore, the countermeasure evaluation unit 36 extracts countermeasure A as the best countermeasure. The countermeasure evaluation unit 36 outputs countermeasure A, which will be executed during attack α, to the countermeasure rule generation unit 37. If there is no suitable countermeasure, the countermeasure evaluation unit 36 sends information that there is no suitable countermeasure to the countermeasure rule generation unit 37. In this case, as shown in Figures 7 and 8 described later, the operator modifies the countermeasure.
[0074] Next, the countermeasure rule generation unit 37 generates a countermeasure rule R1 based on the countermeasures extracted by the countermeasure evaluation unit 36 (S18). The countermeasure rule generation unit 37 generates a countermeasure rule R1 based on the countermeasures extracted from the countermeasure evaluation unit 36 (for example, countermeasure A executed during attack α) and information entered by an expert into the countermeasure analysis unit input unit 33 (for example, the specific command for countermeasure A, the location of vehicle 1 to which it is applied, etc.).
[0075] Here, an example of the configuration of countermeasure rule R1 will be explained with reference to Figure 6. Figure 6 is a diagram showing an example of the configuration of countermeasure rule R1.
[0076] The response rule R1 consists of the following items: trigger, whether or not primary response is performed, response start conditions, response end conditions, response destination, and response content. The trigger item stores the trigger that initiates primary response. For example, the trigger is when the attack detection unit 13 detects attack α. The ID of the attack detection rule detected by the attack detection unit 13 may also be stored in the trigger item.
[0077] The "Initial Response Implemented" field stores whether or not an initial response will be implemented when the trigger occurs. In the example in Figure 6, an initial response is implemented, so "Implemented" is stored. If the attack is minor, an initial response will not be implemented and a secondary response will be carried out, so "Not Implemented" is stored.
[0078] The "Initiation Conditions" field stores conditions that some of the vehicle status information must satisfy to initiate the initial response. Examples of initiation conditions include when the speed of vehicle 1 increases or decreases by a% from its normal value, when the speed exceeds a specified speed value, or when attack α is detected. The "Ending Conditions" field stores conditions that some of the vehicle status information must satisfy to terminate the initial response. Examples of ending conditions include when the speed of vehicle 1 returns to a specified value after the initial response has begun.
[0079] The "Target" item stores the target of the initial countermeasure. In the example in Figure 6, the target is the engine and electronic control unit 10 (ECU) of vehicle 1. The "Countermeasure Details" item stores the countermeasure details to be taken by the electronic control unit 10. As countermeasure details, for example, detailed commands or scripts are stored in which the automatic countermeasure execution unit 15 instructs the electronic control unit 10 itself to take initial countermeasures.
[0080] Returning to Figure 4, we continue the explanation. After step S18, the response rule distribution unit 38 distributes the response rule R1 to the electronic control unit 10 of the vehicle 1 (S19), and this process ends. The response rule R1 is distributed to the electronic control unit 10 of the vehicle 1 by the communication unit 31, with a destination address assigned to it.
[0081] <Process for correcting countermeasure rules> If all of the countermeasures shown in Figure 5 result in exceeding the threshold range, the countermeasures need to be reconsidered. Therefore, experts are notified that there were no appropriate countermeasures against the attack, and new countermeasures are considered, planned, and entered into the security countermeasure system 30. With these new countermeasures, the execution and evaluation of countermeasures against the attack, as well as the generation and distribution of countermeasure rules, are carried out again.
[0082] Here, the process of modifying the response rule will be explained with reference to Figures 7 and 8. Figure 7 is a block diagram showing how the modification process for response rule R1 is performed in the security countermeasure system 30. Response rule R1 is modified to appropriate content by the operator. Figure 7 shows only the part of the security countermeasure system 30 that is involved in the modification process for response rule R1. Figure 8 is a flowchart showing an example of the modification process for response rule R1.
[0083] In the following explanation, it is assumed that the operator has already obtained design information, countermeasures, and attack examples related to the vehicle 1 to be evaluated. The operator operates the automated countermeasure analysis unit 32 via the security countermeasure system operation unit 39. The operator shown in Figure 7 is different from the expert shown in Figure 3, but the expert may also act as the operator and perform the modification process of countermeasure rule R1.
[0084] First, the operator uses a PC or similar device to input the attack case to be evaluated into the attack case storage unit 40 (S21). Next, the operator inputs the attack case to be evaluated into the countermeasure analysis unit input unit 33 and instructs the system to start the countermeasure rule generation process (S22).
[0085] Next, the automated countermeasure analysis unit 32 performs the countermeasure rule generation process described with reference to Figure 4 (S23). The countermeasure rule generation process performed in step S23 may be the process from step S15 onwards in Figure 4, or the process from step S11 onwards may be repeated.
[0086] After generating the countermeasure rule R1, the automated countermeasure analysis unit 32 determines whether or not to require operator action (S24). If operator action is required (YES in S24), the generated countermeasure rule R1 is presented to the operator (S25).
[0087] The operator determines whether or not the presented countermeasure rule R1 needs to be modified (S26). If the operator determines that the countermeasure rule R1 needs to be modified (YES in S26), the operator modifies the input values to be entered into the automatic countermeasure analysis unit 32 (S27). The input values to be modified are attack examples, countermeasures, etc. After that, the processing from step S21 onwards is performed again with the modified input values.
[0088] If the operator determines that no modification to the corrective action rule R1 is necessary (NO in S26), they approve the corrective action rule R1. The operator then outputs the approved corrective action rule R1 to the corrective action rule distribution unit 38 (S28). The corrective action rule distribution unit 38 distributes the approved corrective action rule R1 to the electronic control unit 10 mounted on the vehicle 1 (S30), and this process ends.
[0089] On the other hand, if no operator action is requested in step S24 (NO in S24), the response rule generation unit 37 outputs the response rule R1 to the response rule distribution unit 38 (S29). The response rule distribution unit 38 distributes the generated response rule R1 to the electronic control device 10 mounted on the vehicle 1 (S30), and this process ends.
[0090] <Example of operation of the electronic control unit> Next, an example of operation of the electronic control unit 10 installed in vehicle 1 will be explained with reference to Figures 9 and 10. The process described below is performed in vehicle 1 during actual operation, and it is assumed that the electronic control unit 10 has already received the response rule R1.
[0091] Figure 9 is a block diagram showing the part of the electronic control device 10 related to automatic response processing. Figure 10 is a flowchart showing an example of automatic response processing.
[0092] First, the attack detection unit 13 of the electronic control unit 10 detects an attack (S31). The detection of an attack by the attack detection unit 13 triggers the initial response. Therefore, the attack detection unit 13 activates the automatic response function of the automatic response implementation unit 15 (S32).
[0093] Next, the automated response unit 15 inputs vehicle status information, including the current status of vehicle 1, which has been acquired by the vehicle status information acquisition unit 14 (S33). Then, based on the vehicle status information, the automated response unit 15 determines the current status of the vehicle and reads out the response rule R1 from the response rule storage unit 19 in accordance with the attack detected by the attack detection unit 13 (S34).
[0094] Next, the automated response unit 15, based on the response rule R1 and the input vehicle status information, if a part of the vehicle status information satisfies the response start condition of response rule R1, performs a primary response to the attack by executing commands, scripts, etc., described in the response content of response rule R1 on the target of response rule R1 until the response end condition of response rule R1 is met (S35). The vehicle control unit 18 controls vehicle 1 based on the primary response (S36).
[0095] The communication unit 11 then transmits information including the details of the attack detected by the attack detection unit 13, the initial response implemented by the automatic response implementation unit 15, and the status of vehicle 1 after the initial response as actual data to the security countermeasure system 30 (S37), and terminates this process. The security countermeasure system 30 stores this received information in the attack case storage unit 40, thereby sharing attack cases between the electronic control unit 10 and the security countermeasure system 30. After step S37, the communication unit 11 may disconnect from the internet 50 to prevent the reception of new attacks.
[0096] <Example of notification screen during initial response> While an attack is detected and the electronic control unit 10 is performing initial response, a notification screen is displayed on the display device 65 of the vehicle 1. Here, an example of the notification screen display is described. Figure 11 is a diagram showing an example of the notification screen displayed on the display device 65 of the vehicle 1.
[0097] Figure 11 shows an example of a notification screen W1, which is displayed when the attack does not significantly affect the behavior of vehicle 1. The upper part W11 of the notification screen W1 displays normal HMI information such as the navigation screen. The lower part W12 of the notification screen W1 shows that suspicious communication or operation has been detected and that initial countermeasures are being taken. It also shows that the attack does not significantly affect the behavior of vehicle 1 and therefore does not affect the driving of vehicle 1.
[0098] Example screen (2) in Figure 11 shows an example of a notification screen W2 that is displayed when an attack significantly affects the behavior of vehicle 1. Significant effects include, for example, a large change in the speed of vehicle 1, or the inability to deal with the attack without performing controls contrary to the driver's intentions. Notification screen W2 is displayed as a pop-up in front of the navigation screen. The entire screen of notification screen W2 warns the driver that suspicious communication or operation has been detected, that the automatic driving mode will be deactivated, that initial countermeasures against the malicious communication or operation are being taken, and that certain operations may be affected. Specific operations include, for example, steering operations and acceleration operations. In addition, an alert sound or message may be broadcast from the in-car speakers along with notification screen W2.
[0099] As shown in Figure 11, different notification screens are displayed depending on whether the attack significantly affects the behavior of vehicle 1. Therefore, the driver can understand from the content of the notification screen what kind of attack is occurring and whether initial countermeasures are being taken.
[0100] If the attack detection unit 13 detects an unknown attack, appropriate countermeasure rules for the unknown attack may not have been created. If the attack does not significantly affect the driving of vehicle 1, a notification screen W1 is displayed containing a message instructing the driver to decelerate vehicle 1 in autonomous driving mode and stop it in a safe place. If the attack significantly affects the driving of vehicle 1, a notification screen W2 is displayed containing a message instructing the driver to switch vehicle 1 from autonomous driving mode to manual driving mode and stop vehicle 1 in a safe place. To assist this driver operation, the vehicle control unit 18 automatically turns on the hazard lights and prevents the vehicle from accelerating beyond a predetermined speed even if the driver presses the accelerator.
[0101] <Process of updating and deploying countermeasure rules> The security countermeasure system 30 collects the behavior of vehicle 1 after an attack occurs on vehicle 1 and countermeasure rule R1 is executed by the electronic control unit 10, thereby enabling a more precise reproduction of the operating status of vehicle 1 that is simulated when formulating the initial countermeasures. Furthermore, by testing new countermeasures in cyberspace where the operating status is precisely reproduced, it also contributes to updating the countermeasure rules for vehicles 1 of the same type. Therefore, the process of updating and deploying countermeasure rule R1 will be explained with reference to Figures 12 and 13.
[0102] Figure 12 is a block diagram showing how the update and deployment of the response rule R1 is performed in the security countermeasure system 30. In Figure 12, only the part of the security countermeasure system 30 related to the update and deployment of the response rule R1 is shown. Figure 13 is a flowchart showing an example of the update and deployment of the response rule R1.
[0103] First, the operational vehicle 1 transmits actual data from the time of the attack to the security countermeasure system 30 (S41). This actual data includes vehicle status information collected by the vehicle status information acquisition unit 14 at the time of the attack, details of the attack, etc. When the security countermeasure system 30 receives the actual data, it stores it as an attack case in the attack case storage unit 40.
[0104] Next, the test vehicle 1A provides experts with data obtained from test runs (S42).
[0105] Next, the experts share and analyze attack cases against vehicle 1 in operation. The experts also analyze attacks based on data from test vehicle 1A (S43). The attack cases shared by the experts may be data directly received from vehicle 1 in operation, or data read from the attack case storage unit 40. Based on the analysis results, if the experts determine that it would be better to refine the countermeasure rules, they input instructions to refine the countermeasure rules. On the other hand, if the experts determine that it would be better to extend the countermeasure rules to vehicle types or vehicle systems 20 similar to vehicle 1, they input instructions to extend the countermeasure rules.
[0106] Next, the response rule deployment unit 41 takes in attack cases from the attack case storage unit 40, and further incorporates the analysis results and instructions from experts (S44). The attack cases and analysis results taken in by the response rule deployment unit 41 are input to the vehicle configuration similarity determination unit 42.
[0107] Next, the vehicle configuration similarity determination unit 42 determines the similarity of the vehicle configurations (S45). The similarity of the vehicle configurations is determined by whether the vehicle type or vehicle system 20 of vehicle 1 or test vehicle 1A is the same as or similar to the vehicle type or vehicle system 20 of other deployable vehicles. The vehicle configuration similarity determination unit 42 then determines whether the vehicle type or vehicle system 20 is the same (S46).
[0108] If the vehicle type or vehicle system 20 is the same (YES in S46), the countermeasure rule generation process shown in Figure 4 is performed to refine the countermeasure rule R1 (S47), and this process ends. In step S47, attack cases based on actual data from the operational vehicle 1 and vehicle status information acquired from the operational vehicle 1 are used, so the countermeasure rule R1 is refined. The refined countermeasure rule R1 updates the countermeasure rule R1 distributed to other vehicles 1 that are the same vehicle type or vehicle system 20 as the operational vehicle 1.
[0109] On the other hand, if the vehicle type or vehicle system 20 is not the same (NO in S46), it is assumed that the vehicle type or vehicle system 20 is similar. In this case, the similar system handling rule generation unit 43 generates a similar system handling rule R2 based on the similarity of the vehicle configuration (S48). The similar system handling rule R2 is a handling rule used for primary response in similar systems that are similar to the vehicle system 20 of the attacked vehicle 1.
[0110] The similar system handling rule R2 generated by the similar system handling rule generation unit 43 is deployed to the similar system (S49), and this process ends. The similar system handling rule R2 is then distributed by the handling rule distribution unit 38 to the vehicle 1 of the corresponding similar vehicle model or vehicle system 20.
[0111] The response rule update process refines and updates response rule R1. Furthermore, the response rule deployment process deploys similar system response rule R2 to vehicles with a vehicle type or vehicle system 20 similar to the attacked vehicle type or vehicle system 20.
[0112] In the security countermeasure system 30 according to the embodiment described above, when a simulated vehicle 1 in cyberspace is attacked, the operating state of the vehicle at the time of the cyberattack and the time of countermeasures is evaluated based on the behavior of the simulated vehicle 1. The security countermeasure system 30 then automatically generates a countermeasure rule R1 based on the state of vehicle 1. In this way, the security countermeasure system 30 can test appropriate countermeasures in cyberspace for each operating state of the vehicle.
[0113] The response rule R1 is distributed to the electronic control unit 10 of the vehicle 1 operating in the real world and stored in the response rule storage unit 19 of the electronic control unit 10. Therefore, if the operating vehicle 1 is attacked, the initial response based on the response rule R1 read from the response rule storage unit 19 is automatically performed, enabling safe control of the vehicle 1. For example, if the vehicle 1 is traveling at high speed, the vehicle control unit 18 can control the vehicle not to immediately stop the vehicle 1 in the driving lane, but to gradually decelerate and move the vehicle 1 to the shoulder before stopping it.
[0114] Furthermore, the electronic control unit 10 extracts a response rule R1 that matches the actual state of vehicle 1 from various anticipated states of vehicle 1, and performs initial countermeasures based on this response rule R1. This enables safe control of vehicle 1. In addition, since the response rule R1 is distributed simultaneously to all vehicles 1 of the same system, the security of vehicle 1 can be enhanced.
[0115] Furthermore, the security countermeasure system 30 can refine the countermeasure rule R1 applicable to the same system as vehicle 1 by collecting attack cases from vehicle 1 on which initial countermeasures have been implemented. The countermeasure rule deployment unit 41 determines the similarity of the components of vehicle 1 and other vehicles based on the hardware and software configuration of vehicle 1. The similar system countermeasure rule generation unit 43 automatically generates a countermeasure rule R1 that can be reused for similar systems as a similar system countermeasure rule R2. As a result, similar systems that receive a similar system countermeasure rule R2 can also perform initial countermeasures against attacks on similar systems. In addition, experts can reduce the effort required to generate the similar system countermeasure rule R2. Therefore, even if a new attack is carried out against vehicle systems of multiple different car models, the generation of initial countermeasure rules to neutralize this attack can be expedited.
[0116] In the embodiment described above, after an expert confirmed the countermeasure rule R1 in advance, the confirmed countermeasure rule R1 was delivered to the electronic control unit 10 of the vehicle 1. However, the expert may be replaced with AI (Artificial Intelligence). If the AI confirms the validity of the countermeasure rule R1 before delivering it to the electronic control unit 10 of the vehicle 1, the process from generating to delivering the countermeasure rule R1 can be automated. Alternatively, the AI may automatically create scenarios for the evaluation target model simulated in cyberspace. By introducing AI, the initial response to attacks on a specific vehicle type can also be automated to adapt to various vehicle types, significantly reducing the manual effort required to generate the countermeasure rule R1 and the time from generation to delivery.
[0117] It should be noted that the present invention is not limited to the embodiments described above, and various other applications and modifications are possible as long as they do not depart from the gist of the present invention as described in the claims. For example, the embodiments described above describe the system configuration in detail and concretely in order to explain the present invention in an easy-to-understand manner, and are not necessarily limited to having all the configurations described. Also, it is possible to add, delete, or replace some of the configurations of these embodiments with other configurations. Furthermore, the control lines and information lines shown are those that are considered necessary for explanation, and do not necessarily represent all control lines and information lines in the actual product. In practice, it can be assumed that almost all configurations are interconnected.
[0118] 1...Vehicle, 10...Electronic control unit, 12...Security function unit, 13...Attack detection unit, 14...Vehicle status information acquisition unit, 15...Automatic countermeasure implementation unit, 17...Control unit, 18...Vehicle control unit, 19...Countermeasure rule storage unit, 20...Vehicle system, 30...Security countermeasure system, 31...Communication unit, 32...Automatic countermeasure analysis unit, 33...Countermeasure analysis unit input unit, 34...Countermeasure analysis unit, 35...Vehicle status information acquisition unit, 36...Countermeasure evaluation unit, 37...Countermeasure rule generation unit, 38...Countermeasure rule distribution unit, 39...Security countermeasure system operation unit, 40...Attack case storage unit, 41...Countermeasure rule deployment unit, 42...Vehicle configuration similarity determination unit, 43...Similar system countermeasure rule generation unit
Claims
1. A security countermeasure system comprising: a countermeasure analysis unit that attacks a target model, which is a model of a vehicle system to be evaluated, in a simulated environment and analyzes the results of executing multiple countermeasures against the attack on the target model; a vehicle status information acquisition unit that acquires vehicle status information indicating the vehicle status of the target model before and after the execution of each of the multiple countermeasures; a countermeasure evaluation unit that outputs an evaluation result of evaluating the multiple countermeasures based on the amount of change in the vehicle status information before and after the execution of the countermeasures; and a countermeasure rule generation unit that generates a countermeasure rule that associates the vehicle status information, the attack, at least one of the multiple countermeasures against the attack, and a countermeasure start condition defined by the vehicle status information for the condition under which the countermeasure is initiated.
2. The security countermeasure system according to claim 1, wherein the countermeasure analysis unit inputs the vehicle state information given by the scenario in which the attack is defined into the evaluation target model, and the countermeasure evaluation unit extracts the countermeasures in which the amount of change in the vehicle state information is within the range of a threshold set for each scenario.
3. The security countermeasure system according to claim 2, comprising an attack case storage unit that stores as past attack cases the attacks that were previously inflicted on the vehicle system in operation and the vehicle status information of the vehicle system that was subjected to the attacks, and the countermeasure analysis unit that analyzes the attacks that were inflicted on the model under evaluation, the behavior of the model under evaluation in response to the attacks, and the countermeasures based on the past attack cases read from the attack case storage unit.
4. The security countermeasure system according to claim 3, which is equipped with the vehicle system that forms the basis of the model to be evaluated, and comprises a countermeasure rule distribution unit that distributes the countermeasure rules to an electronic control unit installed in a vehicle that is operating the vehicle system.
5. The security countermeasure system according to claim 4, comprising a communication unit that collects actual data from the electronic control unit, including the countermeasures carried out in accordance with the countermeasure rules in response to the attack on the vehicle system in operation, and the vehicle status information of the vehicle system resulting from the execution of the countermeasure rules, and stores the data in the attack case storage unit.
6. The security countermeasure system according to claim 5, further comprising a determination unit that determines whether to refine the distributed countermeasure rule or distribute a second countermeasure rule to a vehicle system similar to the vehicle system relating to the evaluation target model, based on the identity or similarity of the vehicle configuration, which includes configuration information indicating the hardware configuration of the vehicle system and version information indicating the software version of the software used in the vehicle system.
7. The security system according to claim 6, wherein, if the determination unit determines that the vehicle configuration is the same and that the distributed countermeasure rule should be refined, the countermeasure analysis unit, the vehicle status information acquisition unit, the countermeasure evaluation unit, and the countermeasure rule generation unit generate the refined countermeasure rule, and the countermeasure rule distribution unit distributes the refined countermeasure rule to the electronic control unit.
8. The security countermeasure system according to claim 6, further comprising a second countermeasure rule generation unit that generates the second countermeasure rule when the determination unit determines that the configuration of the vehicle is similar and that the second countermeasure rule should be distributed to a second vehicle system similar to the vehicle system relating to the model to be evaluated, wherein the countermeasure rule distribution unit distributes the second countermeasure rule to a second electronic control device mounted on a second vehicle that is operating the second vehicle system.
9. The security system according to claim 5, wherein the electronic control device comprises: a countermeasure rule storage unit that stores the countermeasure rules distributed from the countermeasure rule distribution unit; an attack detection unit that detects the attack on the vehicle; a vehicle status information acquisition unit that acquires vehicle status information of the vehicle; and an automatic countermeasure implementation unit that counters the attack using the countermeasure rules read from the countermeasure rule storage unit based on the vehicle status information, and transmits the countermeasure result together with the vehicle status information to the security system.
10. A security countermeasure method comprising: a step of subjecting a target model, which is a model of a vehicle system to be evaluated, to an attack in a simulated environment, and analyzing the results of executing multiple countermeasures against the attack on the target model; a step of acquiring vehicle state information indicating the vehicle state of the target model before and after the execution of each of the multiple countermeasures; a step of outputting an evaluation result that evaluates the multiple countermeasures based on the amount of change in the vehicle state information before and after the execution of the countermeasures; and a step of generating a countermeasure rule that associates the vehicle state information, the attack, at least one of the multiple countermeasures against the attack, and a countermeasure initiation condition defined by the vehicle state information for the condition under which the countermeasure is initiated.
Citation Information
Patent Citations
Evaluation device, evaluation system and evaluation method
JP2017112598A
System and method of generating rules for blocking computer attack on vehicle
JP2019194830A
Analyzing device and analyzing method
JP2023097605A