JP7478085B2 - In-vehicle security device, vehicle security system, and vehicle management method - Google Patents

Description

The present invention generally relates to a technology for processing log information from devices installed in a vehicle.

In recent years, in-vehicle networks using in-vehicle LANs (Local Area Networks) and the like have become increasingly common as an environment for collecting and managing control data from various ECUs (Electrical Control Units) installed in the vehicle. Technologies that utilize these in-vehicle networks include, for example, adding a communication function to the vehicle with other vehicles and external server devices, and using this communication function to collect environmental information used in autonomous driving, driving assistance, and the like, and to update ECU software.

Conventional in-vehicle network systems generally used their own OS and network, and were not configured to connect to external systems. For that reason, it was thought that in-vehicle network systems would not be exposed to security threats such as external attacks by viruses. However, in recent years, the field of in-vehicle network systems has been moving toward openness, and the adoption of general-purpose OS and standard protocols has progressed. Against this background, reports of attacks targeting in-vehicle network systems, which were previously considered safe, are increasing year by year.

If an attack on an in-vehicle network system causes a denial of service or unauthorized access to a vehicle, damage to people and assets may occur. For example, if an attack occurs and a vehicle goes out of control, the personal and property damage may be severe, with a large social impact. For this reason, vehicle manufacturers are being asked to collect and store log information to monitor for the occurrence of attacks on in-vehicle network systems.

Recently, technology has been disclosed that can detect attacks that exploit vulnerabilities at an early stage and reduce processing load by adjusting the execution cycle of detection rules (see Patent Document 1).

JP 2020-28092 A

The technology described in Patent Document 1 has the problem that the amount of log information to be managed becomes enormous, and processing the vast amount of log information puts strain on the processor, memory, and other resources of the computer installed in the vehicle.

The present invention was made in consideration of the above points, and aims to propose an in-vehicle security device etc. that can properly process log information from devices installed in a vehicle.

In order to solve this problem, the present invention provides an in-vehicle security device that is mounted on a vehicle equipped with a specified device, and includes an attack information storage unit that stores attack information indicating an attack on the device, a log information storage unit that stores log information about the device, and a log management unit that extracts log information related to the attack information stored in the attack information storage unit from the log information stored in the log information storage unit and transmits the extracted log information to an attack countermeasure device that provides countermeasures against attacks on the device.

The present invention makes it possible to appropriately process log information from devices installed in a vehicle.

FIG. 1 is a diagram showing an example of a configuration of a vehicle security system. FIG. 2 is a diagram illustrating an example of a hardware configuration of a vehicle. FIG. 2 is a diagram illustrating an example of a hardware configuration of a roadside unit and an attack countermeasure device. FIG. 2 is a diagram illustrating an example of a functional configuration of an in-vehicle security device. FIG. 2 is a diagram illustrating an example of a functional configuration of an attack countermeasure device. FIG. 11 is a diagram for explaining attack information. FIG. 11 is a diagram for explaining attack information. FIG. 11 is a diagram for explaining attack information. FIG. 4 illustrates an example of a log information storage unit; FIG. 2 is a diagram illustrating an example of a vehicle configuration information storage unit. FIG. 4 illustrates an example of an attack information storage unit. FIG. 4 illustrates an example of a countermeasure information storage unit; FIG. 11 is a diagram illustrating an example of attack detection information. FIG. 11 is a diagram illustrating an example of incident information. FIG. 4 is a diagram illustrating an example of an in-vehicle configuration information storage unit. FIG. 11 illustrates an example of an initial setting process. FIG. 2 is a diagram showing an example of a series of processes in a vehicle security system. FIG. 13 illustrates an example of an attack detection process. FIG. 13 illustrates an example of an attack countermeasure process. 13 is an example of a log information management process.

(1) First embodiment Hereinafter, one embodiment of the present invention will be described in detail. However, the present invention is not limited to the embodiment.

The in-vehicle security device according to this embodiment collects log information for detecting and analyzing attacks within the in-vehicle network. The in-vehicle security device stores attack information that can identify the device for which log information is to be collected and the type of log information to be collected in response to attacks on devices connected to the in-vehicle network. The in-vehicle security device, for example, collects log information based on the attack information, and extracts log information related to the attack from the collected log information based on the attack information. According to the above configuration, for example, it is possible to efficiently store and transmit log information in response to attacks anticipated in the in-vehicle network.

Next, an embodiment of the present invention will be described with reference to the drawings. The following description and drawings are examples for explaining the present invention, and appropriate omissions and simplifications have been made to clarify the explanation. The present invention can also be implemented in various other forms. Unless otherwise specified, each component may be singular or plural. In the following explanation, the same elements in the drawings will be given the same numbers, and explanations will be omitted as appropriate.

Figure 1 is a diagram showing an example of the configuration of a vehicle security system 100 in this embodiment. The vehicle security system 100 includes a vehicle 110, a roadside unit 120, and an attack countermeasure device 130.

The vehicle 110 is equipped with an on-board security device 111. The roadside unit 120 is fixedly installed at a predetermined point on the side of the road on which the vehicle 110 travels. Note that multiple roadside units 120 may be installed at different points. The roadside unit 120 and the attack countermeasure device 130 are connected to each other via a network 101. The attack countermeasure device 130 communicates with the on-board security device 111 via the network 101 and the roadside unit 120. Note that the on-board security device 111 and the attack countermeasure device 130 may communicate with each other via, for example, a general communication network, without going through the network 101 and the roadside unit 120.

Note that FIG. 1 shows an example in which the vehicle security system 100 includes two vehicles 110. However, the number of vehicles 110 included in the vehicle security system 100 is not limited to two. The operation of the on-board security device 111 installed in each vehicle 110 is similar. Therefore, the following explanation focuses on one of the multiple vehicles 110 and focuses on the operation of the on-board security device 111 installed in the target vehicle 110.

Figure 2 is a diagram showing an example of the hardware configuration of vehicle 110.

The in-vehicle security device 111 mounted on the vehicle 110 includes a storage device 210, a CPU 220, and a memory unit 230. The storage device 210 is, for example, an auxiliary storage device such as a HDD or flash memory. The CPU 220 controls the in-vehicle security device 111 by, for example, reading and executing a specific program stored in the storage device 210 or the like. The memory unit 230 is a main storage device used when the CPU 220 executes a program.

The CPU 220 functionally comprises a log management unit 221, an initial setting unit 222, an attack management unit 223, an attack detection unit 224, a countermeasure processing unit 225, and a warning processing unit 226. That is, the functions of the in-vehicle security device 111 (log management unit 221, etc.) are realized in software by a program executed by the CPU 220. The functions of the in-vehicle security device 111 may be realized by an electronic circuit such as an FPGA. Furthermore, one function of the in-vehicle security device 111 may be divided into multiple functions, or multiple functions may be combined into one function. Furthermore, some of the functions of the in-vehicle security device 111 may be provided as a separate function, or may be included in another function. Furthermore, some of the functions of the in-vehicle security device 111 may be realized by another computer that can communicate with the in-vehicle security device 111.

