Threat intelligence deployment system, threat intelligence deployment method, and program

Abstract

In the present invention, a monitoring server (30a) in a vehicle-mounted control network system comprises: a threat information generation unit (3003) that acquires first threat information relating to a threat that has occurred in a vehicle of a first vehicle type; a threat information abstraction unit (3005) that generates abstracted threat information in which information unique to the first vehicle type is deleted from the first threat information; and a display unit (3002) that outputs second threat information which has been generated on the basis of the abstracted threat information and includes a risk value indicating the degree of risk of the threat to a second vehicle type differing from the first vehicle type.

Description

Technical Field

[0001] The present disclosure relates to a threat information deployment system, a threat information deployment method and a program in an in-vehicle control network system. Background Art

[0002] In recent years, in systems where all kinds of devices are connected, such as those called IoT (Internet of Things) and CPS (Cyber Physical Systems), an increasing number of systems process sensing results from physical space in cyberspace and control physical space. Along with this trend, the importance of cybersecurity technology has been increasing more than ever.

[0003] In fact, there are cases where security issues in control system networks such as those of automobiles and factories lead to unauthorized control of automobiles and shutdown of factory operations, therefore security issues affect human life and business continuity.

[0004] In IT (Internet Technology) systems, threat information is utilized to quickly respond to constantly evolving attack methods.

[0005] Threat information is also called threat intelligence or Cyber Threat Intelligence (CTI), and it is a systematized body of knowledge about attacker information and specific attack methods, among other contents.

[0006] Threat information includes, for example, information such as malicious IP addresses and hash values of malware; utilization of such information makes it possible to detect signs of attacks and implement countermeasures. Since widespread use of threat information improves the security of more organizations and systems and benefits society as a whole, organizations such as Information Sharing and Analysis Centers (ISACs) exist to collect and share threat information.

[0007] In the automotive sector, Auto-ISAC has been established, and it is expected that ISACs will be established in various other industries in the future.

[0008] Incidentally, threat intelligence can be widely utilized for systems such as IT systems, which include equipment equipped with standard communication protocols and widely used operating systems. On the other hand, for systems such as automotive systems, which have communication protocols specific to the car manufacturer or model, or systems that include dedicated Electronic Control Units (ECUs), threat intelligence that is effective for a particular model may not be directly applicable to other models, making it difficult to accumulate threat intelligence for each individual model.

[0009] Furthermore, because sharing system-specific threat information can identify targeted vehicle models and manufacturers, and reveal vulnerabilities in automotive systems, it is possible that the sharing of threat information may not proceed as smoothly as intended.

[0010] In response to this situation, Patent Document 1 discloses a system for sharing threat information among multiple organizations, and specifically discloses a method for evaluating the usefulness of threat information based on its novelty and impact.

[0011] Furthermore, Patent Document 2 discloses a threat information evaluation device that assists security operators in evaluating threat information. [Prior art documents] [Patent Documents]

[0012] [Patent Document 1] Japanese Patent Publication No. 2019-191657 [Patent Document 2] Patent No. 6710716 [Overview of the Initiative] [Problems that the invention aims to solve]

[0013] However, Patent Document 1 mentioned above does not provide specific disclosure on how to determine how useful threat information is to a company's system and whether it is urgent.

[0014] Furthermore, Patent Document 2 mentioned above does not disclose any specific methods for evaluating threat information other than using machine learning on threat information patterns and security operators' evaluation values.

[0015] This disclosure provides a threat intelligence deployment system that can evaluate the usefulness of threat intelligence for a target vehicle when deploying threat intelligence to other vehicle models. [Means for solving the problem]

[0016] A threat information deployment system according to one aspect of the present disclosure is a threat information deployment system in an in-vehicle control network system, comprising: an acquisition unit that acquires first threat information relating to a threat occurring in a vehicle of a first type; a threat information abstraction unit that generates abstracted threat information by removing information specific to the first type from the first threat information; and an output unit that outputs second threat information generated based on the abstracted threat information, including a risk value indicating the degree of threat risk to a second type of vehicle different from the first type. [Effects of the Invention]

[0017] According to a threat intelligence deployment system, etc., in one aspect of this disclosure, when deploying threat intelligence to other vehicle models, it is possible to evaluate the usefulness of the threat intelligence for the target vehicle model. [Brief explanation of the drawing]

[0018] [Figure 1] Figure 1 is an overall configuration diagram of the automotive cybersecurity monitoring system in Embodiment 1. [Figure 2] Figure 2 is a diagram showing the configuration of the in-vehicle network system in Embodiment 1. [Figure 3]FIG. 3 is a configuration diagram of the in-vehicle network monitoring ECU according to the first embodiment. [Figure 4] FIG. 4 is a configuration diagram of the monitoring server according to the first embodiment. [Figure 5] FIG. 5 is a configuration diagram of the threat information sharing server according to the first embodiment. [Figure 6] FIG. 6 is a diagram showing an example of a communication log according to the first embodiment. [Figure 7] FIG. 7 is a diagram showing an example of an anomaly detection log according to the first embodiment. [Figure 8] FIG. 8 is a diagram showing an example of a vehicle communication log according to the first embodiment. [Figure 9] FIG. 9 is a diagram showing an example of an alert according to the first embodiment. [Figure 10] FIG. 10 is a diagram showing an example of threat information according to the first embodiment. [Figure 11] FIG. 11 is a diagram showing an example of vehicle-specific information according to the first embodiment. [Figure 12] FIG. 12 is a diagram showing an example of shared threat information according to the first embodiment. [Figure 13] FIG. 13 is a diagram showing a threat information sharing sequence according to the first embodiment. [Figure 14] FIG. 14 is a flowchart showing processing for abstracting threat information according to the first embodiment. [Figure 15] FIG. 15 is a flowchart showing processing for adapting threat information to a vehicle model according to the first embodiment. [Figure 16] FIG. 16 is a diagram showing an example of a vehicle model compatibility determination matrix according to the first embodiment. [Figure 17] FIG. 17 is a flowchart showing risk determination processing for threat information based on vehicle conditions according to the first embodiment. [Figure 18] FIG. 18 is a diagram showing a display example of the occurrence status of similar threats according to the first embodiment. [Figure 19]Figure 19 is a diagram showing an example of the display of the occurrence status of similar threats in Embodiment 1. [Figure 20] Figure 20 shows an example of how the vehicle suitability of threat information is displayed in Embodiment 1. [Figure 21] Figure 21 shows an example of displaying the risk value of threat information based on the vehicle status in Embodiment 1. [Modes for carrying out the invention]

[0019] A threat information deployment device according to one aspect of the present disclosure is a threat information deployment device in an in-vehicle control network system, comprising: an acquisition unit that acquires first threat information relating to a threat occurring in a vehicle of a first type; a threat information abstraction unit that generates abstracted threat information by removing information specific to the first type from the first threat information; and an output unit that outputs second threat information generated based on the abstracted threat information, including a risk value indicating the degree of threat risk to a second type of vehicle different from the first type.

[0020] This means that when threat information related to a threat occurring in the first vehicle model is deployed to a second vehicle model that is different from the first, information specific to the first vehicle model is removed, thus preventing the identification of the targeted vehicle model or manufacturer and the revelation of vulnerabilities in the automotive system. Furthermore, since the threat information for the second vehicle model includes risk values ​​for that second vehicle model, the threat information can be deployed while taking into account the degree of threat risk which may differ depending on the vehicle model. Therefore, when deploying threat information to other vehicle models, the usefulness of the threat information for the target vehicle model can be evaluated, allowing for the effective use of threat information and contributing to improved security.

[0021] For example, the threat information deployment system may further include a risk value calculation unit that calculates the risk value.

[0022] Thus, a threat intelligence deployment system may calculate the risk value.

[0023] For example, the threat information deployment system may further include a threat occurrence status retention unit and an attack deployment capability determination unit, wherein the threat occurrence status retention unit maintains the threat occurrence status for each abnormal vehicle in which a threat corresponding to the abstracted threat information has been observed, the attack deployment capability determination unit calculates the deployment capability of the threat corresponding to the abstracted threat information according to the number of vehicle types or the number of individual abnormal vehicles indicated by the occurrence status, and the risk value calculation unit calculates the risk value based on the deployment capability.

[0024] Abstracted threat information corresponds to similar threats (referred to as similar threats) that may occur in different vehicle models. Threat information regarding similar threats is almost identical except for vehicle-specific information; by removing vehicle-specific information, they can all become the same abstracted threat information. Therefore, it is possible to associate instances of similar threats with a single abstracted threat information. Furthermore, the number of vehicle models or individuals affected by similar threats can be used to assess the potential for threat deployment, providing useful information for utilizing abstracted threat information.

[0025] For example, the threat information deployment system further comprises a vehicle-specific information holding unit and a vehicle-specific suitability determination unit, wherein the vehicle-specific information holding unit holds vehicle-specific information for each vehicle type, which includes at least one of the following: information relating to an installed electronic control unit, signals received by the electronic control unit, a network through which the signals received by the electronic control unit are communicated, and configuration information of the in-vehicle network; the vehicle-specific suitability determination unit calculates the suitability of the abstracted threat information for the second vehicle type using the abstracted threat information and the vehicle-specific information relating to the second vehicle type; and the risk value calculation unit calculates the risk value based on the suitability.

[0026] Since the electronic control units affected by the threat, the signals received by the electronic control units, the networks through which those signals are communicated, and the in-vehicle network may differ for each vehicle model, it becomes possible to determine the suitability of the abstracted threat information based on vehicle-specific information unique to the second vehicle model, and thus evaluate the suitability of the abstracted threat information for the second vehicle model.

[0027] For example, the information relating to the electronic control unit includes operating conditions for processing signals received by the electronic control unit, and the vehicle suitability determination unit may calculate the suitability using the ease with which an attack on the second vehicle can be carried out, determined based on at least one of the following: whether the operating conditions for processing signals that constitute a threat corresponding to the abstracted threat information include conditions relating to signals outside the in-vehicle network in the second vehicle; whether there are a predetermined number or more of such operating conditions; and whether tampering countermeasures or access control are in place for signals received by the electronic control unit.

[0028] Since the operating conditions for electronic control devices installed in vehicles to process signals that constitute a threat can vary from vehicle to vehicle, the ease of attacking a second vehicle can be evaluated based on the complexity of these operating conditions, thereby allowing for a more accurate assessment of the suitability of the abstracted threat information for that second vehicle.

[0029] For example, the vehicle type suitability determination unit may calculate the suitability using the ease of access to the communication network, which is determined according to the number of subnetworks that the signal corresponding to the abstracted threat information is transmitted from an external connection device, which is an electronic control device installed in the second vehicle type and is connected to an external network, to the communication network in the second vehicle type.

[0030] Since the number of subnetworks traversed from the external connection device to the communication network transmitting the threat-causing signal can vary depending on the vehicle model, the suitability of the abstracted threat information for a second vehicle model can be accurately assessed by evaluating the ease with which an attacker can access the communication network necessary to compromise the signal.

[0031] For example, the output unit may output the second threat information if the compliance level is above a predetermined value.

[0032] This prevents the threat intelligence from becoming excessively large and thus reduces storage requirements by not generating secondary threat intelligence for vehicle models with low relevance to the abstracted threat intelligence.

[0033] For example, the threat information deployment system further comprises a vehicle-specific information holding unit and a vehicle log collection unit, wherein the vehicle-specific information holding unit holds information about the electronic control device, including operating conditions for processing signals received by the installed electronic control device, for each vehicle type; the vehicle log collection unit collects vehicle logs of the second vehicle type; and the risk value calculation unit calculates the risk value for the vehicle according to the degree of agreement between the operating conditions for processing signals that constitute a threat corresponding to the abstracted threat information and the state of the vehicle included in the vehicle log.

[0034] This allows for the individual assessment of threat intelligence risks for each vehicle based on its status, and enables more dynamic deployment of threat intelligence.

[0035] For example, the threat information deployment system further includes a risk response unit, which determines a response to the threat to the second vehicle type according to the risk value, and the response may be at least one of the following: matching the abnormal communication pattern indicated by the second threat information with communication logs collected from the vehicle of the second vehicle type; updating the firmware of the electronic control unit installed in the vehicle; restricting the functions of the vehicle; and notifying security analysts of an alert.

[0036] This allows for determining appropriate responses based on the risk value calculated for each vehicle, enabling priority action to be taken for vehicles with high risk values.

[0037] Furthermore, a threat information deployment method according to one aspect of the present disclosure is a method executed by a threat information deployment system in an in-vehicle control network system, and includes the process of acquiring first threat information relating to a threat occurring in a first vehicle type, generating abstracted threat information by removing information specific to the first vehicle type from the first threat information, and outputting second threat information, which includes a risk value indicating the degree of threat risk to a second vehicle type different from the first vehicle type, generated based on the abstracted threat information.

[0038] This provides a threat intelligence deployment method that allows for the evaluation of the usefulness of threat intelligence for the target vehicle when deploying it to other vehicle models.

[0039] Furthermore, a program relating to one aspect of this disclosure is a program for causing a threat intelligence deployment system to execute the above-described threat intelligence deployment method.

[0040] This allows us to provide a program that can evaluate the usefulness of threat information for the target vehicle when deploying it to other vehicle models.

[0041] The following describes a threat information deployment method according to embodiments of this disclosure, with reference to the drawings. Note that the embodiments described below are all preferred examples of this disclosure. In other words, the numerical values, shapes, materials, components, arrangement and connection configurations of components, steps, and the order of steps shown in the following embodiments are examples of this disclosure and are not intended to limit it. This disclosure is identified by the claims. Therefore, among the components in the following embodiments, those not described in the independent claims representing the highest-level concept of this disclosure are described as components that constitute a more preferred configuration, even though they are not necessarily required to achieve the objectives of this disclosure.

[0042] (Embodiment 1) The following describes a threat intelligence deployment system in an automotive cybersecurity monitoring system (also known as a vehicle control network system) that monitors the security status of multiple vehicles.

[0043] [1.1 Overall Configuration of the Automotive Cybersecurity Monitoring System] Figure 1 is an overall configuration diagram of the automotive cybersecurity system in this embodiment. The automotive cybersecurity system includes a threat information deployment system, which comprises an acquisition unit, a threat information abstraction unit, an output unit, a risk value calculation unit, a threat occurrence status retention unit, an attack deployment feasibility determination unit, a vehicle-specific information retention unit, a vehicle-specific suitability determination unit, a vehicle log collection unit, and a risk response unit. The threat information deployment system is a computer including a processor, a communication interface, a user interface, and memory. The memory is ROM (Read Only Memory) and RAM (Random Access Memory), and can store programs executed by the processor. The acquisition unit, threat information abstraction unit, risk value calculation unit, attack deployment feasibility determination unit, vehicle-specific suitability determination unit, and risk response unit are implemented by a processor that executes programs stored in memory. The threat occurrence status retention unit and the vehicle-specific information retention unit are implemented by memory, etc. Note that the memory where programs are stored, the threat occurrence status retention unit, and the vehicle-specific information retention unit may each be separate memories. The threat information deployment system may be, for example, a threat information deployment device consisting of a single enclosure. Furthermore, the threat intelligence deployment system may be a system in which its components are distributed and located across multiple devices.

[0044] As shown in Figure 1, the automotive cybersecurity monitoring system comprises a vehicle 10a, a vehicle 10b, a network 20a, a network 20b, a monitoring server 30a, a monitoring server 30b, and a threat information sharing server 40.

[0045] Vehicles 10a and 10b are vehicles that travel on the road and are operated by a driver or an automated driving system. Vehicles 10a and 10b are vehicles that differ in year, model, options, or manufacturer; in other words, they are vehicles of different types. Vehicle 10a notifies the monitoring server 30a of vehicle security anomaly alerts and vehicle logs via the network 20a. Vehicle 10a is an example of a first type of vehicle, and vehicle 10b is an example of a second type of vehicle that is different from the first type.

[0046] Network 20a is a communication network connecting vehicle 10a and monitoring server 30a, and is implemented via a dedicated line or the internet. Similarly, network 20b is a communication network connecting vehicle 10b and monitoring server 30b.

[0047] The monitoring server 30a detects security incidents involving vehicle 10a based on security anomaly alerts notified from vehicle 10a and vehicle logs.

[0048] Furthermore, the monitoring server 30a holds threat information and, based on this threat information, checks the vehicle logs to determine whether or not a threat has occurred to the vehicle. Threat information may include information registered as a result of analysis by security analysts based on vehicle security alerts and vehicle logs, or information obtained by downloading threat information (abstracted threat information, described later) registered on the threat information sharing server 40 and adapting it to the vehicle being monitored.

[0049] Furthermore, the monitoring server 30a registers abstracted threat information, obtained by removing vehicle-specific vulnerability information from newly registered threat information, to the threat information sharing server 40.

[0050] Since monitoring server 30b has the same configuration as monitoring server 30a, the description of monitoring server 30b will be omitted.

[0051] For example, monitoring server 30a (monitoring server 30b) is an example of a threat intelligence deployment system.

[0052] Note that while Figure 1 shows an example where the monitoring server 30a monitors only vehicle 10a, it may monitor many other vehicles as well. The vehicles monitored by the monitoring server 30a may be the same make and model as vehicle 10a, or they may be different make and model vehicles. The vehicles monitored may vary depending on the security vendor managing the monitoring server 30a, the manufacturer of the monitored vehicles, or the region being monitored.

[0053] The threat intelligence sharing server 40 is a shared server for sharing threat intelligence held by different organizations, such as security vendors, car manufacturers, and suppliers. For example, through the threat intelligence sharing server 40, threat intelligence regarding a threat that occurred in vehicle 10a, held by monitoring server 30a, can be shared with monitoring server 30b, which does not monitor vehicle 10a, and can be used to improve the security of vehicle 10b, which is monitored by monitoring server 30b. The threat intelligence sharing server 40 is managed by a trusted organization.

[0054] Furthermore, threat information sharing may be restricted to authenticated users or organizations only, and the threat information sharing server 40 may authenticate or authorize the monitoring servers 30a and 30b or the source of access.

[0055] [1.2 Configuration of the In-Vehicle Network System] Figure 2 is a diagram showing the configuration of the in-vehicle network system of vehicle 10a in this embodiment. Since the in-vehicle network system of vehicle 10b has the same configuration as the in-vehicle network system of vehicle 10a, the description of the in-vehicle network system of vehicle 10b will be omitted.

[0056] As shown in Figure 2, the in-vehicle network system of vehicle 10a consists of an in-vehicle network 100a and an in-vehicle network monitoring ECU 110a.

[0057] The in-vehicle network 100a is a network to which multiple electronic control units (ECUs) are connected, and may consist of multiple subnetworks.

[0058] The ECUs and subnetworks that make up the in-vehicle network 100a differ depending on the vehicle model, and the communication protocols and the meaning of the payloads included in the messages communicated over the in-vehicle network 100a also differ.

[0059] ECUs communicate with other ECUs using communication standards such as Controller Area Network (CAN), FlexRay®, Ethernet®, Local Interconnected Network (LIN), and Media Oriented Systems Transport (MOST).

[0060] The in-vehicle network monitoring ECU 110a is an ECU that monitors communication on the in-vehicle network 100a. The in-vehicle network monitoring ECU 110a acquires communication logs and detects whether or not an abnormality has occurred in the communication.

[0061] Furthermore, the in-vehicle network monitoring ECU110a communicates with the monitoring server 30a to notify of communication anomalies as security anomaly alerts and to notify of communication logs.

[0062] Furthermore, the ECU that notifies the monitoring server 30a of abnormal alerts and vehicle logs does not necessarily have to be implemented in the in-vehicle network monitoring ECU 110a; there may be a separate ECU that receives notifications from the in-vehicle network monitoring ECU 110a and communicates with the monitoring server 30a.

[0063] [1.3 Configuration of the In-Vehicle Network Monitoring ECU] Figure 3 is a configuration diagram of the in-vehicle network monitoring ECU 110a in this embodiment.

[0064] As shown in Figure 3, the in-vehicle network monitoring ECU 110a includes an in-vehicle network communication unit 1101, an anomaly detection unit 1102, a monitoring server communication unit 1103, a communication log holding unit 1104, and an anomaly detection log holding unit 1105.

[0065] The in-vehicle network communication unit 1101 is a communication interface that handles the exchange of messages flowing through the in-vehicle network.

[0066] The in-vehicle network communication unit 1101 notifies the anomaly detection unit 1102 of the received message and stores it in the communication log holding unit 1104. The in-vehicle network communication unit 1101 also sends a message to the in-vehicle network 100a in accordance with message transmission requests from the anomaly detection unit 1102 and the monitoring server communication unit 1103.

[0067] The anomaly detection unit 1102 monitors messages notified from the in-vehicle network communication unit 1101 and communication logs stored in the communication log retention unit 1104 to detect whether or not abnormal communication is occurring in the in-vehicle network 100a.