The vehicle 110 also includes a GW device 240, one or more devices belonging to a control system network 250, one or more devices belonging to an assist system network 260, one or more devices belonging to an information system network 270, and a mobile router 280.

In each network, devices in the same network can communicate data directly without going through the GW device 240. For example, in the control network 250, communication is performed for driving control of the vehicle 110. In the assist network 260, communication is performed for the assist function of the vehicle 110. The assist function of the vehicle 110 is autonomous driving, driving assistance, etc. In the following, when there is no distinction between the autonomous driving of the vehicle 110 and the driving assistance of the vehicle 110, it is referred to as the "assist function". In the information network 270, communication is performed for a user interface for the driver (user) of the vehicle 110. On the other hand, communication is performed between devices in different networks via the GW device 240.

The control system network 250 is connected to a steering ECU 251, a brake ECU 252, and an engine ECU 253. The assist system network 260 is connected to an ADAS ECU 261, a brake control ECU 262, a steering control ECU 263, an engine control ECU 264, a camera 265, a GPS sensor 266, an acceleration sensor 267, and an MPU (Map Processing Unit) 268. The information system network 270 is connected to a wireless communication device 271, a user switch 272, a display device 273, and a navigation system 274.

The devices connected to the control network 250, the devices connected to the assist network 260, and the devices connected to the information network 270 are connected to the in-vehicle security device 111 via the GW device 240. The mobile router 280 is also wirelessly connected to the in-vehicle security device 111 via the wireless communication device 271.

The steering ECU 251 controls the steering mechanism of the vehicle 110 to control the traveling direction of the vehicle 110 in response to a steering operation by the user of the vehicle 110 or a steering control command transmitted from the steering control ECU 263. The brake ECU 252 controls the brakes of the vehicle 110 to control deceleration in response to a braking operation by the user of the vehicle 110 or a brake control command transmitted from the brake control ECU 262. The engine ECU 253 controls the engine of the vehicle 110 to control the speed of the vehicle 110 in response to the running state of the vehicle 110 or an engine control command transmitted from the engine control ECU 264. The running of the vehicle 110 is controlled by these devices.

The ADAS ECU 261 determines the acceleration, deceleration, and stoppage of the vehicle 110 from information inside and outside the vehicle 110, and realizes the assist function of the vehicle 110 using the determined results. The ADAS ECU 261 determines the behavior of the vehicle 110 by referring to images acquired from the camera 265, the position of the vehicle 110 acquired from the GPS sensor 266, map information held by the MPU 268, and the like. The ADAS ECU 261 then instructs the brake control ECU 262, steering control ECU 263, and engine control ECU 264 to each output a control command according to the determined behavior of the vehicle 110.

The brake control ECU 262 transmits a brake control command including a brake strength to the brake ECU 252 in response to an instruction from the ADAS ECU 261. The steering control ECU 263 transmits a steering control command including a steering operation angle to the steering ECU 251 in response to an instruction from the ADAS ECU 261. The engine control ECU 264 transmits an engine control command including an engine speed to the engine ECU 253 in response to an instruction from the ADAS ECU 261. The camera 265 outputs an image of the surroundings of the vehicle 110 to the ADAS ECU 261. The GPS sensor 266 receives a signal from a satellite and measures the position of the vehicle 110. The acceleration sensor 267 detects the acceleration in the forward/rearward direction and the acceleration in the left/right direction of the vehicle 110. The MPU 268 holds map information such as the road shape around the vehicle 110. This map information is used by the ADAS ECU 261 for the assist function. These devices execute the assist function of the vehicle 110.

The wireless communication device 271 is connected to the in-vehicle security device 111, and wirelessly communicates with the roadside device 120 directly or via the mobile router 280. The user switch 272 detects a predetermined input operation by the user of the vehicle 110. The user of the vehicle 110 uses the user switch 272, for example, when switching the assist function of the vehicle 110 from disabled to enabled, or from enabled to disabled. The display device 273 is a liquid crystal monitor or the like, and displays various information to the user. For example, when the assist function is enabled in the vehicle 110, the display device 273 displays that the assist function is enabled, so that the user can understand the state of the vehicle 110. The navigation system 274 holds map information such as road shapes, and provides map information around the vehicle 110 in response to a request from the user or the ADAS ECU 261. These devices provide a user interface for the user of the vehicle 110.

Figure 3 is a diagram showing an example of the hardware configuration of the roadside unit 120 and the attack countermeasure device 130. The roadside unit 120 and the attack countermeasure device 130 are connected via a network 101.

The roadside unit 120 includes a wireless transceiver unit 310 and a roadside unit control unit 320. The wireless transceiver unit 310 transmits and receives information about the vehicle 110 and information about the attack countermeasure device 130. The wireless transceiver unit 310 communicates with the in-vehicle security device 111 mounted on the vehicle 110 by transmitting and receiving wireless signals. The roadside unit control unit 320 controls the roadside unit 120. The roadside unit control unit 320 is connected to the network 101 and communicates with the attack countermeasure device 130 via the network 101. The roadside unit control unit 320 also controls the wireless transceiver unit 310 to transmit information received from the attack countermeasure device 130 to the vehicle 110 and to transmit information received from the vehicle 110 to the attack countermeasure device 130.

The attack countermeasure device 130 includes a storage device 330, a CPU 340, and a memory unit 350. The storage device 330 is configured using a non-volatile storage device such as a flash memory or a HDD. The CPU 340 uses information stored in the storage device 330 and information received from the roadside unit 120 to execute a program in the memory unit 350, thereby considering countermeasures against an attack detected in the vehicle 110, for example. The memory unit 350 is a main storage device used by the CPU 340 when executing the program.

The CPU 340 functionally comprises a transmission/reception information processing unit 341, an attack information generating unit 342, and a countermeasure management unit 343. That is, the functions of the attack countermeasure device 130 (such as the transmission/reception information processing unit 341) are realized in software by a program executed by the CPU 340. The functions of the attack countermeasure device 130 may be realized by an electronic circuit such as an FPGA. One function of the attack countermeasure device 130 may be divided into multiple functions, or multiple functions may be combined into one function. In addition, some of the functions of the attack countermeasure device 130 may be provided as a separate function, or may be included in another function. In addition, some of the functions of the attack countermeasure device 130 may be realized by another computer that can communicate with the attack countermeasure device 130.

Figure 4 is a diagram showing an example of the functional configuration of the in-vehicle security device 111. The storage device 210 includes a log information storage unit 410, a vehicle configuration information storage unit 420, an attack information storage unit 430, and a countermeasure information storage unit 440. Each storage unit may be a database.

The GW device 240 relays communications between the networks. For example, the GW device 240 transfers brake control instructions sent from the brake control ECU 262 of the assist system network 260 to the brake ECU 252 of the control system network 250 between these networks. Communication is performed between devices in the same network and between devices in different networks using vehicle information packets. When the GW device 240 receives a vehicle information packet transmitted and received between the devices, it stores (e.g., appends) the information contained in the vehicle information packet as log information 411 in the log information storage unit 410. That is, the information contained in the vehicle information packet is stored in chronological order in the log information storage unit 410 as log information 411.

The log management unit 221 extracts log information 411 related to the attack information 431 stored in the attack information storage unit 430 from the log information storage unit 410 at a predetermined timing, and transmits the extracted log information 411 to the attack countermeasure device 130 or stores it in the log information storage unit 410. Whether the log information 411 is related to the attack information 431 is determined, for example, by whether the log content of the log information 411 matches the detection content of the attack information 431. At a predetermined timing, periodically, when the attack detection unit 224 detects an attack, when the storage capacity of the storage device 210 assigned to the log information storage unit 410 exceeds a predetermined capacity, etc.

The initial setting unit 222 communicates with the roadside unit 120 using the wireless communication device 271, and transmits the vehicle configuration information 421 to the attack countermeasure device 130 via the roadside unit 120. The attack management unit 223 receives attack information 431 corresponding to the vehicle configuration information 421 transmitted by the attack countermeasure device 130. The attack management unit 223 stores the received attack information 431 in the attack information storage unit 430. Note that the initial setting unit 222 may be included in the attack management unit 223.

The attack detection unit 224 detects an attack on the equipment of the vehicle 110 based on the attack information 431 stored in the attack information storage unit 430 and the log information 411 stored in the log information storage unit 410. When the attack detection unit 224 detects an attack, it communicates with the roadside unit 120 using the wireless communication device 271, and transmits attack detection information 450 and incident information 460 related to the detected attack to the attack countermeasure device 130 via the roadside unit 120. The attack detection information 450 and incident information 460 include the location where the attack was detected, the software version of the attacked equipment, the cause of the attack, the date and time of the attack detection, etc. When the attack detection unit 224 detects an attack, it outputs a notification that the attack has been detected to the warning processing unit 226. The warning processing unit 226 displays a warning to the user via the display device 273, etc.

The countermeasure processing unit 225 communicates with the roadside unit 120 using the wireless communication device 271, and receives countermeasure information 441 of countermeasures against an attack detected by the attack detection unit 224 from the attack countermeasure device 130 via the roadside unit 120. The countermeasure processing unit 225 stores the received countermeasure information 441 in the countermeasure information storage unit 440. The countermeasure information 441 is information for implementing countermeasures against an attacked device. The countermeasure information 441 includes, for example, backdate commands and configuration files for software running on the attacked device.

Figure 5 is a diagram showing an example of the functional configuration of the attack countermeasure device 130. The storage device 330 includes a log information storage unit 510, a vehicle configuration information storage unit 520, an attack information storage unit 530, a countermeasure information storage unit 540, and a vulnerability information storage unit 550. Each storage unit may be a database.

The transmission/reception information processing unit 341 receives information from the roadside unit 120 and transmits information to the roadside unit 120. For example, the transmission/reception information processing unit 341 receives log information 411 transmitted from the vehicle 110 via the roadside unit 120. The transmission/reception information processing unit 341 stores the log information 411 received from the vehicle 110 in the log information storage unit 510.

When the attack information generation unit 342 receives vehicle configuration information 421 including information such as the configuration of the equipment equipped in the vehicle 110 and the software version of the equipment, the attack information generation unit 342 extracts attack information 431 against the equipment configuration and software version of the equipment corresponding to the vehicle 110 from the attack information storage unit 530, and transmits it to the vehicle 110 via the transmission/reception information processing unit 341.

Based on the received attack detection information 450, the countermeasure management unit 343 acquires countermeasure information 441 corresponding to the attack detected by the attack detection unit 224 from the countermeasure information storage unit 540, and transmits the acquired countermeasure information 441 to the vehicle 110 via the transmission/reception information processing unit 341. The countermeasure management unit 343 also extracts the vehicle configuration information from the vehicle configuration information storage unit 520, and extracts vulnerability information for the vehicle configuration information from the vulnerability information storage unit 550. The countermeasure management unit 343 searches the log information storage unit 510 for an attack that matches the vulnerability information, and if found, generates countermeasure information 441 for preventing the vulnerability information and stores it in the countermeasure information storage unit 540. The countermeasure management unit 343 may transmit the generated countermeasure information 441 to the vehicle 110 via the transmission/reception information processing unit 341. In addition, commonly available information such as CVE (Common Vulnerabilities and Exposures) and CWE (Common Weakness Enumeration) may be used as vulnerability information, and illustration and description of the vulnerability information storage unit 550 will be omitted.

Next, attack information 431 indicating an attack will be described using Figures 6A, 6B, and 6C. In the following, one attack will be described as an attack scenario that combines attacks (attack scenario elements) in stages (attack stages) that make up the attack. Figure 6C shows an attack scenario 600, which is an example of attack information 431. Attack scenario 600 includes information describing the order in which attack scenario elements occur from the first attack stage to the final attack stage. Note that the attack scenario element in the final attack stage may be referred to as an "incident."

Figure 6A is a diagram showing the attack stages (hierarchies) of the attack scenario 600. Figure 6B is a diagram showing the relationships between seven vulnerabilities in the wireless communication device 271. Figure 6C is a diagram showing the details of the attack scenario 600. Note that a vulnerability is a defect in software, hardware, etc. that may be subject to attack.

The attack scenario 600 includes information on the attack stage 601, vulnerability ID 602, attack method 603, detection location 604, and detection content 605.

Attack stage 601 indicates the stage of an attack on vehicle 110. For example, FIG. 6A shows four attack stages. Each attack stage is defined as attack preparation, attack, installation, and remote control, and if the remote control attack in the fourth attack stage is successful, the vehicle 110 will be operated and the impact on the user will become apparent. In this attack scenario 600, it is shown that the risk of an attack increases as the attack stage progresses, and when the attack method in each attack stage is executed and successful, the attack progresses to the next attack stage.

Vulnerability ID 602 indicates a number that can uniquely identify a vulnerability that is already a target of attack. For example, a number is assigned to a case where software that is susceptible to an attack has been discovered under existing conditions such as a software version, and the vulnerability has been identified. In FIG. 6C, for example, the vulnerability ID "CWE-284" is set as a uniquely identifiable number for a vulnerability due to inadequate access restrictions.

Attack method 603 indicates a method of attacking the vulnerability of vulnerability ID 602. For example, an attack method of sending an SMS message to the number of wireless communication device 271 has already been discovered for the vulnerability of inadequate access restrictions. Detection location 604 indicates a location where an attack on the vulnerability of vulnerability ID 602 is detected. For example, it indicates that the location where an attack on the vulnerability of vulnerability ID 602 "CWE-284" is detected is wireless communication device 271. Detection content 605 indicates a method of detecting an attack on the vulnerability of vulnerability ID 602. For example, an attack on the vulnerability of inadequate access restrictions for vulnerability ID 602 "CWE-284" can be detected by access from a phone number other than the pre-registration list.