[0068] When the anomaly detection unit 1102 detects a communication anomaly, it notifies the monitoring server communication unit 1103 of a security anomaly alert and the corresponding communication log. The anomaly detection unit 1102 further stores the details of the detected anomaly in the anomaly detection log holding unit 1105. Communication anomalies include, but are not limited to, anomalies in communication volume, anomalies in payload values, anomalies in destination / source, and anomalies in message authentication.

[0069] The monitoring server communication unit 1103 is a communication interface with the monitoring server 30a. The monitoring server communication unit 1103 receives security anomaly alert notifications from the anomaly detection unit 1102 and notifies the monitoring server 30a of the anomaly detection logs stored in the anomaly detection log holding unit 1105, and also notifies the monitoring server 30a of the communication logs stored in the communication log holding unit 1104.

[0070] The communication log storage unit 1104 stores a log of messages communicated on the in-vehicle network 100a.

[0071] The anomaly detection log retention unit 1105 retains logs related to communication anomalies detected by the anomaly detection unit 1102.

[0072] [1.4 Monitoring Server Configuration] Figure 4 is a diagram showing the configuration of the monitoring server 30a in this embodiment. Since the monitoring server 30b has the same configuration as the monitoring server 30a, the description of the monitoring server 30b is omitted.

[0073] As shown in Figure 4, the monitoring server 30a includes a vehicle communication unit 3001, a display unit 3002, a threat information generation unit 3003, a threat information utilization unit 3004, a threat information abstraction unit 3005, a risk assessment unit 3006, a threat information sharing server communication unit 3007, a threat information adaptation unit 3008, a vehicle communication log storage unit 3009, an alert storage unit 3010, a threat information storage unit 3011, and a vehicle-specific information storage unit 3012.

[0074] The vehicle communication unit 3001 is a communication interface that communicates with the vehicle 10a via the network 20a. The vehicle communication unit 3001 receives security anomaly alerts and vehicle logs from the vehicle 10a. The vehicle communication unit 3001 is an example of a vehicle log collection unit. Figure 17 illustrates an example in which the vehicle communication unit 3001 provided by the monitoring server 30b collects vehicle logs from a second vehicle type 10b.

[0075] The display unit 3002 is a display interface for security analysts to view information regarding security anomaly alerts, vehicle logs, and threat information. The display unit 3002 is an example of an output unit that outputs second threat information, including a risk value indicating the degree of threat risk to a second vehicle type different from the first vehicle type, which is generated based on abstracted threat information. Figures 18, 19, 20, and 21 show examples of the display unit 3002, and further details will be described later. Note that the output unit is not limited to the display unit 3002, but may be a component that outputs the second threat information to the memory of the monitoring server 30a or to other servers.

[0076] The threat information generation unit 3003 extracts specific attack methods as threat information based on security alerts stored in the alert retention unit 3010 and stores them in the threat information retention unit 3011.

[0077] Alternatively, the threat information generation unit 3003 takes the results of the security analyst's analysis as input, generates threat information, and stores it in the threat information storage unit 3011.

[0078] The threat information generation unit 3003 is an example of an acquisition unit that acquires first threat information relating to a threat that occurred in a vehicle 10a of a first type. The first threat information is threat information specific to the first type.

[0079] The Threat Information Utilization Unit 3004 checks the vehicle communication logs stored in the Vehicle Communication Log Storage Unit 3009 to see if a threat matching the threat information stored in the Threat Information Storage Unit 3011 has occurred. If a threat has occurred, the Threat Information Utilization Unit 3004 takes action, such as notifying the vehicle that sent the vehicle communication log of an alert. The Threat Information Utilization Unit 3004 is an example of a risk response unit that determines how to respond to a threat to a second vehicle type according to the risk value. Figure 17 illustrates an example in which the Threat Information Utilization Unit 3004 of the monitoring server 30b determines how to respond to a threat to a second vehicle type.

[0080] The threat information abstraction unit 3005 generates abstract threat information by removing vehicle-specific information from vehicle-specific threat information. Specifically, the threat information abstraction unit 3005 generates abstract threat information by removing information specific to a first vehicle from first threat information.

[0081] Information that will be removed from vehicle-specific threat intelligence includes vehicle-specific identifiers included in messages, raw message information, target vehicle models, and the number of received messages—information that could identify a vehicle model. Information that will not be removed from vehicle-specific threat intelligence includes the role of the ECU being attacked, the meaning and nature of the altered signal values, the percentage increase in communication volume, and information that does not lead to the identification of a vehicle model.

[0082] Abstracted threat information corresponds to similar threats (also called similar threats) that may occur in different vehicle types. Threat information regarding similar threats is almost identical except for vehicle-specific information, and by removing vehicle-specific information, they can all become the same abstracted threat information. Furthermore, when abstracting threat information, the threat information abstraction unit 3005 determines the attack potential of the abstracted threat information based on whether the threat corresponding to the abstracted threat information occurs in multiple vehicle types or multiple vehicles, and includes the attack potential in the abstracted threat information. The threat information abstraction unit 3005 is an example of an attack potential determination unit that calculates the potential of a threat corresponding to abstracted threat information according to the number of vehicle types or individual abnormal vehicles indicated by the threat occurrence status for each abnormal vehicle in which the threat corresponding to the abstracted threat information was observed.

[0083] The threat information abstraction unit 3005 notifies the threat information sharing server communication unit 3007 of the abstracted threat information, and then notifies the threat information sharing server 40.

[0084] The threat information abstraction unit 3005 may notify the threat information retention unit 3011 of the abstracted threat information, and the threat information retention unit 3011 may retain the abstracted threat information.

[0085] The risk assessment unit 3006 determines the risk value of the threat information stored in the threat information storage unit 3011, based on the vehicle-specific information stored in the vehicle-specific information storage unit 3012 and the driving status of the monitored vehicle. The risk assessment unit 3006 notifies the threat information utilization unit 3004 of the response based on the combination of the threat information and the vehicle that is judged to have a high risk value. The risk assessment unit 3006 is an example of a risk value calculation unit that calculates a risk value indicating the degree of threat risk to a second vehicle type that is different from the first vehicle type. Figure 17 illustrates an example in which the risk assessment unit 3006 of the monitoring server 30b calculates a risk value.

[0086] The threat intelligence sharing server communication unit 3007 is a communication interface with the threat intelligence sharing server 40.

[0087] The threat information sharing server communication unit 3007 notifies the threat information sharing server 40 of the abstracted threat information stored in the threat information storage unit 3011, and also receives abstracted threat information from the threat information sharing server 40 and stores the received abstracted threat information in the threat information storage unit 3011.

[0088] The threat information adaptation unit 3008 determines whether the abstracted threat information received from the threat information sharing server 40 is suitable for the vehicle models it monitors. The suitability of the threat information is determined using vehicle-specific information stored in the vehicle-specific information holding unit 3012, based on the complexity of the operating conditions for the ECU that receives the tampered signal value included in the threat information to receive and process the signal, and the ease of access from an external network to the network that receives the signal. The threat information adaptation unit 3008 is an example of a vehicle suitability determination unit that calculates the suitability of the abstracted threat information for a second vehicle model using the abstracted threat information and vehicle-specific information relating to the second vehicle model. Figure 15 illustrates an example in which the threat information adaptation unit 3008 of the monitoring server 30b calculates the suitability of the abstracted threat information for a second vehicle model.

[0089] The vehicle communication log storage unit 3009 stores the communication logs notified from the vehicle 10a.

[0090] The alert holding unit 3010 holds alerts notified from the vehicle 10a.

[0091] The threat information storage unit 3011 stores threat information, including information about threats that have occurred in vehicles. The threat information storage unit 3011 is also an example of a threat occurrence status storage unit that stores the threat occurrence status for each abnormal vehicle in which a threat corresponding to abstracted threat information has been observed.

[0092] The vehicle-specific information storage unit 3012 stores information about the installed ECU, communication specifications, and network architecture, which differ for each vehicle model. For example, the vehicle-specific information storage unit 3012 stores vehicle-specific information for each vehicle model, which includes at least one of the following: information about the installed ECU, the signals received by the ECU, the network through which the signals received by the ECU are communicated, and configuration information of the in-vehicle network. In addition, for example, the vehicle-specific information storage unit 3012 stores information about the ECU for each vehicle model, which includes operating conditions for processing the signals received by the installed ECU.

[0093] [1.5 Configuration of the Threat Intelligence Sharing Server] Figure 5 is a diagram showing the configuration of the threat information sharing server 40 in this embodiment.

[0094] As shown in Figure 5, the threat information sharing server 40 includes a monitoring server communication unit 4001 and a shared threat information storage unit 4002.

[0095] The monitoring server communication unit 4001 is an interface for communicating abstract threat information with the monitoring server 30a or 30b. The monitoring server communication unit 4001 stores the abstract threat information received from the monitoring server 30a or 30b in the shared threat information storage unit 4002. In addition, the monitoring server communication unit 4001 returns the abstract threat information stored in the shared threat information storage unit 4002 in response to inquiries from the monitoring server 30a or 30b.

[0096] The shared threat information storage unit 4002 stores abstract threat information notified from the monitoring server 30a or 30b.

[0097] [1.6 Example of a communication log] Figure 6 shows an example of a communication log in this embodiment. The communication log is stored in the communication log storage unit 1104. In Figure 6, as an example of a communication log observed in the in-vehicle network and stored in the communication log storage unit 1104, the reception time, ID, and payload are shown for each message.

[0098] The first line of the message indicates that the reception time was 10000 (ms), the ID is 0x100, and the payload is "0x1122334455667788".

[0099] The second line of the message indicates that the reception time was 10001 (ms), the ID is 0x200, and the payload is "0x00000000".

[0100] The third line of the message indicates that the reception time was 10004 (ms), the ID is 0x300, and the payload is "0x00FF00FF332211".

[0101] The fourth line of the message indicates that the reception time was 10007 (ms), the ID is 0x500, and the payload is "0x1234".

[0102] [1.7 Example of anomaly detection log] Figure 7 shows an example of an anomaly detection log in this embodiment. The anomaly detection log is stored in the anomaly detection log storage unit 1105 as a result of detection by the anomaly detection unit 1102. In Figure 7, an example of an anomaly detection log stored in the anomaly detection log storage unit 1105 is shown, including the anomaly ID, detection time, message payload value, and anomaly detection details.

[0103] The first line of the anomaly detection log shows that the anomaly ID is 0x200, the detection time is 10012, the payload is 0xFFFFFFFF, and the detected anomaly is an abnormal communication volume and an abnormal payload value.