The following describes an example of an attack that uses four of the seven vulnerabilities present in wireless communication device 271. More specifically, this shows an example in which the configuration file of wireless communication device 271 is rewritten by an SMS message received by wireless communication device 271 using wireless communication, causing software updates from an unauthorized server device to be performed in wireless communication device 271, resulting in wireless communication device 271 being remotely and unauthorizedly controlled by a malicious third party. This example shows a case in which one attack scenario 600 is divided into attack scenario elements A1 to A4, and the attack shown in attack scenario 600 is realized by exploiting vulnerabilities at each attack stage.

As shown in FIG. 6A, attack scenario element A1 corresponds to the preparation stage of an attack. In the preparation stage of an attack, when a malicious third party becomes aware of the existence of a vulnerability due to an SMS message, the malicious third party sends an SMS message to a random telephone number in order to search for a vehicle 110 having the corresponding vulnerability. At this time, the in-vehicle security device 111 detects that the wireless communication device 271 has received a call from a telephone number different from a pre-set number list, thereby detecting an attack against the wireless communication device 271 as a violation of the access policy.

Attack scenario element A2 corresponds to the start of the attack. In the start of the attack, an attacker who has confirmed the vulnerability of the wireless communication device 271 sends a malicious program to the wireless communication device 271 via an SMS message and starts the attack. When the wireless communication device 271 receives the malicious program and the settings of the wireless communication device 271 are changed, the access control that is set to allow downloading of only specified programs from specified server devices is released. At this time, the in-vehicle security device 111 detects that the setting file that implements the access control in the wireless communication device 271 has been updated without permission, and thereby detects an attack on the wireless communication device 271 as a violation of the security policy.

Attack scenario element A3 corresponds to the installation stage of the attack. In the installation stage of the attack, the attacker makes the wireless communication device 271 download a file from an unauthorized server device. At this time, the in-vehicle security device 111 detects an attack on the wireless communication device 271 as a violation of the security policy by detecting changes to the program installation authority in the wireless communication device 271, detection of unauthorized installation, access to an unauthorized server device, etc.

Attack scenario element A4 corresponds to the remote control stage of the attack. In the remote control stage of the attack, the attacker causes the wireless communication device 271 to execute a file downloaded from an unauthorized server device, causing the wireless communication device 271 to perform unauthorized communication with the GW device 240. At this time, the in-vehicle security device 111 detects the transmission of unauthorized control commands from the wireless communication device 271 to the GW device 240 and the access at an unauthorized time, thereby detecting the attack as a violation of the access policy against the wireless communication device 271.

Here, the vulnerabilities used in the attack scenario 600 are mutually causally related, and in order to realize a certain attack scenario element, the preceding attack scenario element must have already been realized. For this reason, in the vehicle security system 100, the in-vehicle security device 111 is provided with an attack information storage unit 430 that stores various attack scenarios 600 that hierarchically show vulnerabilities that are mutually related. For example, when an attack is detected by the attack detection unit 224, the countermeasure processing unit 225 of the in-vehicle security device 111 identifies a vulnerability related to the detected attack based on the attack information storage unit 430, and takes provisional measures against the equipment having the vulnerability. This makes it possible to quickly implement provisional measures against appropriate equipment in response to an attack that occurs in the vehicle 110.

Note that the attack scenario 600 shown in FIG. 6C is just an example, and various other attacks can be detected by the in-vehicle security device 111. In addition, the attack scenario 600 may be prepared for each device installed in the vehicle 110.

Figure 7 is a diagram showing an example of the log information storage unit 410 (log information table 700). Note that the log information storage unit 510 has the same data structure as the log information storage unit 410, so illustration and description are omitted.

The log information table 700 stores the following information: log information number 701, date and time 702, device type 703, and log content 704. The log information number 701 indicates a number that can uniquely identify the log information 411. The date and time 702 indicates the date and time when the log information 411 was acquired. The device type 703 indicates the type of device that transmitted the vehicle information packet used to generate the log information 411. The log content 704 indicates the content of the log information 411.

Figure 8 is a diagram showing an example of the vehicle configuration information storage unit 420 (vehicle configuration information table 800). The vehicle configuration information table 800 stores each piece of information: vehicle model ID 801, vehicle ID 802, device type 803, NW domain 804, and software version 805. The vehicle model ID 801 indicates information that can identify the vehicle model of the vehicle 110. The vehicle ID 802 indicates information that can identify the vehicle 110. The device type 803 indicates the type of device installed in the vehicle 110. The NW domain 804 indicates the network to which the device installed in the vehicle 110 is connected. The software version 805 indicates the version of the software of the device installed in the vehicle 110.

Figure 9 is a diagram showing an example of the attack information storage unit 430 (attack scenario table 900). In the attack scenario table 900, the information shown in Figure 9 is stored for each attack scenario element that constitutes the attack scenario 600. Note that the attack information storage unit 530 has the same data structure as the attack information storage unit 430, so illustrations and explanations are omitted.

The attack scenario table 900 stores the following information: attack scenario number 901, attack scenario element number 902, attack stage 903, vulnerability ID 904, attack method 905, detection location 906, detection content 907, and related software information 908. The attack scenario number 901 indicates a number that can uniquely identify the attack scenario 600. The attack scenario element number 902 indicates a number that can uniquely identify an attack (attack scenario element) including the attack stage 903, vulnerability ID 904, attack method 905, detection location 906, detection content 907, etc.

Attack stage 903 indicates the stage at which the attack has progressed among the attack stages from the first attack stage to the last attack stage. Vulnerability ID 904 indicates a number that can uniquely identify the vulnerability of the target of attack. Attack method 905 indicates the attack method used when attacking the vulnerability. Detection location 906 indicates the location where the attack can be detected. Detection content 907 indicates the content in log information 411 where the attack can be detected. Related software information 908 indicates a number that can identify software having the vulnerability of the target of attack. Related software information 908 includes information such as product type, vendor name, product name, version, whether or not there is an update, edition, and language. Related software information 908 may be information that can identify the software, and CPE (Common Platform Enumeration) or the like may be used.

Figure 10 is a diagram showing an example of the countermeasure information storage unit 440 (countermeasure information table 1000). Note that the countermeasure information storage unit 540 has the same data structure as the countermeasure information storage unit 440, so illustration and description are omitted.

The countermeasure information table 1000 stores information on countermeasure information ID 1001, vulnerability ID 1002, attack method 1003, related software information 1004, and countermeasure 1005. The countermeasure information ID 1001 indicates a number that can uniquely identify the countermeasure information 441. The vulnerability ID 1002 indicates a number that can uniquely identify the vulnerability of the target of attack. The attack method 1003 indicates an attack method used when attacking the vulnerability. The related software information 1004 indicates a number that can identify software having the vulnerability of the target of attack. The countermeasure 1005 indicates a countermeasure against the attack method. The countermeasure 1005 may include measures to prevent the attack method, measures to allow the attack and not deal with the attack if there is no method to detect it, or there is no impact on assets, etc.

Figure 11 is a diagram showing an example of attack detection information 450 (attack detection information table 1100). The in-vehicle security device 111 detects attacks from all attack stages, not just the final attack stage, from the log information 411, and collects information related to the attack as attack detection information 450. When the attack detection information 450 is notified to the attack countermeasure device 130, the attack countermeasure device 130 considers countermeasures against vulnerabilities that correspond to the detected attack scenario elements.

The attack detection information table 1100 stores the following information: attack detection information ID 1101, judgment date and time 1102, incident judgment result 1103, related attack scenario number 1104, matching attack scenario element number 1105, vulnerability ID 1106, log information number 1107, and related software information 1108.

The attack detection information ID 1101 indicates a number that can uniquely identify the attack detection information 450. The judgment date and time 1102 indicates the date and time when the incident judgment was performed. The incident judgment result 1103 indicates the judgment result as to whether or not an incident has occurred. When it is judged that an incident has occurred, "○" is set in the incident judgment result 1103, and "×" is set otherwise.

The related attack scenario number 1104 indicates the attack scenario number of the attack scenario 600 composed of the matching attack scenario element ID. The matching attack scenario element number 1105 indicates the attack scenario element number of the attack scenario element whose log content of the log information 411 matches the detection content of the attack scenario element of the attack scenario 600 when determining whether the log information 411 matches the detection content of the attack scenario element of the attack scenario 600 when determining whether the log information 411 matches the detection content of the attack scenario element. The vulnerability ID 1106 indicates a number that can uniquely identify the vulnerability of the target of attack. The log information number 1107 indicates a number that can uniquely identify the log information 411 that matches the detection content of the attack scenario element. The related software information 1108 indicates a number that can identify the software having the vulnerability of the target of attack.

Figure 12 is a diagram showing an example of incident information 460 (incident information table 1200). When the in-vehicle security device 111 detects an incident, that is, an attack of attack stage "4", from the log information 411, the in-vehicle security device 111 collects information related to the attack and sets it as incident information 460. When the attack countermeasure device 130 is notified of the incident information 460, if the attack countermeasure device 130 determines that countermeasures cannot be implemented, it may stop using the corresponding vehicle 110 and consider new countermeasures by analyzing the log information 411. Note that the in-vehicle security device 111 may set a priority for the log information 411, and when it becomes necessary to store the log information 411 in the log information storage unit 410, the log information 411 with the log information number included in the incident information 460 may be stored preferentially.

The incident information table 1200 stores the following information: judgment date and time 1201, attack scenario number 1202, detection judgment 1203, attack scenario element number 1204, attack stage 1205, vulnerability ID 1206, attack method 1207, detection location 1208, log information number 1209, and related software information 1210.

The judgment date and time 1201 indicates the date and time when the incident was judged. The attack scenario number 1202 indicates the attack scenario number of the attack scenario 600 judged to be related to the incident. The detection judgment 1203 indicates the result of comparing the attack scenario 600 judged to be related to the incident with the log information 411 and judging whether there is a match or a mismatch. The attack scenario element number 1204 indicates a number that can uniquely identify the attack, including the attack stage 1205, the vulnerability ID 1206, the attack method 1207, the detection location 1208, etc.

Attack stage 1205 indicates the stage at which the attack has progressed among the attack stages from the first attack stage to the final attack stage. Vulnerability ID 1206 indicates a number that can uniquely identify the vulnerability of the target of attack. Attack method 1207 indicates the attack method used when attacking the vulnerability. Detection location 1208 indicates the location at which the attack indicated by attack scenario element number 1204 can be detected. Log information number 1209 indicates a number that can uniquely identify log information 411 that matches the detection content of the attack scenario element. Related software information 1210 indicates a number that can identify software having the vulnerability of the target of attack.

Figure 13 shows an example of the vehicle configuration information storage unit 520 (vehicle configuration table 1300).

The vehicle configuration table 1300 stores information on vehicle model ID 1301, device type 1302, network domain 1303, and software version 1304. The vehicle model ID 1301 indicates information that can identify the vehicle model of the vehicle 110. The device type 1302 indicates the type of device installed in the vehicle 110. The network domain 1303 indicates the network to which the device installed in the vehicle 110 is connected. The software version 1304 indicates the version of the software of the device installed in the vehicle 110.

Figure 14 is a diagram showing an example of the initial setting process executed by the CPU 220 of the in-vehicle security device 111. The initial setting process is executed by the CPU 220 when the in-vehicle security device 111 is started up.

At S1401, the CPU 220 acquires the vehicle configuration information 421 at the time of this startup (current) from the GW device 240. The GW device 240 collects information from the devices installed in the vehicle 110 and acquires the current vehicle configuration information 421.

In S1402, the CPU 220 compares the current vehicle configuration information 421 with the vehicle configuration information 421 (past vehicle configuration information 421) stored in the vehicle configuration information storage unit 420, and determines whether there has been a change between the current configuration of the vehicle 110 and the past configuration of the vehicle 110. If the CPU 220 determines that there has been a change in the configuration of the vehicle 110, it proceeds to S1403, and if it determines that there has been no change in the configuration of the vehicle 110, it proceeds to S1406. The configuration of the vehicle 110 refers to at least one of the software configuration of the equipment mounted on the vehicle 110 and the system configuration of the equipment mounted on the vehicle 110. The past vehicle configuration information 421 may be the vehicle configuration information 421 at the time of the previous startup, or the vehicle configuration information 421 after the software of the equipment has been updated.

At S1403, the CPU 220 transmits the current vehicle configuration information 421 to the attack countermeasure device 130 and requests the attack scenario 600 corresponding to the vehicle configuration information 421 (attack scenario request).

In S1404, the CPU 220 determines whether or not the attack scenario 600 has been received from the attack countermeasure device 130. If the CPU 220 determines that the attack scenario 600 has been received, it stores the attack scenario 600 in the attack information storage unit 430 and proceeds to S1406. If the CPU 220 determines that the attack scenario 600 has not been received, it proceeds to S1405.

In S1405, the CPU 220 sends (retries) the attack scenario request a specified number of times until it receives the attack scenario 600 from the attack countermeasure device 130.

At S1406, the CPU 220 starts the in-vehicle security device 111 and ends the initial setting process.

Figure 15 is a diagram showing an example of a series of processes executed in the vehicle security system 100. First, the process related to the log information 411 will be described.

In S1511, when the GW device 240 generates the log information 411 from the vehicle information packet, the GW device 240 stores the generated log information 411 in the log information storage unit 410. In S1512, the GW device 240 transmits the log information 411 to the in-vehicle security device 111.

In S1521, the in-vehicle security device 111 receives the log information 411 from the GW device 240. In S1522, the in-vehicle security device 111 sets a priority related to the attack in the log information 411. For example, the in-vehicle security device 111 determines whether the log content of the log information 411 is related (for example, matches) to the detection content of the attack scenario 600 stored in the attack information storage unit 430. If the in-vehicle security device 111 determines that the log content is related, it sets the attack stage of the attack scenario 600 that is determined to be related as the priority. If the in-vehicle security device 111 determines that the attack scenario 600 is not related, it sets the priority to the lowest value (for example, "0"). Note that, as for the priority, information indicating the progress of the attack, the impact of the attack, etc., such as the size of the attack stage of the attack scenario and the importance of the attack location, can be appropriately adopted. Note that the priority may be included in the log information 411 and stored, or the priority may be associated with the log information number of the log information 411 to which the priority is set and stored in the storage device 210.