[0104] The second line of the anomaly detection log shows that the anomaly ID is 0x200, the detection time is 10022, the payload is 0xFFFFFFFF, and the detected anomaly is an abnormal communication volume and an abnormal payload value.

[0105] The anomaly detection log on the third line indicates that the anomaly ID is 0x200, the detection time is 10032, the payload is 0xFFFFFFFF, and the detected anomaly is an abnormal communication volume and an abnormal payload value.

[0106] [1.8 Example of a vehicle communication log] Figure 8 shows an example of a vehicle communication log in this embodiment. The vehicle communication log is stored in the vehicle communication log storage unit 3009. Figure 8 shows an example of a vehicle communication log stored in the vehicle communication log storage unit 3009, showing the notified communication log for each monitored vehicle.

[0107] In the example shown in Figure 8, the monitored vehicle 10a has information similar to the communication log shown in Figure 6 stored within it.

[0108] [1.9 Example of an alert] Figure 9 shows an example of an alert in this embodiment. The alert is stored in the alert storage unit 3010. In Figure 9, as an example of an alert stored in the alert storage unit 3010, the alert content, message ID, message reception time, and message payload for each monitored vehicle are shown.

[0109] In the example shown in Figure 9, the monitored vehicle 10a is shown to have the same information stored as the anomaly detection log shown in Figure 7.

[0110] [1.10 Example of Threat Intelligence] Figure 10 shows an example of threat information in this embodiment. The threat information is stored in the threat information storage unit 3011. Figure 10 shows the threat information ID and the content of the threat information for each threat information as an example of the threat information held by the threat information storage unit 3011. Specifically, Figure 10 shows the first threat information relating to a threat that occurred in a vehicle of type A, which is the first type of vehicle.

[0111] The threat intelligence with ID TID-001 (the first threat intelligence) indicates that the target vehicle is vehicle A, the impact of the threat is unauthorized brake control, the compromised signal name is emergency brake request signal, the compromised message ID is 0x200, the compromised signal value is 0x3 (emergency brake ON request), the increase in the volume of compromised messages is 50%, the number of times the threat was observed per vehicle is 100 times for vehicle A001 of vehicle A, and 20 times for vehicle A008 of vehicle A, indicating that the attack deployment potential is moderate.

[0112] It should be noted that the information included in threat intelligence is not limited to this. For example, it may include communication capture logs containing abnormal communication patterns, and rules for detecting abnormal communication patterns. Furthermore, the information included in threat intelligence does not need to include all the information shown in Figure 10.

[0113] [1.11 Example of vehicle-specific information] Figure 11 shows an example of vehicle-specific information in this embodiment. The vehicle-specific information is stored in the vehicle-specific information storage unit 3012. Figure 11 shows an example of vehicle-specific information stored in the vehicle-specific information storage unit 3012, illustrating the types of unique information and their values ​​for each vehicle.

[0114] Regarding the relationship between the signals and the transmitting / receiving ECUs for vehicle type A, it indicates that the ECU receiving the emergency brake request signal is brake ECU_A.

[0115] The signal processing conditions for the ECU of vehicle type A indicate that the vehicle speed must be less than 40 km / h to process the emergency brake request signal.

[0116] Regarding the signal communication network for vehicle type A, it indicates that the emergency brake request signal is communicated via the chassis network, and the speed signal is communicated via both the chassis network and the powertrain network.

[0117] Regarding the network configuration for vehicle model A, it indicates that the chassis network and the adjacent network are powertrain networks.

[0118] Regarding the relationship between the signals and the transmitting / receiving ECUs for vehicle type C, it indicates that the ECU that receives the emergency brake request signal is brake ECU_C.

[0119] The signal processing conditions for the ECU of vehicle model C indicate that there are no specific conditions for processing the emergency brake request signal.

[0120] Regarding the signal communication network of the ECU in vehicle model C, it indicates that the emergency brake request signal is communicated via the ADAS network.

[0121] Regarding the network configuration for vehicle type C, it is indicated that the chassis network and the adjacent network are ADAS networks.

[0122] [1.12 An example of shared threat intelligence] Figure 12 shows an example of shared threat information in this embodiment. Shared threat information is abstract threat information stored in the shared threat information storage unit 4002. In the example in Figure 12, the contents of the abstract threat information for each threat information ID are shown as an example of shared threat information held by the shared threat information storage unit 4002.

[0123] The abstracted threat information with threat information ID TID-001 indicates that the control affected by the threat is unauthorized brake control, the compromised signal name is emergency brake request signal, the signal value is emergency brake ON, the increase in compromised messages is 50%, and the attack potential is moderate. This is information obtained by abstracting the threat information shown in Figure 10, and it can be seen that some vehicle-specific information (e.g., target vehicle model, compromised message ID, specific signal value, number of observations per vehicle) has been removed.

[0124] [1.13 Threat Intelligence Sharing Sequence] Figure 13 shows the communication sequence of the automotive cybersecurity monitoring system when threat information is shared and deployed between monitoring server 30a and monitoring server 30b in this embodiment.

[0125] Vehicle 10a notifies the monitoring server 30a of an anomaly detection alert indicating that an abnormality has occurred in the vehicle (step S100).

[0126] The monitoring server 30a generates threat information based on the analysis of the anomaly detection alerts received from the vehicle 10a (step S101).

[0127] The monitoring server 30a abstracts the threat information by excluding vehicle-specific information from the generated threat information, and shares the abstracted threat information with the threat information sharing server 40 (step S102).

[0128] The threat information sharing server 40 holds the abstracted threat information shared from the monitoring server 30a and shares it with the monitoring server 30b (step S103).

[0129] The monitoring server 30b determines whether the abstract threat information shared from the threat information sharing server 40 is relevant to the vehicle it monitors, and if so, it adapts the abstract threat information to each vehicle it monitors and stores it (step S104).

[0130] Vehicle 10b notifies the monitoring server 30b of the vehicle's communication log (step S105).

[0131] The monitoring server 30b checks the vehicle logs for signs of threats in vehicle 10b using threat information that it holds, including threat information adapted from abstracted threat information. Specifically, the monitoring server 30b evaluates the risk value for vehicle 10b based on the threat information, using the vehicle status of vehicle 10b extracted from the vehicle logs and the attack content included in the threat information (step S106).

[0132] Based on the assessed risk value, the monitoring server 30b determines whether to take risk mitigation measures for vehicle 10b, and whether to perform threat information matching with vehicle logs (step S107).

[0133] [1.14 Threat Intelligence Abstraction Flowchart] Figure 14 is a flowchart showing the process of abstracting threat information from the monitoring server 30a in this embodiment.

[0134] The monitoring server 30a collects alerts from the vehicle 10a that is being monitored (step S200).

[0135] The monitoring server 30a analyzes the alert and determines whether or not there are signs of an attack (step S201). If there are signs of an attack (Yes), the monitoring server 30a executes the process in step S202; if there are no signs of an attack (No), it returns to the process in step S200.

[0136] The monitoring server 30a generates threat information based on the alerts it has collected regarding signs of an attack (step S202).

[0137] The monitoring server 30a generates abstract threat information by excluding vehicle-specific information from the generated threat information (step S203).

[0138] The monitoring server 30a determines whether it already possesses abstract threat information generated from threat information of other vehicle types that matches the abstract threat information it has generated (step S204). The monitoring server 30a determines that the generated abstract threat information matches the abstract threat information it already possesses if the data in the generated abstract threat information is an exact match with the abstract threat information it already possesses, or if the predetermined data in the generated abstract threat information is a partial match with the abstract threat information it already possesses (for example, the impact, compromised signal name, and signal value match). If the monitoring server 30a already possesses the same abstract threat information (Yes), it executes the process in step S205; if it does not possess the same abstract threat information (No), it executes the process in step S206.

[0139] If the monitoring server 30a already possesses the same abstracted threat information, it discards the generated abstracted threat information and uses the abstracted threat information it already possesses (step S205).

[0140] The monitoring server 30a updates the number of occurrences of the threat corresponding to the abstracted threat information for the vehicle models that are notifying alerts related to the abstracted threat information (step S206). For example, if the abstracted threat information corresponds to similar threats to vehicle models A, B, and C, and it is determined that there are signs of an attack on a vehicle of model A, the number of occurrences of the threat to vehicle model A is increased by 1.

[0141] The monitoring server 30a checks whether the threat corresponding to the abstracted threat information has occurred in a predetermined number of vehicle types or more (step S207). The predetermined number of vehicle types is not particularly limited and can be set as appropriate. If the threat has occurred in a predetermined number of vehicle types or more (Yes), the monitoring server 30a executes the process in step S208, and if the threat has not occurred in a predetermined number of vehicle types or more (No), it executes the process in step S209.

[0142] If the threat occurs in more than a predetermined number of vehicle types, the monitoring server 30a sets the threat scalability (also called attack scalability) corresponding to the abstracted threat information to "High" (step S208). For example, if the threat occurs in two or more vehicle types, the monitoring server 30a sets the attack scalability of the abstracted threat information to "High".

[0143] If the threat has not occurred in more than a predetermined number of vehicle types, the monitoring server 30a checks whether the threat has occurred in more than a predetermined number of different vehicles within the same vehicle type (step S209). The predetermined number is not particularly limited and can be set as appropriate. If the threat has occurred in more than a predetermined number of different vehicles within the same vehicle type (Yes), the monitoring server 30a executes the process in step S210. If the threat has not occurred in more than a predetermined number of different vehicles within the same vehicle type (No), the monitoring server 30a executes the process in step S211.

[0144] If a threat occurs in a predetermined number of different vehicles within the same vehicle type, the monitoring server 30a sets the attack deployment capability of the abstracted threat information to "medium" (step S210).

[0145] If no threats have occurred in a predetermined number of different vehicles within the same vehicle type, the monitoring server 30a sets the attack deployment capability of the abstracted threat information to "low" (step S211).

[0146] Furthermore, steps S207 and S209 do not necessarily have to be performed; either one may be performed, and the attack deployment level may be set to two stages (for example, "large" and "small").

[0147] In this manner, the monitoring server 30a (threat information abstraction unit 3005) calculates the deployment potential of the threat corresponding to the abstracted threat information, according to the number of vehicle types or individual abnormal vehicles indicated by the threat occurrence status for each abnormal vehicle in which the threat corresponding to the abstracted threat information was observed. The calculated attack deployment potential is used to calculate the vehicle type suitability of the abstracted threat information to the second vehicle type, and consequently, the risk value included in the threat information adapted to the second vehicle type (second threat information).

[0148] The monitoring server 30a notifies the threat information sharing server 40 of the abstracted threat information with configured attack deployment capabilities and shares it (step S212).

[0149] In this embodiment, an example was shown in which the monitoring server 30a performs tasks from alert collection to threat information generation. However, the judgment of attacks based on alerts and the generation of threat information do not necessarily have to be performed by the monitoring server 30a. For example, the results of an analysis by a security analyst based on alerts collected by the monitoring server 30a may be registered as threat information in the monitoring server 30a.

[0150] Furthermore, while an example was shown where the attack deployment capabilities of the abstracted threat information are configured before notifying the threat information sharing server 40 of the abstracted threat information, it is not necessary to notify the abstracted threat information at this time. For example, the abstracted threat information may be shared in response to a request from the threat information sharing server 40, or the abstracted threat information differing from the previously shared abstracted threat information may be shared in a batch at regular intervals.

[0151] [1.15 Threat Intelligence Vehicle Adaptation Flowchart] Figure 15 is a flowchart of the process in this embodiment for adapting the shared abstract threat information of the monitoring server 30b to the vehicles it is monitoring.

[0152] The monitoring server 30b obtains abstracted threat information from the threat intelligence sharing server 40 (step S300).

[0153] The monitoring server 30b acquires information on anomalous signals that indicate an attack, which are included in the abstracted threat intelligence (step S301). An anomalous signal that indicates an attack is, for example, an emergency brake request signal, as shown in Figure 12.

[0154] The monitoring server 30b refers to the vehicle type-specific information of the vehicle 10b it is monitoring and identifies the ECU that receives the abnormal signal (step S302). For example, as shown in Figure 11, if the vehicle type of vehicle 10b is vehicle type C, it can be identified that the ECU that receives the emergency brake request signal is brake ECU_C.

[0155] The monitoring server 30b refers to vehicle-specific information and extracts the operating conditions for the ECU when it processes an abnormal signal for the identified ECU (step S303). The processing conditions for an abnormal signal are values ​​(conditions) corresponding to the signal, which are included in the signal processing conditions of the ECU stored in the vehicle-specific information holding unit 3012 (for example, speed less than 40 km / h). If there is no value corresponding to the signal, there are no specific operating conditions. For example, as shown in Figure 11, if the vehicle type of vehicle 10b is vehicle type C, there are no conditions for brake ECU_C to process an emergency brake request signal.

[0156] The monitoring server 30b determines whether the extracted operating conditions (conditions for processing abnormal signals) include conditions other than those related to signals received by the ECU from the in-vehicle network (step S304). Specifically, the monitoring server 30b determines whether conditions related to information obtained by the identified ECU from sources other than messages received from the in-vehicle network are included in the conditions for processing abnormal signals. For example, if conditions related to information directly sensed by the ECU without going through the in-vehicle network are included in the conditions for processing abnormal signals, the monitoring server 30b determines that conditions other than those related to signals received by the ECU from the in-vehicle network are included. For example, if the extracted operating conditions include conditions related to information from a speed sensor or LiDAR, the answer in step S304 is Yes.

[0157] If the extracted operating conditions include conditions other than those related to signals received by the ECU from the in-vehicle network (Yes), the monitoring server 30b executes the process in step S305. If the extracted operating conditions do not include conditions other than those related to signals received by the ECU from the in-vehicle network (No), the monitoring server 30b executes the process in step S306.

[0158] If the extracted operating conditions include conditions other than those related to signals received by the ECU from the in-vehicle network, the monitoring server 30b sets the ease of attacking the second vehicle (also called ease of attack) to "low" (step S305). An ease of attack of "low" indicates that it is difficult for an attacker accessing the in-vehicle network to control the conditions necessary to generate a threat.

[0159] If the extracted operating conditions do not include any conditions other than those related to signals received by the ECU from the in-vehicle network, the monitoring server 30b determines whether the number of operating conditions for processing abnormal signals is greater than or equal to a predetermined number (step S306). The predetermined number is not particularly limited and is set as appropriate. If the number of operating conditions for processing abnormal signals is greater than or equal to the predetermined number (Yes), the monitoring server 30b executes the process in step S307, and if the number of operating conditions for processing abnormal signals is not greater than or equal to the predetermined number (No), it executes the process in step S308.

[0160] If the number of operating conditions for processing abnormal signals is greater than or equal to a predetermined number, the monitoring server 30b sets the ease of attack to "medium" (step S307). An ease of attack of "medium" indicates that an attacker with access to the in-vehicle network can control the conditions for generating a threat, but it is necessary to control multiple conditions.

[0161] If the number of operating conditions for processing abnormal signals is not equal to or greater than a predetermined number, the monitoring server 30b sets the ease of attack to "high" (step S308). An ease of attack of "high" indicates that it is relatively easy for an attacker with access to the in-vehicle network to fulfill the operating conditions necessary to generate a threat.

[0162] Furthermore, if the monitoring server 30b has measures in place to prevent tampering with the signals received by the ECU or to control access, it may be configured in a way that reduces the ease with which an attack can be successfully carried out.

[0163] The monitoring server 30b refers to vehicle-specific information and extracts the networks through which abnormal signals included in the abstracted threat information and signals related to the operating conditions extracted in step S303 communicate (step S309). If the signal related to the operating conditions is, for example, speed, it extracts the network corresponding to the speed signal indicated by the signal communication network stored in the vehicle-specific information holding unit 3012 (for example, the chassis network and the powertrain network, as shown in Figure 11). If there are multiple signals related to the operating conditions, the communication networks are extracted similarly for all signals.

[0164] The monitoring server 30b calculates for each extracted network how many subnetworks it passes through from the external communication device installed in the vehicle 10b, and determines whether there is a network that passes through a predetermined number of subnetworks or more (step S310). The predetermined number is not particularly limited and is set as appropriate. If there is a network that passes through a predetermined number of subnetworks or more (Yes), the monitoring server 30b executes the process in step S311, and if there is no network that passes through a predetermined number of subnetworks or more (No), it executes the process in step S312.

[0165] If the monitoring server 30b finds a network with a predetermined number of subnetworks to pass through, it sets the ease of access to that network (also called network access ease) to "low" (step S311). A network access ease of "low" indicates that it is difficult for an attacker outside the vehicle to access the target network in order to inject abnormal signals.

[0166] If there are no networks that pass through a predetermined number of subnetworks or more, the monitoring server 30b determines whether the number of different networks is predetermined or greater for the target network extracted in step S309 (step S312). The predetermined number is not particularly limited and can be set as appropriate. If the number of different networks is predetermined or greater (Yes), the monitoring server 30b executes the process in step S313, and if the number of different networks is not predetermined or greater (No), it executes the process in step S314.

[0167] If the number of different networks exceeds a predetermined number, the monitoring server 30b sets the network accessibility to "medium" (step S313). A network accessibility of "medium" indicates that it is relatively easy for an attacker to access the target network from outside the vehicle, but it requires access to multiple networks.

[0168] The monitoring server 30b sets the network accessibility to "high" if the number of different networks is less than a predetermined number (step S314). Network accessibility to "high" indicates that it is easy for an attacker outside the vehicle to access the target network, and that the number of such attacks is not large.

[0169] The monitoring server 30b determines the suitability of the abstract threat information to the monitored vehicle based on the configured ease of attack success, ease of network access, and attack deployment capabilities included in the abstract threat information (step S315).

[0170] Figure 16 shows an example of a vehicle compatibility judgment matrix in this embodiment. The monitoring server 30b determines the compatibility of the abstracted threat information with the monitored vehicle based on the vehicle compatibility judgment matrix shown in Figure 16. For example, if the attack deployment potential is medium, the ease of attack success is medium, and the ease of access to the target network is medium, the vehicle compatibility is determined to be "medium" from the vehicle compatibility judgment matrix shown in Figure 16.

[0171] In this manner, the monitoring server 30b (threat information adaptation unit 3008) uses the abstracted threat information and vehicle-specific information relating to the second vehicle type to calculate the suitability of the abstracted threat information for the second vehicle type.

[0172] For example, the monitoring server 30b (threat information adaptation unit 3008) calculates suitability using the ease of an attack on the second vehicle type, which is determined based on at least one of the following: whether the operating conditions for processing the signals that caused the threat corresponding to the abstracted threat information include conditions relating to signals outside the in-vehicle network in the second vehicle type vehicle 10b, whether there are a predetermined number or more of such operating conditions, and whether tampering countermeasures or access control are in place for the signals received by the vehicle 10b's ECU.

[0173] Furthermore, for example, the monitoring server 30b (threat information adaptation unit 3008) calculates suitability using the ease of access to the communication network, which is determined according to the number of subnetworks that the signal corresponding to the abstracted threat information is transmitted from the external connection device, which is one of the ECUs installed in the second vehicle type 10b and is connected to an external network, to the communication network in the second vehicle type 10b.

[0174] The monitoring server 30b determines whether the vehicle compatibility is above a predetermined value (step S316). The predetermined value is not particularly limited, but for example, it may be "medium". If the vehicle compatibility is above the predetermined value (Yes), the monitoring server 30b executes the process in step S317. If the vehicle compatibility is not above the predetermined value (No), the monitoring server 30b does not adapt the abstracted threat information to the monitored vehicle 10b and terminates the process.

[0175] If the vehicle suitability of the monitoring server 30b is above a predetermined value, it generates threat information adapted to the vehicle from the abstract threat information using vehicle-specific information of the monitored vehicle. For example, by adding information that allows for the detection of specific abnormal communications in the monitored vehicle, such as assigning the ID of the message containing the signal or assigning an abnormal payload value to the signals included in the abstract threat information, the abstract threat information can be adapted to the monitored vehicle.

[0176] In this embodiment, the monitoring server 30b determined vehicle compatibility from the vehicle compatibility matrix shown in Figure 16, based on the ease of attack execution, the ease of network access, and the ease of attack deployment. However, it is not necessary to determine vehicle compatibility based on all of this information. For example, the monitoring server 30b may determine vehicle compatibility based on any of the information, or it may determine vehicle compatibility using any combination of the information.

[0177] [1.16 Risk Assessment Flowchart for Threat Information Based on Vehicle Status] Figure 17 is a flowchart of the risk assessment process for threat information based on vehicle status in the monitoring server 30b.

[0178] The monitoring server 30b acquires the vehicle's communication logs from the vehicle 10b (step S400).

[0179] The monitoring server 30b determines whether or not threat information corresponding to vehicle 10b exists among the threat information it holds (step S401). The threat information held by the monitoring server 30b includes threat information adapted from abstract threat information to the vehicle type monitored by the monitoring server 30b. If no threat information corresponding to vehicle 10b exists (No), the monitoring server 30b returns to the process in step S400. If threat information corresponding to vehicle 10b exists (Yes), the monitoring server 30b executes the process in step S402.