In S1523, the in-vehicle security device 111 periodically transmits the log information 411 to the attack countermeasure device 130 based on the priority. For example, the in-vehicle security device 111 transmits to the attack countermeasure device 130 the log information 411 in which a priority value greater than a predetermined value is set. For example, if the predetermined value is "0", the in-vehicle security device 111 extracts the log information 411 related to the attack from the log information storage unit 410 and transmits it to the attack countermeasure device 130.

At S1531, the attack countermeasure device 130 stores the log information 411 transmitted from the in-vehicle security device 111 in the log information storage unit 510.

Next, the process related to attacks on devices mounted on the vehicle 110 will be described. In S1524, the in-vehicle security device 111 periodically executes an attack detection process. In the attack detection process, if an attack is detected, attack detection information 450 is sent to the attack countermeasure device 130, and if an incident is detected, incident information 460 is sent to the attack countermeasure device 130. The attack detection process will be described later with reference to FIG. 16.

At S1532, the attack countermeasure device 130 receives the attack detection information 450 and the incident information 460. At S1533, the attack countermeasure device 130 executes the attack countermeasure process. In the attack countermeasure process, countermeasures against the attack are considered, and countermeasure information 441 against the attack is transmitted to the in-vehicle security device 111. The attack countermeasure process will be described later with reference to FIG. 17.

At S1525, the in-vehicle security device 111 receives countermeasure information 441 from the attack countermeasure device 130, stores the countermeasure information 441 in the countermeasure information storage unit 440, and transmits a countermeasure instruction to the GW device 240 so that the device in which the attack has been detected can execute countermeasures based on the countermeasure information 441.

In S1513, the GW device 240 transmits the countermeasure instruction received from the in-vehicle security device 111 to the device in which the attack was detected. The device implements countermeasures against the attack in accordance with the countermeasure instruction from the in-vehicle security device 111.

Figure 16 shows an example of an attack detection process that is periodically executed by the CPU 220 of the in-vehicle security device 111.

In S1601, the CPU 220 retrieves unprocessed log information 411 from the log information storage unit 410.

At S1602, the CPU 220 retrieves the attack scenario 600 from the attack information storage unit 430.

In S1603, the CPU 220 determines whether or not all of the attack scenarios 600 acquired in S1602 have been processed. If the CPU 220 determines that all of the attack scenarios 600 acquired in S1602 have been processed, it ends the attack detection process. If the CPU 220 determines that some of the attack scenarios 600 acquired in S1602 have not been processed, it selects one attack scenario 600 that has not been processed as the processing target and proceeds to S1604.

In S1604, the CPU 220 determines whether or not all of the attack scenario elements included in the attack scenario 600 being processed have been processed. If the CPU 220 determines that all of the attack scenario elements included in the attack scenario 600 being processed have been processed, it transfers processing to S1603. If the CPU 220 determines that some of the attack scenario elements included in the attack scenario 600 being processed have not been processed, it transfers processing to S1605, with one attack scenario element that has not been processed being the processing target.

In S1605, the CPU 220 determines whether the log contents of the log information 411 acquired in S1601 match the detection contents of the attack scenario element being processed. If the CPU 220 determines that the log contents of the log information 411 match the detection contents of the attack scenario element being processed, it transfers processing to S1606, and if it determines that the log contents of the log information 411 do not match the detection contents of the attack scenario element being processed, it transfers processing to S1604.

In S1606, the CPU 220 generates attack detection information 450 based on the log information 411 and the attack scenario 600 to be processed that are determined to match.

In S1607, the CPU 220 determines whether the attack stage of the attack scenario element being processed is the final attack stage (e.g., "4"). If the CPU 220 determines that the attack stage of the attack scenario element being processed is the final attack stage, it transfers processing to S1608, and if the CPU 220 determines that the attack stage of the attack scenario element being processed is not the final attack stage, it transfers processing to S1604.

In S1608, the CPU 220 generates incident information 460 based on the log information 411 and the attack scenario 600 to be processed, and moves the process to S1604. At this time, the CPU 220 sets the incident determination result of the attack detection information 450 generated in S1606 to "o".

Figure 17 shows an example of the attack countermeasure processing executed by the CPU 340 of the attack countermeasure device 130.

At S1701, the CPU 340 acquires the attack detection information 450 received from the in-vehicle security device 111.

At S1702, the CPU 340 acquires the countermeasure information 441 from the countermeasure information storage unit 540.

In S1703, the CPU 340 determines whether or not all of the attack detection information 450 acquired in S1701 has been processed. If the CPU 340 determines that all of the attack detection information 450 acquired in S1701 has been processed, the attack countermeasure processing is terminated. If the CPU 340 determines that some of the attack detection information 450 acquired in S1701 has not been processed, the CPU 340 selects one piece of attack detection information 450 that has not been processed as the processing target and proceeds to S1704.

In S1704, the CPU 340 determines whether or not all of the vulnerabilities included in the attack detection information 450 being processed have been processed. If the CPU 340 determines that all of the vulnerabilities included in the attack detection information 450 being processed have been processed, the CPU 340 proceeds to S1710. If the CPU 340 determines that some of the vulnerabilities included in the attack detection information 450 being processed have not been processed, the CPU 340 selects one vulnerability that has not been processed as the processing target and proceeds to S1705.

In S1705, the CPU 340 determines whether countermeasure information 441 that matches the vulnerability ID of the vulnerability to be processed can be extracted from the countermeasure information 441 acquired in S1702, and whether the extracted countermeasure information 441 includes a countermeasure (whether a countermeasure exists). If the CPU 340 determines that a countermeasure exists, it proceeds to S1706, and if it determines that a countermeasure does not exist, it proceeds to S1707.

In S1706, the CPU 340 stores the countermeasure information 441 extracted in S1705 in the memory unit 350, and then proceeds to S1704.

In S1707, the CPU 340 determines whether the attack on the vulnerability being processed is in the final attack stage (whether it is an incident). If the CPU 340 determines that it is an incident, it proceeds to S1708, and if it determines that it is not an incident, it proceeds to S1709.

In S1708, the CPU 340 transmits countermeasure information 441 for suspending the use of the vehicle 110 to the in-vehicle security device 111, reviews the new countermeasure information 441, and ends the attack countermeasure processing. For example, the CPU 340 performs an analysis of an unknown vulnerability based on the log information 411 and the vulnerability information storage unit 550, reviews a countermeasure for the unknown vulnerability, and generates countermeasure information 441 including a patch for correcting the unknown vulnerability and a method for mitigating the attack. The patch includes a backdate command for the software running on the device, a configuration file, update software, etc. Then, the CPU 340 updates the attack information storage unit 530, the countermeasure information storage unit 540, and the vulnerability information storage unit 550 based on the obtained review results.