[0180] The monitoring server 30b refers to the vehicle type-specific information of the vehicle 10b and extracts the operating conditions for processing abnormal signals with respect to the ECU that processes abnormal signals included in the threat information (step S402).

[0181] The monitoring server 30b determines whether the vehicle status included in the vehicle 10b's communication log matches the operating conditions extracted in step S402 (step S403). If the operating conditions match (Yes), the monitoring server 30b executes the process in step S404; otherwise, it executes the process in step S405. The vehicle status is determined by the ECU's operating conditions. For example, if the ECU's operating conditions are only speed, the vehicle status will be speed. If there are multiple operating conditions, the vehicle status is determined by the combination of signals related to the multiple operating conditions. For example, if the vehicle status is speed, it is determined whether the speed signal included in the vehicle 10b's communication log (the latest value if there are multiple) matches the operating conditions (for example, whether the speed is less than 40 km / h). If there are multiple conditions, it is determined whether all signal conditions are met. If there are no multiple operating conditions, step S405 may not be performed, and consequently, either step S406 or step S413 may not be performed.

[0182] If the vehicle status included in the vehicle log matches the operating conditions extracted in step S402, the monitoring server 30b sets the risk value to "High" for the threat information corresponding to the monitored vehicle 10b (step S404). A risk value of "High" indicates that there is a high risk of the threat indicated by the threat information occurring in vehicle 10b.

[0183] If the vehicle status included in the vehicle log does not match the operating conditions extracted in step S402, the monitoring server 30b determines whether the vehicle status partially matches the operating conditions (step S405). Partially matching the operating conditions means that the vehicle status matches some of the multiple operating conditions. If the vehicle status partially matches the operating conditions (Yes), the monitoring server 30b executes the process in step S406. If the vehicle status does not partially match the operating conditions (No), the monitoring server 30b executes the process in step S413.

[0184] If the monitoring server 30b partially matches the operating conditions extracted in step S402, it sets the risk value for the monitored vehicle 10b to "medium" (step S406). A risk value of "medium" indicates that the threat included in the threat information is not in a situation where it will occur immediately.

[0185] If the monitoring server 30b finds that the status of the monitored vehicle does not even partially match the operating conditions extracted in step S402, it sets the risk value for the monitored vehicle 10b to "low" (step S413). A risk value of "low" indicates that the likelihood of the threats included in the threat information occurring is low.

[0186] The monitoring server 30b does not apply threat information with a risk value of "low" to the monitored vehicle 10b at this time (step S414).

[0187] In this manner, the monitoring server 30b (risk assessment unit 3006) calculates a risk value for vehicle 10b based on the degree of agreement between the operating conditions for processing the signals that constituted the threat corresponding to the abstracted threat information and the state of vehicle 10b contained in the vehicle log.

[0188] Furthermore, since the monitoring server 30b (risk assessment unit 3006) calculates risk values ​​based on threat information that is suitable for the vehicle type of the vehicle it monitors (threat information with high vehicle type suitability), it can be said that the monitoring server 30b (risk assessment unit 3006) calculates risk values ​​based on vehicle type suitability. In addition, since vehicle type suitability is calculated based on attack deployment potential, it can be said that the monitoring server 30b (risk assessment unit 3006) calculates risk values ​​based on attack deployment potential.

[0189] Threat information with risk values ​​set in this manner is an example of second threat information that includes a risk value indicating the degree of threat risk to the vehicle type (second vehicle type) of vehicle 10b.

[0190] If the risk value for the monitored vehicle 10b is "high" or "medium", the monitoring server 30b performs a matching process on the vehicle communication log with abnormal signals included in the threat information (step S407). Through this process, the monitoring server 30b determines whether or not a threat has occurred to the monitored vehicle 10b.

[0191] The monitoring server 30b determines whether or not a threat has been detected based on the results of the threat information matching (step S408). If a threat is detected (Yes), the monitoring server 30b executes the process in step S409; if no threat is detected (No), it executes the process in step S411.

[0192] If the monitoring server 30b detects a threat, it determines that an attack has occurred on the monitored vehicle 10b and takes incident response action (step S409). Incident response may be carried out by automated actions such as notifying the monitored vehicle 10b of a security alert and transitioning the vehicle 10b to a degraded mode that limits its functionality, or by notifying a security analyst of the detected threat and prompting them to take action.

[0193] If no threat is detected, the monitoring server 30b determines whether the risk value for the monitored vehicle 10b is "high" (step S411). If the risk value is "high", it executes step S412; otherwise, it terminates the process.

[0194] If the monitoring server 30b determines that the risk value for the monitored vehicle 10b is "high," it considers the vehicle 10b to be at high risk and takes risk mitigation measures (step S412), even if no threat has occurred to the vehicle 10b. Risk mitigation measures may be carried out by automated actions such as notifying the monitored vehicle 10b to disable vehicle control functions related to the threat, notifying the ECU to disable abnormal signals, notifying the driver that there is a high risk of attack, or reducing the risk value by updating the ECU's firmware. Alternatively, it may be carried out by notifying a security analyst that the risk is high and prompting them to take risk mitigation measures.

[0195] In this way, the monitoring server 30b (threat information utilization unit 3004) determines a response to the threat to the second vehicle type according to the risk value. For example, this response may be at least one of the following: matching the abnormal communication pattern indicated by the second threat information with the communication logs collected from the second vehicle type vehicle 10b, updating the firmware of the ECU installed in vehicle 10b, restricting the functions of vehicle 10b, and notifying security analysts of an alert.

[0196] In this embodiment, an example was described in which the risk value is determined based on the degree of matching between the operating conditions related to the ECU processing of abnormal signals included in the threat information and the vehicle status included in the vehicle communication log. However, the vehicle status does not have to be extracted from the vehicle communication log. For example, the risk value may be determined based on the vehicle status directly notified from vehicle 10b.

[0197] Furthermore, in this embodiment, an example was described in which the risk value is determined based on the degree of matching between the operating conditions related to the ECU processing of abnormal signals included in the threat information and the vehicle status included in the vehicle communication log. However, the information used to determine the risk value is not limited to these. For example, the impact level included in the threat information may be used to determine the risk value. For example, if the content relates to unauthorized control of the vehicle, the impact level may be set to "high," if the content relates to the stopping or interference of vehicle functions, the impact level may be set to "medium," and if it is anything else, the impact level may be set to "low," and the risk value may be determined comprehensively using such impact levels as well. In addition, the risk value may be determined comprehensively using attack deployment potential and vehicle type compatibility.

[0198] Furthermore, in this embodiment, an example was shown where threat information with a risk value of "low" was not applied to the monitored vehicle 10b, but the risk values ​​to which threat information is not applied are not limited to this. For example, depending on the server resources, threat information with a risk value of "medium" may not be applied.

[0199] Furthermore, in this embodiment, an example was described in which threat information relating to a threat occurring in a first vehicle type 10a monitored by monitoring server 30a is deployed to a second vehicle type 10b monitored by monitoring server 30b, but this is not limited to this. For example, one monitoring server may monitor both a first vehicle type and a second vehicle type, and threat information relating to a threat occurring in the first vehicle type monitored by that monitoring server may be deployed to the second vehicle type monitored by that monitoring server. In this case, one monitoring server may perform the generation of abstracted threat information, the adaptation of the abstracted threat information to the second vehicle type, and the evaluation of risk values.

[0200] [1.17 Example of displaying the occurrence status of similar threats 1] Figure 18 shows an example of how the display unit 3002 of the monitoring server 30a or 30b displays the occurrence status of similar threats corresponding to abstracted threat information. This display is shown for the purpose of allowing administrators or security analysts of the monitoring server 30a or 30b to check the derivative relationships of the abstracted threat information and the occurrence status by vehicle type.

[0201] On the left side of Figure 18, in addition to the content of the threat information, the number of observed threat occurrences is displayed as a time-series bar graph for the selected abstract threat information ID. On the right side of Figure 18, threats that occurred in different vehicle models corresponding to the selected abstract threat information are also shown as similar threats if they match the threat information on the left side. In the example in Figure 18, for abstract threat information TID-001, 2300 similar threats occurred in vehicle model A, and attacks were deployed against 400 vehicles of vehicle model A. In vehicle model B, 500 similar threats occurred, and attacks were deployed against 80 vehicles of vehicle model B. In vehicle model C, 10 similar threats occurred, and attacks were deployed against 3 vehicles of vehicle model C. In vehicle model D, no similar threats occurred.

[0202] [1.18 Example of displaying the occurrence status of similar threats 2] Figure 19 shows an example of how the display unit 3002 of the monitoring server 30a or 30b displays the occurrence status of similar threats corresponding to abstracted threat information. This display is shown for the purpose of allowing administrators or security analysts of the monitoring server 30a or 30b to check the derivative relationships of the abstracted threat information and the occurrence status by vehicle type.

[0203] In Figure 19, abstract threat information is placed as TID-001, displaying the total number of similar threat occurrences (2810) and the number of affected vehicle types (3). Additionally, TID-001_A is a threat information derived from TID-001 that is compatible with vehicle type A, displaying the number of occurrences (2300) and the number of affected vehicles (400) for vehicle type A. Furthermore, the vehicle ID (1XXXXXXXXXX) of the vehicle where the threat information TID-001_A occurred is also displayed. Similarly, TID-001_B is a threat information compatible with vehicle type B, displaying the number of occurrences (500) and the number of affected vehicles (80) for vehicle type B. Furthermore, the vehicle ID (1YYYYYYYYYY) of the vehicle where the threat information TID-001_B occurred is also displayed. Furthermore, the threat information corresponding to vehicle type C is TID-001_C, and the number of incidents (10) and the number of affected vehicles (3) for vehicle type C are displayed. In addition, the vehicle ID (1ZZZZZZZZZZ) of the vehicle on which the threat information TID-001_C occurred is also displayed.

[0204] [1.19 Example of display for vehicle compatibility assessment of threat information] Figure 20 shows an example of the display of vehicle type suitability judgment for threat information on the display unit 3002 of the monitoring server 30a. This display is shown, for example, after vehicle type suitability processing has been performed on abstracted threat information, for the purpose of allowing a security analyst to confirm the basis for vehicle type suitability.

[0205] The upper left of Figure 20 displays the results of the assessment of the suitability of vehicle type B to the abstracted threat information. The results show the abstracted threat information (threat information with vehicle-specific information removed) and the vehicle-specific information of vehicle type B. The ECU that receives the park assist signal is steering ECU_B, and the operating condition for park assist signal processing is a speed of less than 10 km / h, which indicates that the ease of fulfilling the attack conditions was determined to be medium. The network through which the park assist signal is communicated is the chassis network, which indicates that the ease of access to the target network was determined to be low. The overall assessment result indicates that the suitability for vehicle type B was determined to be low, and therefore the threat information will not be applied.

[0206] In the upper right of Figure 20, details of the abstracted threat information are displayed. Abstracted threat information TID-001 indicates that the impact of the threat is unauthorized control of the steering wheel, the abnormal signal is the park assist signal, the abnormal signal value was observed to be between -500 and 500 degrees, and an abnormal increase in traffic volume of 50 to 100% was observed, and the attack deployment potential was determined to be moderate. Abstracted threat information TID-001 also indicates that the threat was first observed on September 1, 2022, and the most recent occurrence was on October 1, 2022.

[0207] Below Figure 20, the in-vehicle network configuration for vehicle type B is shown, illustrating the path (subnetwork) from the diagnostic port, which is an external connection device, and TCU_B to the chassis network. For example, it is shown that access to the chassis network connected to the steering ECU_B, which receives abnormal signals, and the park ECU_B, which is the legitimate source ECU of the abnormal signals, is difficult.

[0208] [1.20 Example of displaying risk values ​​for threat information based on vehicle condition] Figure 21 shows an example of the display of risk values ​​for threat information based on vehicle status in the display unit 3002 of the monitoring server 30a or 30b. This display is shown for the purpose of checking a list of risk values ​​for each vehicle regarding specific threat information (secondary threat information) for a specific vehicle type.

[0209] The upper left of Figure 21 shows the details of the threat information tailored to vehicle type C. Threat information TID-001_C indicates that the impact is steering wheel tampering, the abnormal signal is the park assist signal, the abnormal message ID is 0x300, the abnormal signal value is in the range of -500 to 500 degrees, the abnormal communication volume is a 50-100% increase in communication volume, the attack deployment potential is medium, and the suitability for vehicle type C is medium.

[0210] The upper right of Figure 21 shows the processing conditions for abnormal signals included in the threat information for vehicle type C. For vehicle type C, the conditions for processing the park assist signal are that the speed is 30 km / h or less and the shift lever is in the D or R position.

[0211] The middle section of Figure 21 shows the risk value evaluation for vehicle ID 1XXXXXXXXXXXXXXX1. The driving conditions are a speed of 20 km / h, the shift lever is in D, and the cruise control function is OFF. Since the conditions for park assist signal processing are met, the risk value is "High". It also shows that the park assist function has been disabled as a risk mitigation measure.

[0212] The lower part of Figure 21 shows the risk value assessment for vehicle ID 1XXXXXXXXXXXXXXX3. The driving conditions are 0 km / h, the gear is in P, and the cruise control function is OFF. Since the conditions for park assist signal processing are not met, the risk value is "low". It also indicates that no risk mitigation measures are being taken.

[0213] For example, the output unit (e.g., display unit 3002) outputs the second threat information if the vehicle compatibility is above a predetermined value. In other words, the output unit does not need to output the second threat information if the vehicle compatibility is below a predetermined value.

[0214] [1.21 Effects of Embodiment 1] The monitoring server 30a in this embodiment abstracts threat information generated based on logs collected from the vehicle 10a, and determines the likelihood of an attack spreading based on the number of vehicle types and individuals for which alerts matching the abstracted threat information have occurred. This makes it possible to understand how likely a threat occurring in a particular vehicle is to spread to other vehicle types and individuals.

[0215] Furthermore, the monitoring server 30b determines the vehicle-specific applicability of a threat based on the signal to be tampered with included in the threat information, the conditions related to the signal processing of the ECU that receives the signal included in the vehicle-specific information, and the network that receives the signal. This makes it possible to determine whether threat information originating in another vehicle is valid for the vehicle 10b that the monitoring server 30b is monitoring.

[0216] Furthermore, the monitoring server 30b calculates the risk value of the threat information from the vehicle status of the monitored vehicle 10b and the conditions related to the signal processing of the ECU that receives the signal to be tampered with, which is included in the threat information. This makes it possible to respond according to the risk of the threat information, which may vary depending on the vehicle status of the monitored vehicle 10b.

[0217] Thus, the monitoring servers 30a and 30b according to this embodiment can determine whether a threat occurring in a specific vehicle 10a is threat information that can be deployed in other vehicles 10b, whether it is suitable for the vehicle type being monitored, and the degree of risk associated with the threat information in the current vehicle state, and can take appropriate action according to the risk value.

[0218] [Other variations] Although this disclosure has been described based on the embodiments described above, it goes without saying that this disclosure is not limited to the embodiments described above. The following cases are also included in this disclosure.

[0219] (1) In the above embodiment, the physical layer and data link layer of the in-vehicle network are not particularly limited, but Ethernet may be used, and not limited to Ethernet, CAN, CAN-FD (Flexible-Datarate), LIN (Local Interconnect Network), FlexRay may be used, or a combination of each may be used.

[0220] (2) In the above embodiment, the threat information abstraction unit 3005 was shown as a component of the monitoring servers 30a and 30b, but it may also be a component of the threat information sharing server 40. This allows the threat information collected by each monitoring server to be centrally managed by the threat information sharing server 40, making it possible to more accurately grasp the occurrence status of the abstracted threat information for each vehicle type and individual.

[0221] (3) In the above embodiment, an example was shown in which the attack deployment level was in three stages: "large," "medium," and "small." However, the method of expressing the attack deployment level is not limited to this. For example, the attack deployment level may be expressed simply by the number of deployed vehicle types or the number of deployed vehicles, or it may be expressed together with "large," "medium," "small," etc. This makes it possible to grasp the status of the attack deployment in detail and to flexibly set the level of attack deployment according to the policy of each monitoring server.

[0222] (4) In the above embodiment, an example was shown in which vehicle compatibility is represented in three stages: "high," "medium," and "low," but the method of representing vehicle compatibility is not limited to this. Also, although it was stated that vehicle compatibility is determined by a matrix of ease of attack and ease of network access, which are represented in three stages, it is not limited to this. For example, ease of attack may be a score calculated from the number of signals different from the target of tampering included in the signal processing conditions of the ECU and the method of acquiring those signals, and similarly, ease of network access may be a score calculated from the number of different networks that acquire the signals and the number of connections from external devices. Vehicle compatibility may be a score calculated from these two scores, or from three scores including ease of attack deployment. This makes it possible to express vehicle compatibility in more detail numerically, and makes it possible to set vehicle compatibility policies in more detail.

[0223] (5) In the above embodiment, an example was shown in which the threat information is stored in plain text, but it may also be stored encrypted.

[0224] (6) In the above embodiment, metadata indicating the attributes of the threat information was not specifically shown within the threat information. However, metadata indicating the attributes of the threat information may include a flag indicating that it is abstract threat information, a flag indicating that it is observed threat information, and a flag indicating that it is vehicle-specific threat information derived from abstract threat information. This makes it easier to prioritize the use of threat information and to express the relationships between threat information, which is effective for managing threat information. Furthermore, the scope of information disclosure may be specified as metadata using the Traffic Light Protocol (TLP). For example, threat information including vehicle information or vehicle-specific IDs may be set to "Red" or "Amber" to limit the recipients of disclosure, while abstract threat information from which vehicle information or vehicle-specific IDs have been removed may be set to "GREEN" to allow sharing within the community. This makes it possible to determine the scope of information disclosure according to the type of threat information.

[0225] (7) In the above embodiment, no special processing was performed on the abnormal signal names that were to be tampered with when abstracting threat information, but signal names may be converted. If the signal name is vehicle-specific, converting from the vehicle-specific signal name to a general signal name makes it difficult to identify the vehicle. Alternatively, when vehicle-specificization is performed, general signal names may be converted to vehicle-specific signal names.

[0226] (8) In the above embodiment, the risk assessment unit 3006 and the threat information utilization unit 3004 were shown as components of the monitoring servers 30a and 30b, but they may also be components within the vehicle. In this case, the vehicle also holds threat information, and the threat information may include vehicle status and corresponding information related to the calculation of risk values. This reduces the processing load on the monitoring servers 30a and 30b, and allows for immediate and effective response on the vehicle side.

[0227] (9) In the above embodiment, an example was shown in which the ease of access to the in-vehicle network was determined by the number of subnetworks that pass from the external connection device to the network that transmits the signal that caused the threat. However, the determination of ease of access is not limited to the number of subnetworks. For example, the ease of reaching the network may be determined by the presence or absence of communication packet filtering at the gateway, the presence or absence of network access authentication, and the presence or absence of message authentication. This makes it possible to evaluate more accurately the likelihood that an attacker will be able to access the network.

[0228] (10) In the above embodiment, an example was shown in which the ease of success of an attack is determined based on the number of conditions for processing when the ECU receives a signal to be tampered with, and whether there are conditions other than the received signal. However, the determination factors are not limited to these. For example, the ease of success of an attack may be determined by whether or not measures are taken to protect against tampering with the signal to be tampered with, or the signal that is the operating condition for processing the signal to be tampered with, such as whether a message authentication code is used to protect against tampering or whether the source of the signal is authenticated. This makes it possible to grasp more accurately the complexity of the conditions for success of an attack by an attacker.

[0229] (11) In the above embodiment, an example was shown in which the risk value is evaluated for each vehicle according to the vehicle state related to the processing of the signal to be tampered included in the threat information. However, the information used for vehicle risk assessment is not limited to this. For example, the risk value may be determined in combination with security alerts detected by the vehicle. Security alerts may include the results of network intrusion detection and host intrusion detection. Alternatively, security alerts may include known vulnerability information of ECUs on the attack path leading to the injection of the signal to be tampered included in the threat information, or the number of observed threats. Security alerts may also include trends in the vehicle state of the vehicle. For example, security alerts may include the frequency of use of driver assistance functions, the distribution of driving speeds, and the degree of agreement between these and the vehicle state related to the processing of the signal to be tampered included in the threat information over a predetermined period. This makes it possible to determine the risk value based on the compromise status of individual vehicles, the number of vulnerabilities that an attacker can exploit in that vehicle type, and the likelihood that the vehicle will enter a high-risk vehicle state, thereby improving the accuracy of risk assessment.

[0230] (12) In the above embodiment, the format of the threat information and the communication protocol are not specified, but the threat information may be in STIX (Structured Threat Information eXpression) format, for example, and the sharing protocol may be TAXII (Trusted Automated eXchange of Indicator Information). This makes it possible to share threat information in a standardized way, which is efficient. However, the format of the threat information and the communication protocol are not limited to these.