In S1709, the CPU 340 tolerates the vulnerability being processed, i.e., it determines that the attack is not in the final stage of the attack and therefore will not affect assets, stores in the memory unit 350 countermeasure information 441 indicating that no countermeasures will be implemented against the attack on the vulnerability being processed, and proceeds to S1704.

In S1710, the CPU 340 transmits the countermeasure information 441 stored in the memory unit 350 to the in-vehicle security device 111, and moves the process to S1703. Note that the timing of transmitting the countermeasure information 441 to the in-vehicle security device 111 is not limited to the timing described above. For example, the CPU 340 may transmit the countermeasure information 441 to the in-vehicle security device 111 in each of S1706 and S1709, or may transmit the countermeasure information 441 to the in-vehicle security device 111 if the determination in S1703 is NO.

Figure 18 is a diagram showing an example of the log information management process executed by the CPU 220 of the in-vehicle security device 111. The log information management process is executed by the CPU 220 at a predetermined timing. The predetermined timing may be periodically, may be when the attack detection unit 224 detects an incident, or may be when the storage capacity of the storage device 210 assigned to the log information storage unit 410 exceeds a predetermined capacity.

In S1801, the CPU 220 determines whether the free space of the storage device 210 is greater than a specified value. If the CPU 220 determines that the free space of the storage device 210 is greater than the specified value, the CPU 220 ends the log information management process. If the CPU 220 determines that the free space of the storage device 210 is equal to or less than the specified value, the process proceeds to S1802.

In S1802, the CPU 220 erases the log information 411 with the lowest priority from among the log information 411 stored in the log information storage unit 410, and returns to S1801.

The above configurations, functions, etc. may be realized in hardware, in part or in whole, for example by designing them as integrated circuits. Also, the above configurations, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information on the programs, tables, files, etc. that realize each function can be recorded on a recording device such as a memory, a hard disk, or an SSD (Solid State Drive), or on a recording medium such as an IC (Integrated Circuit) card, a memory card, or a DVD.

(2) Supplementary Notes The above-described embodiment includes, for example, the following contents.

In the above embodiment, the present invention has been described as being applied to a vehicle security system, but the present invention is not limited to this and can be widely applied to a variety of other systems, devices, methods, and programs.

In the above embodiment, the in-vehicle security device 111 periodically reads out the log information 411 stored in the log information storage unit 410 and transmits it to the attack countermeasure device 130, but the present invention is not limited to this. For example, when the in-vehicle security device 111 generates the log information 411, it may set a priority for the log information 411 and transmit the log information 411 to the attack countermeasure device 130 based on the priority. Also, for example, when the in-vehicle security device 111 generates the log information 411, it may determine whether an incident has occurred, and when it determines that an incident has occurred, it may transmit the log information 411 related to the incident to the attack countermeasure device 130.

In addition, in the above embodiment, the in-vehicle security device 111 has been described as setting a priority every time log information 411 is generated (setting in real time), but the present invention is not limited to this. For example, the in-vehicle security device 111 may set a priority for the log information 411 at a timing other than real time. The other timing may be periodically, at a specified time, when the number of log information 411 for which no priority is set exceeds a threshold, or at another timing.

In addition, in the above embodiment, the in-vehicle security device 111 acquires the attack scenario 600 from the attack countermeasure device 130 at startup, but the present invention is not limited to this. The in-vehicle security device 111 may also acquire the attack scenario 600 from the attack countermeasure device 130 when the configuration of the equipment installed in the vehicle 110 is changed.

In addition, in the above embodiment, the attack countermeasure device 130 transmits the attack scenario 600 to the in-vehicle security device 111 in response to an attack scenario request, but the present invention is not limited to this. For example, the attack countermeasure device 130 may periodically acquire the vehicle configuration information 421 from the in-vehicle security device 111, read the attack scenario 600 corresponding to the vehicle configuration information 421 from the attack information storage unit 530, and transmit it to the in-vehicle security device 111.

In the above embodiment, the GW device 240 stores the log information 411 in the log information storage unit 410, but the present invention is not limited to this. For example, the in-vehicle security device 111 may store the log information 411 in the log information storage unit 410. In this case, the in-vehicle security device 111 may set a priority for the log information 411 and store the log information 411 with a priority higher than a threshold in the log information storage unit 410. In addition, for example, the in-vehicle security device 111 may store the log information 411 related to an attack in the log information storage unit 410, may store the log information 411 related to an incident in the log information storage unit 410, or may store the log information 411 related to an attack that is in an advanced attack stage in the log information storage unit 410.

In addition, in the above-described embodiment, the configuration of each table is an example, and one table may be divided into two or more tables, or all or part of two or more tables may be one table.

The above-described embodiment has, for example, the following characteristic configurations. Note that the configurations shown in the embodiments may be modified, rearranged, combined, or omitted as appropriate without departing from the gist of the present invention.

An in-vehicle security device (e.g., the in-vehicle security device 111) mounted on a vehicle (e.g., the vehicle 110) equipped with predetermined devices (e.g., at least one of a GW device 240, a device belonging to a control system network 250, a device belonging to an assist system network 260, a device belonging to an information system network 270, and a mobile router 280) includes an attack information storage unit (e.g., an attack information storage unit 430, a computer capable of communicating with the in-vehicle security device 111) that stores attack information (e.g., attack information 431, attack scenario 600) indicating attacks against the above devices, and a log management unit (e.g., log management unit 221, CPU 220, circuit, computer capable of communicating with in-vehicle security device 111) that extracts log information related to the attack information stored in the attack information storage unit from the log information stored in the log information storage unit and transmits the extracted log information to an attack countermeasure device (e.g., attack countermeasure device 130) for providing countermeasures against attacks on the device.
In the above configuration, log information related to attacks against equipment installed in the vehicle is extracted and transmitted to the attack countermeasure device, thereby reducing the load on computer resources in the vehicle required for transmitting log information, for example.

The log management unit sets a priority level for the attack in the attack information related to the log information for the device (e.g., see S1522), extracts log information related to the attack information stored in the attack information storage unit from the log information stored in the log information storage unit based on the priority level set in the log information, and transmits the extracted log information to the attack countermeasure device (e.g., see S1523).
In the above configuration, log information is extracted based on priority. For example, by extracting log information with a priority higher than a threshold, the load on the computer resources in the vehicle required to transmit the log information can be further reduced.

The log management unit sets a priority of the attack in the attack information related to the log information for the device (e.g., see S1522), and erases the log information stored in the log information storage unit based on the priority set in the log information (e.g., see S1802).
In the above configuration, log information is erased based on priority. For example, by erasing log information whose priority is lower than a threshold, the storage capacity of the storage device required to store log information can be reduced.