[0231] (13) In the above embodiment, the anomaly detection unit 1102 was shown as a component of the in-vehicle network monitoring ECU 110a, but it may also be a component of the monitoring servers 30a and 30b. This makes it possible for the monitoring servers 30a and 30b to execute an anomaly detection algorithm that utilizes resources and to detect anomalies from the vehicle communication log.

[0232] (14) In the above embodiment, the communication network for the signals to be tampered with and the operating conditions is only described as the network to be communicated. However, the network on which the signal is directly received by the ECU may be different from the network on which the source ECU transmits the signal. In this case, the network accessibility may be determined based on the network that is easier for the attacker to access (high accessibility), and the one with the lowest network accessibility among multiple signals may be set as the final network accessibility. This makes it possible to determine the network accessibility based on the network access that is critical to the success of the attack.

[0233] (15) Specifically, each device (system) in the above embodiment is a computer system consisting of a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is stored in the RAM or hard disk unit. Each device achieves its function by operating the microprocessor in accordance with the computer program. Here, the computer program is composed of a combination of multiple instruction codes that indicate commands to the computer in order to achieve a predetermined function.

[0234] (16) In the above embodiments, each device may have some or all of its constituent components made up of a single system LSI (Large Scale Integration). The system LSI is a multi-functional LSI manufactured by integrating multiple components onto a single chip, and specifically, it is a computer system comprising a microprocessor, ROM, RAM, etc. A computer program is stored in the RAM. The system LSI achieves its function by operating the microprocessor in accordance with the computer program.

[0235] Furthermore, each component of the above-mentioned device may be integrated into a single chip individually, or it may be integrated into a single chip to include some or all of the components.

[0236] Furthermore, while we refer to it as a system LSI here, depending on the degree of integration, it may also be called an IC, LSI, super LSI, or ultra LSI. Also, the method of integrated circuit implementation is not limited to LSIs; it may be implemented using dedicated circuits or general-purpose processors. After LSI manufacturing, FPGAs (Field Programmable Gate Arrays) that can be programmed, or reconfigurable processors that allow for the reconfiguration of the connections and settings of circuit cells within the LSI, may also be used.

[0237] Furthermore, if advancements in semiconductor technology or other derived technologies lead to the emergence of integrated circuit technologies that replace LSIs, then naturally, it would be possible to use those technologies to integrate functional blocks. The application of biotechnology, for example, is a possibility.

[0238] (17) Some or all of the components constituting each of the above devices may consist of a removable IC card or a standalone module. The IC card or module is a computer system consisting of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned multi-functional LSI. The IC card or module achieves its function by the operation of the microprocessor according to a computer program. The IC card or module may be tamper-resistant.

[0239] (18) This disclosure can be implemented not only as a threat intelligence deployment system, but also as a threat intelligence deployment method that includes the steps (processes) performed by each component of the threat intelligence deployment system.

[0240] The threat information deployment method is a method executed by a threat information deployment system in an in-vehicle control network system, and includes the following processes as shown in Figure 13: acquiring first threat information relating to a threat occurring in a first vehicle type (step S101), generating abstracted threat information by removing information specific to the first vehicle type from the first threat information (step S102), and outputting second threat information, which is generated based on the abstracted threat information and includes a risk value indicating the degree of threat risk to a second vehicle type different from the first vehicle type (step S107).

[0241] Furthermore, the threat intelligence deployment method may be a computer program that implements the method on a computer, or it may be a digital signal consisting of a computer program. For example, one aspect of this disclosure may be a computer program that causes a computer to execute each characteristic step included in the threat intelligence deployment method shown in any of Figures 14, 15, or 17.

[0242] Furthermore, this disclosure may also refer to a computer program or digital signal recorded on a computer-readable recording medium, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray® Disc), semiconductor memory, etc. Alternatively, it may refer to the digital signal recorded on such a recording medium.

[0243] Furthermore, this disclosure may also include the transmission of computer programs or digital signals via telecommunications lines, wireless or wired communication lines, networks such as the Internet, data broadcasting, etc.

[0244] Furthermore, this disclosure may also describe a computer system comprising a microprocessor and memory, wherein the memory stores the computer program, and the microprocessor operates in accordance with the computer program.

[0245] Alternatively, the program or digital signal may be carried out by another independent computer system by recording and transferring it on a recording medium, or by transferring the program or digital signal via a network or the like.

[0246] (19) The order in which the steps in the flowchart shown in the above embodiment are performed is illustrative for the purpose of specifically illustrating the present disclosure, and may be in a different order. Furthermore, some of the above steps may be performed simultaneously (in parallel) with other steps, and some of the above steps may not be performed.

[0247] Furthermore, the division of functional blocks in the block diagram shown in the above embodiment is just one example; multiple functional blocks may be implemented as a single functional block, a single functional block may be divided into multiple parts, or some functions may be moved to other functional blocks. In addition, the functions of multiple functional blocks having similar functions may be processed in parallel or time-sharing by a single piece of hardware or software.

[0248] (20) In the above embodiment, the vehicle control network system was described as an example of an automotive cybersecurity monitoring system, but it is not limited to this and may be a home network system, an in-facility (e.g., hospital) network system, a factory network system, etc.

[0249] (21) The above embodiments and the above modified examples may be combined. [Industrial applicability]

[0250] This disclosure is effective for communication log aggregation devices and the like in control network systems such as in-vehicle network systems. [Explanation of Symbols]

[0251] 10a, 10b Vehicles 20a, 20b Network 30a, 30b monitoring servers 40 Threat Intelligence Sharing Servers 100a In-vehicle network 110a In-vehicle network monitoring ECU 1101 In-vehicle network communication unit 1102 Anomaly detection unit 1103 Monitoring Server Communication Unit 1104 Communication log storage unit 1105 Anomaly detection log retention unit 3001 Vehicle Communications Department 3002 Display section 3003 Threat Intelligence Generation Unit 3004 Threat Intelligence Utilization Department 3005 Threat Intelligence Abstraction Unit 3006 Risk Assessment Department 3007 Threat Intelligence Sharing Server Communications Unit 3008 Threat Intelligence Adaptation Unit 3009 Vehicle communication log storage unit 3010 Alert retention unit 3011 Threat Intelligence Retention Unit 3012 Vehicle-Specific Information Storage Unit 4001 Monitoring Server Communication Unit 4002 Shared threat information holding unit

Claims

1. A threat intelligence deployment system in an in-vehicle control network system, An acquisition unit that acquires first threat information regarding a threat that occurred in a first type of vehicle, A threat information abstraction unit generates abstracted threat information by removing information specific to the first vehicle type from the first threat information, The system includes an output unit that outputs second threat information, which includes a risk value indicating the degree of threat risk to a second vehicle type different from the first vehicle type, generated based on the abstracted threat information. Threat intelligence deployment system.

2. The threat information deployment system further includes a risk value calculation unit that calculates the risk value. The threat information deployment system according to claim 1.

3. The aforementioned threat information deployment system further comprises a threat occurrence status retention unit and an attack deployment determination unit, The threat occurrence status retention unit retains the threat occurrence status for each abnormal vehicle in which a threat corresponding to the abstracted threat information has been observed. The attack deployment determination unit calculates the deployment potential of the threat corresponding to the abstracted threat information, according to the number of vehicle types or the number of individual abnormal vehicles indicated by the occurrence status. The risk value calculation unit calculates the risk value based on the expandability. The threat information deployment system according to claim 2.

4. The aforementioned threat information deployment system further comprises a vehicle-specific information storage unit and a vehicle-specific suitability determination unit. The vehicle-specific information holding unit holds vehicle-specific information for each vehicle model, which includes at least one of the following: information relating to the installed electronic control unit, signals received by the electronic control unit, the network through which the signals received by the electronic control unit are communicated, and configuration information of the in-vehicle network. The vehicle suitability determination unit calculates the suitability of the abstract threat information to the second vehicle using the abstract threat information and the vehicle-specific information relating to the second vehicle. The risk value calculation unit calculates the risk value based on the suitability. The threat information deployment system according to claim 2.

5. The information relating to the electronic control unit includes operating conditions for processing signals received by the electronic control unit. The vehicle compatibility determination unit calculates the compatibility using the ease with which an attack on the second vehicle can be carried out, which is determined based on at least one of the following: whether the operating conditions for processing the signals that constitute a threat corresponding to the abstracted threat information include conditions relating to signals outside the in-vehicle network in the second vehicle; whether there are a predetermined number or more of such operating conditions; and whether tampering countermeasures or access control are in place for the signals received by the electronic control unit. The threat information deployment system according to claim 4.

6. The vehicle type suitability determination unit calculates the suitability using the ease of access to the communication network, which is determined according to the number of subnetworks traversed from the external connection device, which is connected to an external network among the electronic control devices installed in the second vehicle type, to the communication network in the second vehicle type that transmits signals that constitute a threat corresponding to the abstracted threat information. The threat information deployment system according to claim 4.

7. The output unit outputs the second threat information when the compliance is equal to or greater than a predetermined value. The threat information deployment system according to claim 4.

8. The aforementioned threat information deployment system further comprises a vehicle-specific information storage unit and a vehicle log collection unit. The aforementioned vehicle-specific information holding unit holds information about the electronic control unit, including operating conditions for processing signals received by the installed electronic control unit, for each vehicle model. The vehicle log collection unit collects vehicle logs of the second vehicle type, The risk value calculation unit calculates the risk value for the vehicle according to the degree of agreement between the operating conditions for processing the signals that constituted the threat corresponding to the abstracted threat information and the state of the vehicle included in the vehicle log. The threat information deployment system according to claim 2.

9. The aforementioned threat intelligence deployment system further includes a risk response unit, The risk response unit determines the response to the threat to the second vehicle type according to the risk value, The aforementioned response includes at least one of the following: matching the abnormal communication patterns indicated by the second threat information with communication logs collected from the second vehicle type; updating the firmware of the electronic control unit installed in the vehicle; restricting the functions of the vehicle; and notifying security analysts of an alert. A threat intelligence deployment system according to any one of claims 1 to 8.

10. A threat intelligence deployment method performed by a threat intelligence deployment system in an in-vehicle control network system, We obtained the first threat information regarding a threat that occurred in the first vehicle type. Abstract threat information is generated by removing information specific to the first vehicle type from the first threat information. Based on the abstracted threat information, a second threat information is output, which includes a risk value indicating the degree of threat risk to a second vehicle type different from the first vehicle type. Threat intelligence deployment methods.

11. A program for causing a threat intelligence deployment system to execute the threat intelligence deployment method described in claim 10.

Images