The attack countermeasure device stores attack information for each of a number of known attacks, and the in-vehicle security device is equipped with an attack management unit (e.g., an initial setting unit 222 and an attack management unit 223) that determines whether the configuration of the equipment has been changed from a first configuration (e.g., the configuration of vehicle 110 at the time of the previous startup, the configuration of vehicle 110 in the past) to a second configuration different from the first configuration (e.g., the configuration of vehicle 110 at the time of this startup, the current configuration of vehicle 110), and if it is determined that the configuration has been changed from the first configuration to the second configuration, acquires attack information corresponding to the second configuration from the attack countermeasure device and stores it in the attack information storage unit.
In the above configuration, when the configuration of the vehicle's equipment is changed, attack information corresponding to the changed configuration is obtained from the attack countermeasure device and stored in the attack information storage unit, so that, for example, the log management unit can extract log information according to the configuration of the vehicle's equipment.

In a vehicle security system (e.g., vehicle security system 100) including the in-vehicle security device and the attack countermeasure device, an attack detection unit (e.g., attack detection information 450) that requests the attack countermeasure device to provide countermeasure information including countermeasure content for the attack based on the in-vehicle security device detecting an attack on the device from log information about the device and attack information stored in the attack information storage unit, receives countermeasure information including countermeasure content for the device in which an attack has been detected by the attack detection unit and transmits the countermeasure information to the attack countermeasure device (e.g., attack detection information 450) that requests the attack countermeasure device to provide countermeasure information including countermeasure content for the attack based on the in-vehicle security device detecting an attack on the device from log information about the device and attack information stored in the attack information storage unit, and The attack countermeasure device comprises a countermeasure processing unit (e.g., countermeasure processing unit 225, CPU 220, circuit, computer capable of communicating with in-vehicle security device 111) that implements countermeasures against the equipment based on the countermeasure information, and the attack countermeasure device comprises a countermeasure information storage unit (e.g., countermeasure information storage unit 540, computer capable of communicating with attack countermeasure device 130) that stores countermeasure information for each of a number of known attacks, and a countermeasure management unit (e.g., countermeasure management unit 343, CPU 340, circuit, computer capable of communicating with attack countermeasure device 130) that acquires countermeasure information corresponding to the attack detected by the attack detection unit from the countermeasure information stored in the countermeasure information storage unit based on the attack detection information transmitted by the attack detection unit, and transmits the acquired countermeasure information to the countermeasure processing unit.
In the above configuration, when an attack on equipment in a vehicle is detected, countermeasure information including countermeasures against the attack is obtained from the attack countermeasure device, and countermeasures are implemented on the equipment in which the attack was detected, thereby ensuring the security of the vehicle, for example.

If countermeasure information corresponding to the attack detected by the attack detection unit is not included in the countermeasure information stored in the countermeasure information storage unit, the countermeasure management unit sends countermeasure information to stop the vehicle to the countermeasure processing unit when the attack stage of the attack is the final attack stage (e.g., see S1708), and sends countermeasure information indicating that countermeasures against the attack will not be implemented to the countermeasure processing unit when the attack stage of the attack is not the final attack stage (e.g., S1709, S1710).
In the above configuration, if there is no countermeasure information corresponding to a detected attack, the countermeasures are varied depending on whether the attack stage is the final attack stage or not, thereby ensuring the security of the vehicle while suppressing a decrease in user convenience.

It should be understood that an item listed in the format "at least one of A, B, and C" can mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). Similarly, an item listed in the format "at least one of A, B, or C" can mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

100...vehicle security system, 110...vehicle, 111...vehicle-mounted security device, 130...attack prevention device.

Claims (8)

An in-vehicle security device to be mounted on a vehicle equipped with a predetermined device,
an attack information storage unit that stores attack information indicating an attack against the device;
a log information storage unit that stores log information about the device;
a log management unit that extracts log information related to the attack information stored in the attack information storage unit from the log information stored in the log information storage unit, and transmits the extracted log information to an attack countermeasure device that provides countermeasures against attacks against the device;
An in-vehicle security device comprising: The log management unit
setting a priority level of an attack in attack information related to the log information for the device;
extracting log information related to the attack information stored in the attack information storage unit from the log information stored in the log information storage unit based on a priority set for the log information;
Transmitting the extracted log information to the attack countermeasure device.
The vehicle-mounted security device according to claim 1 . The log management unit
setting a priority level of an attack in attack information related to the log information for the device;
erasing the log information stored in the log information storage unit based on a priority set for the log information;
The vehicle security device according to claim 1 . the attack countermeasure device stores attack information for each of a plurality of known attacks;
an attack management unit that determines whether or not the configuration of the device has been changed from a first configuration to a second configuration different from the first configuration, and when it is determined that the configuration has been changed from the first configuration to the second configuration, acquires attack information corresponding to the second configuration from the attack countermeasure device and stores the attack information in the attack information storage unit;
The vehicle-mounted security device according to claim 1 . A vehicle security system including an on-board security device mounted on a vehicle equipped with a specific device, and an attack countermeasure device for providing countermeasures against attacks on the device,
The vehicle-mounted security device includes:
an attack information storage unit that stores attack information indicating an attack against the device;
a log information storage unit that stores log information about the device;
a log management unit that extracts log information related to the attack information stored in the attack information storage unit from the log information stored in the log information storage unit and transmits the extracted log information to the attack countermeasure device;
A vehicle security system comprising: The vehicle-mounted security device includes:
an attack detection unit that transmits attack detection information to the attack countermeasure device, based on detection of an attack on the device from log information about the device and the attack information stored in the attack information storage unit, for requesting countermeasure information including countermeasure content against the attack from the attack countermeasure device;
a countermeasure processing unit that receives countermeasure information transmitted from the attack countermeasure device, the countermeasure information including countermeasure details for a device on which an attack has been detected by the attack detection unit, and implements countermeasures for the device based on the received countermeasure information;
The attack countermeasure device includes:
a countermeasure information storage unit that stores countermeasure information for each of a plurality of known attacks;
a countermeasure management unit that acquires countermeasure information corresponding to the attack detected by the attack detection unit from the countermeasure information stored in the countermeasure information storage unit based on the attack detection information transmitted by the attack detection unit, and transmits the acquired countermeasure information to the countermeasure processing unit.
6. The vehicle security system of claim 5. When the countermeasure information corresponding to the attack detected by the attack detection unit is not included in the countermeasure information stored in the countermeasure information storage unit, the countermeasure management unit:
When the attack stage of the attack is the final attack stage, transmitting countermeasure information for stopping the vehicle to the countermeasure processing unit;
when the attack stage of the attack is not the final attack stage, transmitting countermeasure information indicating that a countermeasure against the attack will not be implemented to the countermeasure processing unit;
7. The vehicle-mounted security device according to claim 6. A vehicle management method executed by an in-vehicle security device mounted on a vehicle equipped with a predetermined device, comprising:
In-vehicle security devices
an attack information storage unit that stores attack information indicating an attack against the device;
a log information storage unit that stores log information about the device,
extracting log information related to the attack information stored in the attack information storage unit from the log information stored in the log information storage unit;
Transmitting the extracted log information to an attack countermeasure device for providing countermeasures against attacks against the device.
Vehicle management methods.

Images