Analysis device

Abstract

The present application provides an analysis device that appropriately outputs an abnormality notification by reducing false detection of attack events. The present application is an analysis device configured to be able to communicate with a plurality of monitoring target devices, wherein the analysis device collects monitoring results of the monitoring target devices, determines whether an abnormality of each of the monitoring target devices has occurred based on the monitoring results, and decides whether to output an abnormality notification indicating an abnormality based on a result of the determination and a code verification result of each of the monitoring target devices.

Description

Technical Field

[0001] This invention relates to an analysis device. More specifically, this invention relates to an analysis device mounted on a vehicle for detecting anomalies based on monitoring results from a monitored object device, and particularly to an analysis device for determining whether to output an anomaly notification to the outside of the vehicle. Background Technology

[0002] To manage vehicle safety during operation after delivery, the industry is researching automotive-oriented Security Operation Centers (SOCs). In an SOC, logs related to security incidents are collected from the vehicle. SOC operators or analysts use these logs to analyze the vehicle's condition and its impact on other vehicles, and to formulate and implement countermeasures. The utilization of the detection results from attack detection devices installed on the vehicle is also being considered as part of the security incidents collected from it.

[0003] As the number of connected cars continues to increase, the scale of vehicles monitored by the System-on-Chiefly (SOC) is also growing. In this environment, the more false detections the attack detection device makes, the greater the unnecessary workload for operators or analysts.

[0004] Therefore, attack detection technology requires reducing false detections. As a technique to improve the accuracy of attack detection, Patent Document 1 discloses a method for controlling communication with the outside of a vehicle based on the intrusion depth of an illegal attack on the vehicle-mounted device. Existing technical documents Patent documents

[0005] Patent Document 1: Japanese Patent Application Publication No. 2019-125344 Summary of the Invention The problem the invention aims to solve

[0006] However, existing technologies have the problem of failing to properly output exception notifications.

[0007] According to the technology in Patent Document 1, it is expected that the accuracy of attacks can be improved, i.e., false detections can be reduced, based on the depth of intrusion into the vehicle-mounted device. However, when other attack events are detected some time after the initial detected attack event, it is difficult to determine whether they are false detections or attacks. For example, the following method is not disclosed: during the period from vehicle start-up to stop (travel time), determining whether an attack event detected during a certain travel time and an attack event detected during several or dozens of subsequent travel times are actual attacks or false detections.

[0008] The present invention was made in view of the above problems, and its object is to provide an analysis device that appropriately outputs anomaly notifications by reducing false detections of attack events. Technical means to solve the problem

[0009] One example of the analysis apparatus of the present invention is configured to communicate with multiple monitored target devices, wherein, The analysis device collects the monitoring results from each of the monitored devices. Based on the monitoring results, it is determined whether any abnormality has occurred in the monitored devices. Based on the results of the determination and the code verification results of each monitored object device, a decision is made on whether to output an abnormal notification indicating an anomaly. This specification contains the disclosure of Japanese Patent Application No. 2021-037773, which forms the basis of the priority of this application. The effects of the invention

[0010] The analysis device of the present invention can appropriately output anomaly notifications by reducing false detections of attack events. Attached Figure Description

[0011] Figure 1 This diagram illustrates the configuration of the analysis apparatus according to Embodiment 1 of the present invention. Figure 2 This is a diagram illustrating the general processing flow for determining when to issue a notification to the outside of the vehicle. Figure 3 To indicate Figure 2 A detailed flowchart of step 206. Figure 4 This is a diagram illustrating the general processing flow for handling notifications from outside the vehicle. Figure 5 A diagram illustrating an example of log information collected from an onboard device. Figure 6A A diagram illustrating an example of an instant notification rule based on an anomaly mechanism. Figure 6B A diagram illustrating an example of instant notification rules based on log type. Figure 7 A diagram illustrating an example of the influence range of an onboard device. Figure 8A A diagram illustrating examples of whether or not damage exists to various vehicle-mounted devices. Figure 8B A diagram illustrating an example of overall situational information about a vehicle. Figure 9 A diagram illustrating an example of the analysis device's judgment on the vehicle's condition. Detailed Implementation

[0012] The following examples will be used, with reference to the appendix. Figure 1 The embodiments of the present invention will be described in detail below. [Example 1]

[0013] The analysis device in this embodiment performs the following method: determining the timing for notifying the exterior of the vehicle based on abnormal log information obtained from the on-board device. However, the technical concept of the present invention is not limited to this embodiment. For example, the function of detecting abnormalities and the function of determining the timing for notifying the exterior of the vehicle can be applied to the same device.

[0014] Figure 1 The configuration of the analysis device 1 in this embodiment is shown. The analysis device 1 is, for example, a device mounted on the vehicle 50 that analyzes information associated with the vehicle 50. However, the analysis device 1 may not be mounted on the vehicle 50, and may also be a device that analyzes information associated with objects other than the vehicle 50.

[0015] The analysis device 1 is connected to the vehicle-mounted device 3 via the communication bus 2. The vehicle-mounted device 3 is a device mounted on the vehicle 50, and in this embodiment, it is the monitoring target device that is monitored by the analysis device 1. The analysis device 1 is communicatively connected to multiple vehicle-mounted devices 3.

[0016] Communication bus 2 can physically comprise multiple communication buses, each with its own or different specifications. These communication buses may use specifications such as CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), and Ethernet (registered trademark).

[0017] The analysis device 1 includes an arithmetic unit (not shown) and a storage unit (not shown). The arithmetic unit may include, for example, a CPU. The storage unit may include, for example, ROM and RAM. By executing the program stored in the storage unit, the analysis device 1 can perform the functions described in this specification.

[0018] For example, the analysis device 1 includes a log collection unit 12, a log parsing unit 13, an immediate notification determination unit 14, a symptom activity determination unit 15, a vehicle status update unit 16, an attack detection determination unit 17, a notification information generation unit 18, a notification determination unit 19, an instruction content parsing unit 20, and a notification timing control unit 21 as its functional units. In this specification, the processing performed by the CPU or these functional units can also be said to be performed by the analysis device 1.

[0019] Furthermore, the storage unit includes a storage section 100. The storage section 100 may be entirely non-volatile or partially volatile. Additionally, the analysis device 1 includes a communication section 11, which is a communication interface for performing calculations required for communication.

[0020] Figure 1The functional block diagram shown is for illustrative purposes only; the units and names of functions are not limited to this. For example, the functions implemented by the log parsing unit 13 in this embodiment can also be implemented by... Figure 1 Other functional units shown can be implemented, or they can be implemented by units not shown. Figure 1 It is implemented through the functional departments within the system.

[0021] The communication unit 11 receives messages from the vehicle-mounted devices 3 via the communication bus 2, and also sends messages to the vehicle-mounted devices 3 via the communication bus 2. The analysis device 1 uses the communication unit 11 to collect information from each of the vehicle-mounted devices 3 (e.g., information that can determine abnormal states). Furthermore, not only the vehicle-mounted devices 3, but also the logs detected by the analysis device 1 itself can be collected and stored.

[0022] The log collection unit 12 stores the information collected from the vehicle-mounted device 3 into the vehicle log information 101. The log parsing unit 13 analyzes the information collected from the vehicle-mounted device 3 to check for any information indicating anomalies. The immediate notification determination unit 14 determines whether the information indicating anomalies conforms to the immediate notification rule 102. The symptom activity determination unit 15 determines whether any information indicating anomalies has been registered in the vehicle situation information 104 within a specified period (e.g., the latest completed travel time). The vehicle status update unit 16 updates the vehicle situation information 104 based on the information indicating anomalies. The attack detection determination unit 17 determines whether an attack has been detected based on the vehicle situation information 104 and updates the situation judgment result 105. The notification information generation unit 18 generates information to notify the outside of the vehicle 50. The notification determination unit 19 decides whether to notify the outside of the vehicle 50 based on the situation judgment result 105. The instruction content parsing unit 20 parses the instruction content related to notification control received from the outside of the analysis device 1. The notification timing control unit 21 notifies the vehicle 50 of information related to the detected anomaly at a predetermined time.

[0023] The storage unit 100 has the following functional units. - Vehicle log information 101 that maintains information obtained from the vehicle-mounted device 3. - Rule 102 for determining whether to immediately output an instant notification to the outside of vehicle 50 in response to detected anomalies. - Inter-device influence information 103, indicating the mutual influence relationships between vehicle-mounted devices 3. For example, it indicates the relationship between a vehicle-mounted device 3 involved in anomalies and other vehicle-mounted devices 3 that may become targets of attacks. - Maintain vehicle situation information 104 regarding the presence and status of damage to each onboard device 3. - Indicates the situation judgment result 105 based on the state of vehicle 50 according to vehicle situation information 104.

[0024] The same applies to storage unit 100. Figure 1The functional block diagram shown is for illustrative purposes only; the units and names of functions are not limited to this. For example, the information maintained by the vehicle log information 101 in this embodiment can also be provided by... Figure 1 The storage unit 100 may be used to store other functional units shown, or it may be used by units not shown. Figure 1 The storage unit 100 contains functional units for storage.

[0025] Figure 2 This is a flowchart illustrating the process by which the analysis device 1 determines when an external notification anomaly occurs to the vehicle 50. The execution entity for each step described below is, for example, the CPU of the analysis device 1 (not shown).

[0026] In step 201, the log collection unit 12 uses the communication unit 11 to collect the monitoring results of each vehicle-mounted device 3 and stores them in the vehicle log information 101 of the analysis device 1. The monitoring results are collected, for example, in the form of log information. For example, the analysis device 1 may collect log information periodically from startup, or it may collect log information at a pre-set time, or it may receive log information sent from the vehicle-mounted device 3 at a time determined by each vehicle-mounted device 3. In addition, the log collection unit 12 may also collect logs within a specified period. This specified period may include multiple travel times (or a portion thereof), for example, it may span multiple travel times. In the case of spanning multiple travel times, when the logs are initially obtained from each vehicle-mounted device 3 after the vehicle 50 or the analysis device 1 starts up, if the code verification result shows that there is no program tampering (or if no tampering is indicated), the previously collected logs (e.g., abnormal logs) may be deleted. Alternatively, even if the travel time spans, the previous logs may be retained as is, regardless of the code verification result, and the logs may be deleted after notifying the outside of the vehicle 50.

[0027] Figure 5 This section presents an example of vehicle log information 101 that retains the log information collected in step 201 above. The logs contained in vehicle log information 101 are organized per vehicle device. The logs include exception logs (logs indicating that an exception has occurred), which contain the following information. - An identifier assigned to each type of exception log, namely exception ID 1011. - This represents the text data of the exception log, i.e., the exception content 1012. - This indicates the abnormal part 1013, which indicates that an abnormality has occurred in the vehicle-mounted device 3. - This indicates the moment 1014 when the anomaly was detected. This moment 1014 indicates whether the log was included within any operation period of the analysis device 1 or any operation period of the vehicle 50. Furthermore, the operation period of the analysis device 1 can be, for example, the period from the start of the analysis device 1 to its stop, and the operation period of the vehicle 50 can be, for example, the period from the start of the vehicle 50 to its stop.

[0028] Each vehicle-mounted device 3 may generate a log prior to step 201 using known techniques. For example, if there is access from a terminal not registered as an external device via communication channel Ch1 monitored by vehicle-mounted device A, vehicle-mounted device A records the following in the log: anomaly content 1012 "unregistered terminal access", the anomaly ID "0x001", the anomaly location 1013 "Ch1", and the time of detection "2020 / 02 / 01 11:10:20". This log is collected in step 201.

[0029] In step 202, the log parsing unit 13 determines whether the vehicle log information 101 stored in step 201 contains abnormal logs, and extracts the abnormal logs accordingly. That is, the log parsing unit 13 determines whether an abnormality has occurred in each vehicle device 3 based on the monitoring results of the vehicle device 3. In this embodiment, only abnormal logs are maintained, but other log information may also be maintained. In this case, an identifier that can identify abnormal logs may be provided. This determination can be performed, for example, based on the abnormality ID 1011. In addition, the log information may include code verification results. For example, information indicating whether tampering has occurred or not may be included as code verification results.

[0030] In step 203, if an exception log is included in step 202, proceed to step 204. Alternatively, if no exception log is included, the process ends. After completion, proceed to step 201 at a predetermined time. Furthermore, as a variation, the process may also proceed to step 204 if a log indicating the code verification result is included. In this case, the process may proceed to step 204 if no tampering is determined as the code verification result.

[0031] In step 204, the instant notification determination unit 14 determines, according to the instant notification rule 102, whether there is any abnormal log in the vehicle log information 101 that should be immediately notified to the outside of the vehicle 50.

[0032] Figure 6AThis section demonstrates an example of the instant notification rule 102 referenced by the instant notification determination unit 14 in step 204 above. This example is based on an abnormal device 1021. For instance, if the vehicle-mounted device 3 involving an abnormal log conforms to the abnormal device 1021 in instant notification rule 102, the instant notification determination unit 14 determines to output an instant notification for that abnormal log. An instant notification is a type of notification indicating an abnormality (abnormal notification). Determining to output an instant notification for a specific abnormal log corresponds to deciding to output an abnormal notification for that specific abnormal log.

[0033] exist Figure 6A In the example, an immediate notification is output based on the abnormal logs related to vehicle device I. Furthermore, if abnormal logs related to vehicle device G and vehicle device H exist simultaneously or within a specified time, an immediate notification is output based on these abnormal logs.

[0034] Furthermore, in Figure 6A In the example, the instant notification determination unit 14 can decide whether to output an anomaly notification based on the content of any anomaly occurring in the vehicle device 3 (e.g., a single anomaly) (example of vehicle device I). In this way, an anomaly notification can be reliably output in the event of a major anomaly.

[0035] Furthermore, the instant notification rule 102 may also include the condition that multiple abnormal logs matching the abnormal device 1021 are generated. For example, the instant notification determination unit 14 may further determine whether to output an instant notification based on the number of times any vehicle device 3 experiences an abnormality within a specified period. For example, if multiple abnormal logs related to the same vehicle device 3 exist within a specified period, these abnormal logs can be determined as instant notification targets. In this way, frequent abnormalities will not be missed.

[0036] Figure 6B This section presents another example of the instant notification rule 102 referenced by the instant notification determination unit 14 in step 204 above. This example is based on the type of exception log. For instance, in step 204 above, if exception ID 1011 matches instant notification object exception ID 1022, the instant notification determination unit 14 determines to output an instant notification.

[0037] Furthermore, in Figure 6BIn the example, the instant notification determination unit 14 can decide whether to output an exception notification based on the content of a single exception occurring in any vehicle device 3. As a variation, the instant notification rule 102 may also include the condition that multiple exception logs matching the instant notification object exception ID 1022 are generated. For example, the instant notification determination unit 14 can further determine whether to output an instant notification based on the number of times the same exception occurs within a specified period. For example, if multiple exception logs related to the same exception ID exist within a specified period, these exception logs can be determined as instant notification objects. In this way, frequently occurring exceptions will not be missed.

[0038] about Figure 6A The rules shown and Figure 6B The rules shown can be used for judgment by using only one of them, or by using both. When using both, an immediate notification can be output based on the exception logs that match either one, or an immediate notification can be output only if the exception logs match both.

[0039] In step 205, if the instant notification determination unit 14 determines in step 204 that an instant notification will be output, it proceeds to step 208; if it determines that an instant notification will not be output, it proceeds to step 206.

[0040] In step 206, the attack detection and determination unit 17 determines whether an attack has occurred based on the abnormal logs extracted in step 202 and the vehicle situation information 104 described later, thereby determining whether to send a notification to the outside of the vehicle. Details of this determination are as follows... Figure 3 Related topics will be discussed later.

[0041] In step 207, the attack detection and determination unit 17 determines the attack based on the situation determination result 105 (and...). Figure 9 The attack detection determination unit 17 determines whether to output an anomaly notification based on the determination results related to whether an anomaly has occurred in each vehicle device 3 (step 203 above) and the code verification results of each vehicle device 3 (step 302 described later). Therefore, it can be said that the attack detection determination unit 17 determines whether to output an anomaly notification based on the determination results related to whether an anomaly has occurred in each vehicle device 3 and the code verification results of each vehicle device 3.

[0042] Here, the attack detection and determination unit 17 decides to output an anomaly notification corresponding to the determination that either vehicle 50 or vehicle-mounted device 3 is under attack. Furthermore, the attack detection and determination unit 17 decides not to output an anomaly notification corresponding to the determination that neither vehicle 50 nor vehicle-mounted device 3 is under attack, or corresponding to the determination that either vehicle 50 or vehicle-mounted device 3 may be under attack but should be continuously monitored in a wait-and-see manner.

[0043] For example, in situation judgment result 105, situation judgment ID 1051 (and Figure 9 If the value (as described below) is "0x00" or "0x01", no exception notification will be output; if it is "0x10" or "0x11", an exception notification will be output. The content of the output exception notification can be set to, for example, the immediate notification mentioned above or the cumulative notification described below.

[0044] If it is decided to output an exception notification, proceed to step 208; otherwise, end the process.

[0045] In step 208, the notification information generation unit 18 generates an anomaly notification as information to notify the outside of the vehicle. For example, the anomaly notification may include vehicle log information 101, vehicle situation information 104, and information based on situation assessment results 105. In addition, the anomaly notification may include information indicating that an attack has been detected.

[0046] In step 209, the notification determination unit 19 outputs the anomaly notification generated in step 208 to the outside of the vehicle 50. The output destination can be a device located outside the vehicle 50, in which case communication can be made via any onboard device 3. Alternatively, the output destination can be a device mounted on the vehicle 50, for example, illuminating a light mounted on the vehicle 50, thereby enabling external recognition of the detected attack.

[0047] In step 210, the analysis device 1 switches to a response mode for safe handling of the vehicle 50 based on the situation assessment result 105. The specific actions in the response mode can be designed by those skilled in the art based on known technologies. Alternatively, step 210 can be omitted.

[0048] Through the above steps, the analysis device 1 can notify the outside of the vehicle of the anomaly at the appropriate time when an attack is detected.

[0049] Figure 3 This is a detailed flowchart of the processing in step 206 above. The execution entity for each step described below is, for example, the CPU (not shown) of analysis device 1. For example, except for step 307, it is executed according to each exception log. Figure 3 The processing, step 307 is based on Figure 2 The processing is executed accordingly.

[0050] In step 301, the symptom activity determination unit 15 refers to the vehicle situation information 104 to determine whether any signs of attack have been recorded. Next, using... Figure 7 , Figure 8A as well as Figure 8B A specific example of the processing in step 301 will be explained.

[0051] Figure 7 An example of inter-device impact information 103 is shown, which establishes a relationship between the vehicle-mounted device 3 (victim device 1031) involved in the abnormal log and the vehicle-mounted device 3 (impact target 1032) that becomes the target of the impact due to the abnormality.

[0052] The affected target 1032 is associated with the victim device 1031, which experienced an anomaly, and may be affected by an attack. Furthermore, the monitored object group ID 1033 is identification information that identifies the group consisting of the victim device 1031 and the affected target 1032.

[0053] For example, for Figure 5 The abnormal log with abnormal ID 1011 as “0x002” is identified by the symptom activity determination unit 15 as the victim device “Vehicle Device A” which has the abnormal ID registered. It also identifies the affected target 1032 “Vehicle Device D” in the victim device 1031 of the inter-device influence information 103 that matches Vehicle Device A.

[0054] Figure 8A An example of vehicle situation information 104 showing signs of activity is shown. Vehicle situation information 104 includes vehicle device ID 1041 identifying the vehicle device 3 mounted on vehicle 50 and infringement presence / absence 1042 indicating whether the vehicle device has been compromised.

[0055] Figure 8A The vehicle situation information 104 can be generated before the execution of step 301. For example, "1" can be recorded for vehicle-mounted devices 3 that have experienced an anomaly during a specified period (situation information recording period), and "0" can be recorded for vehicle-mounted devices 3 that have not experienced an anomaly.

[0056] The occurrence of an anomaly suggests the possibility of signs of an attack. Therefore, information indicating whether an anomaly occurred during the situation information recording period can also be said to indicate whether each vehicle-mounted device 3 has signs of an attack.

[0057] The start and end points of the situation information recording period can be arbitrarily designed. For example, it can be the operation period of vehicle 50 (e.g., the period from the start of vehicle 50 to its stop) or the operation period of analysis device 1 (e.g., the period from the start of analysis device 1 to its stop). In this way, the recording of the anomaly log can be matched with the operation period of analysis device 1 or vehicle 50 to make a more appropriate judgment.

[0058] Furthermore, the period for recording this situation information can be a period determined based on specific event signals, or a period based on a predetermined time.

[0059] Vehicle situation information 104 can be designed to be updated at any time. For example, it can be updated based on the end of a situation information recording period. For example, if vehicle situation information 104 retains information related to the first situation information recording period, when the second situation information recording period ends, vehicle situation information 104 can be updated to the content corresponding to the second situation information recording period. Furthermore, situation judgment result 105 can be initialized at any time. For example, if the travel time changes (i.e., the previous travel time ends and a new travel time begins), situation judgment result 105 can be maintained or initialized, i.e., set to "0x00". Situation judgment result 105 can also be initialized after performing prescribed procedures from outside vehicle 50 (e.g., it has been confirmed by SOC that there are no problems, or the problematic procedure has been corrected). Alternatively, situation judgment result 105 can also be initialized when logs indicating no tampering are collected from all on-board devices 3 or the corresponding on-board devices 3 as a code verification result.

[0060] In step 301, for example, for Figure 5 The anomaly log with an anomaly ID 1011 as "0x002" is first determined by the symptomatic activity determination unit 15 to determine whether there is symptomatic activity in the vehicle-mounted device (in this case, vehicle-mounted device A) involved in the anomaly log. For example, if the value of the infringement presence / absence 1042 corresponding to vehicle-mounted device A is "1", then symptomatic activity is determined to exist; if it is "0", then no symptomatic activity is determined to exist. In this example, the value of the infringement presence / absence 1042 corresponding to vehicle-mounted device ID 1041, which is "vehicle-mounted device A", is "0", so no symptomatic activity is determined for vehicle-mounted device A.

[0061] Next, the symptom activity determination unit 15, as described above, identifies the vehicle-mounted device D as the target of influence based on the inter-device influence information 103, and determines whether the vehicle-mounted device D exhibits symptom activity. For example, if the value of the infringement presence / absence 1042 corresponding to the vehicle-mounted device D is "1", then symptom activity is determined to exist; if it is "0", then no symptom activity is determined to exist. In this example, the value of the infringement presence / absence 1042 corresponding to the vehicle-mounted device ID 1041, which is "vehicle-mounted device D", is "1", so symptom activity is determined to exist for the vehicle-mounted device D.

[0062] Furthermore, for example, regarding abnormal logs related to the vehicle-mounted device C, in Figure 7When the victim device 1031 is vehicle-mounted device C, the group containing vehicle-mounted devices D and E is associated with the group containing only vehicle-mounted device F as the target of influence 1032. Therefore, for abnormal logs related to vehicle-mounted device C, if either or both of the infringement presence / absence 1042 corresponding to vehicle-mounted device D and vehicle-mounted device E are "1", then there is symptomatic activity for vehicle-mounted device D or vehicle-mounted device E, or both; if both are "0", then there is no symptomatic activity for vehicle-mounted device D and vehicle-mounted device E. Furthermore, if the infringement presence / absence 1042 corresponding to vehicle-mounted device F is "1", then there is symptomatic activity for vehicle-mounted device F; if it is "0", then there is no symptomatic activity for vehicle-mounted device F.

[0063] The symptom activity determination unit 15 can determine whether there is symptom activity for all abnormal logs as described above. In addition, the symptom activity determination unit 15 can also determine the victim device that has an abnormality based on the abnormal logs extracted from the vehicle log information 101 in step 202 above, determine the scope of influence of the victim device using the inter-device influence information 103, and determine whether there is attack symptom by referring to the presence or absence of infringement 1042 for the vehicle device ID 1041 that matches the victim vehicle device and the vehicle devices included in the scope of influence.

[0064] If the result of the determination in step 301 is that there is symptomatic activity in any vehicle device, proceed to step 302; otherwise, proceed to step 303.

[0065] In step 302, the attack detection determination unit 17 refers to the code verification result. For example, it refers to the code verification result of the vehicle-mounted device 3, which was determined to have signs of activity in step 301. Specific examples of the code verification result are not particularly illustrated, but for example, it can indicate whether the program executed by the vehicle-mounted device 3 has been tampered with, and can be generated based on known techniques. Furthermore, if the log obtained in step 201 is a log indicating the code verification result of the vehicle-mounted device 3 (e.g., whether tampering has occurred), it can be determined in step 302 whether the content of the log indicates tampering. For example, the analysis device 1 can collect the code verification result (whether tampering has occurred) of each vehicle-mounted device 3 from each vehicle-mounted device 3 in step 201 when the vehicle 50 is started (or when the analysis device 1 is started), and determine the code verification result in this step 302.

[0066] For example, code verification results can be generated through a secure boot process. The secure boot process is used to determine whether the program executed by the onboard device 3 has been tampered with at the start of the program's execution. Furthermore, the code verification result is not limited to being provided through the secure boot process; it can also be the result of verification performed at any time after the program's execution has begun.

[0067] If it is determined that the program executed by the on-board device 3, which exhibits signs of activity, has been tampered with, the process proceeds to step 304. Otherwise, the process proceeds to step 305.

[0068] In steps 303, 304, and 305, the vehicle status update unit 16 updates the vehicle situation information 104 based on the new abnormal logs extracted from the vehicle log information 101.

[0069] Figure 8B This example demonstrates the vehicle situation information 104 updated in step 303 above. Furthermore, in this embodiment, the vehicle situation information 104 includes... Figure 8A The information shown and Figure 8B The information shown can be contained in different regions (e.g., different databases, RAM, flash memory).

[0070] Figure 8B The vehicle situation information 104 shown includes the following information. - Identify the monitoring object group ID 1043 for groups of interconnected devices. - Indicates the associated device 1044 of the vehicle-mounted device included in each group. The relationship between the devices included in each group can also be... Figure 7 The inter-device influence information 103 corresponds to this. In this embodiment, Figure 8B The relationship shown is Figure 7 The relationships shown correspond to each other, while in the variant examples these relationships do not need to correspond. - Indicates the nature of the damage to each vehicle-mounted device (1045). - This refers to threshold 1046, which is the threshold used to determine whether to output an abnormal notification based on the infringement situation 1045.

[0071] The vehicle status update unit 16 updates the infringement presence / absence 1042 that corresponds to the on-board device (e.g., on-board device A) involved in the abnormal log from "0" to "1". For example, for the abnormal log related to on-board device A, from Figure 7 The monitored object group ID 1033 obtains the ID {0x01} of the group that treats vehicle device A as victim device 1031. Figure 8B The corresponding group's infringement situation 1045 ( Figure 8B If the example is {1, 1} and the value is {0, 0}, then update it to {1, 0}.

[0072] In step 306, the attack detection determination unit 17 compares the infringement situation 1045 in the vehicle situation information 104 with a threshold 1046. For example, it compares the sum of the numbers contained in the infringement situation 1045 with the threshold for each group. If the sum exceeds the threshold, it determines to output a cumulative notification. A cumulative notification is a type of abnormal notification. If the sum does not exceed the threshold, it determines not to output an abnormal notification.

[0073] Furthermore, as a variation, the determination in step 306 can be omitted. In this case, it can be decided not to output an exception notification (same as the case where the threshold is not exceeded).

[0074] In step 307, the vehicle status update unit 16 updates the situation judgment result 105 based on the results of steps 303, 304 or 306.

[0075] Figure 9 An example of situation judgment result 105 is shown. Situation judgment result 105 includes situation judgment ID 1051 that identifies the situation of the vehicle and state 1052 that represents the situation content of the vehicle.

[0076] For example, as an initial state (e.g., a state where no exception logs are logged), situation judgment ID 1051 is "0x00" and state 1052 is "normal".

[0077] If step 303 was executed before step 307, situation judgment ID 1051 becomes "0x01" and state 1052 becomes "continuous monitoring".

[0078] If step 304 was executed before step 307, situation judgment ID 1051 becomes "0x11" and status 1052 becomes "instant notification".

[0079] If step 306 was executed before step 307 and the threshold is exceeded, situation judgment ID 1051 changes to "0x10" and state 1052 changes to "cumulative notification". Furthermore, if step 306 was executed before step 307 and the threshold is not exceeded, situation judgment ID 1051 changes to "0x01" and state 1052 changes to "continuous monitoring".

[0080] Furthermore, when multiple abnormal logs yield different results, the situation judgment ID 1051 takes precedence over the maximum value among the results. For example, if "continuous monitoring" is determined for one abnormal log (situation judgment ID 1051 is "0x01") and "immediate notification" is determined for another abnormal log (situation judgment ID 1051 is "0x11"), the resulting situation judgment ID 1051 will become "0x11".

[0081] like Figure 9 As shown, in this embodiment, the exception notification includes cumulative notifications related to the number of times an exception has occurred and immediate notifications related to the content of the exception.

[0082] Error notifications can also include information indicating whether they are cumulative or instantaneous. This allows for a more detailed output of the error information.

[0083] Through the above processing, the analysis device 1 can determine whether to output an anomaly notification to the outside of the vehicle. If it decides to output an anomaly notification, it can notify the outside of the vehicle at an appropriate time so that a timely response can be taken.

[0084] according to Figure 3 In steps 301, 302, and 304, if the analysis device 1 determines that there is symptomatic activity (i.e., an anomaly has occurred within a specified period) and tampering has occurred for any vehicle-mounted device 3, it decides to output an anomaly notification. Therefore, a more appropriate determination can be made based on past symptomatic activities and the latest code verification results.

[0085] Figure 4 This is a flowchart illustrating an example of how the analysis device 1 processes information from an externally output onboard device of a vehicle. The analysis device 1 may also include... Figure 2 In addition to step 209 shown, it is also through Figure 4 The process shown or through Figure 4 The processing shown is not Figure 2 Step 209, as shown, is used to output an exception notification.

[0086] Figure 4 In particular, the cases where output is given in the form of timed reports and cases where output is given according to instructions from outside the vehicle are explained. The execution entity for each step described below is, for example, the CPU of the analysis device 1 (not shown). Furthermore, this processing flow is executed, for example, when the vehicle 50 is started. Moreover, this processing flow can be executed at a predetermined time, can be executed repeatedly at regular intervals, or can be executed after an anomaly is notified.

[0087] In step 401, the instruction content parsing unit 20 confirms whether a notification instruction has been received from outside the vehicle. If a notification instruction has been received, the process proceeds to step 402; otherwise, it proceeds to step 405.

[0088] In step 402, the instruction content parsing unit 20 parses the instruction content received from outside the vehicle. For example, the instruction content includes information specifying information to be output to outside the vehicle. For example, the instruction content may include a specification for a specific in-vehicle device, a specification for specific log information, a specification for log information that should be collected additionally from other in-vehicle devices, a specification for other information stored in the vehicle, etc. In addition, the instruction content may also include information for changing the function or configuration of the analysis device 1.

[0089] In step 403, the notification information generation unit 18 collects the necessary information from the analysis device 1 or the vehicle-mounted device 3 based on the content parsed in step 402 above.

[0090] In step 404, the notification information generation unit 18 uses the information collected in step 403 above to generate information that is output to the outside of the vehicle.

[0091] In step 405, the notification timing control unit 21 confirms whether the current time is the prescribed notification timing. For example, the prescribed timing may be the time when a prescribed event or process occurs (e.g., when it is started) or a prescribed date and time.

[0092] In step 406, the timing control unit 21 is notified to proceed to step 407 if the current time is determined to be a specified timing based on the confirmation result of step 405 above; otherwise, the process ends.

[0093] In step 407, the notification information generation unit 18 generates data in a fixed format that is output to the outside of the vehicle. For example, it generates information consisting of part or all of the information stored in the storage unit of the analysis device 1.

[0094] In step 408, the determination unit 19 is notified to output the information generated in step 404 or step 407 to the outside of the vehicle. This can be combined with... Figure 2 Step 209 similarly designs the output destination.

[0095] Based on the above processing, the analysis device 1 determines whether to output an anomaly notification based on the results of the judgment related to whether an anomaly has occurred in each vehicle-mounted device 3 and the code verification results of each vehicle-mounted device 3.

[0096] Furthermore, for example, scheduled information can be notified periodically when the operational burden and data communication costs of the central side are taken into account, and additional information can be flexibly notified according to requests from outside the vehicle in situations where an attack is determined to have occurred.

[0097] Therefore, the analysis device 1 can output abnormal notifications to the outside of the vehicle at the appropriate time based on the abnormal logs and real-time notification rules obtained from the on-board device.

[0098] More specifically, the analysis device 1 can determine that an attack has been carried out based on abnormal logs and symptomatic activities, and output abnormal notifications to the outside of the vehicle.

[0099] Furthermore, regardless of the code verification results, anomaly notifications can be output to the vehicle's external system based on the severity of the vehicle's situation. This allows for immediate output of anomaly notifications when an urgent anomaly log is detected.

[0100] Furthermore, according to Embodiment 1, it is possible to reduce the need for notifications when no attack has occurred, while also minimizing the likelihood of missing situations with a high probability of attack. Therefore, the burden when collaborating with centralized services such as SOCs can be made more manageable.

[0101] Furthermore, according to Example 1, code verification results can be generated through secure boot processing, thus effectively utilizing the results of secure boot processing.

[0102] Furthermore, according to a variation of Example 1 that omits step 306, the analysis device 1 decides not to output an anomaly notification if it determines that all vehicle-mounted devices 3 have not been tampered with. In this case, false detections of attacks based on anomaly logs can be suppressed.

[0103] In Example 1, Figure 2 and Figure 3 Taking the processing as an example, changes can be made as appropriate. For example, the criteria for determination in step 204 and step 302 can be changed arbitrarily. In addition, step 301 can be omitted, and step 302 can be always executed in step 206.

[0104] Furthermore, the form of the information used for the determination can be added, omitted, or changed as appropriate. For example, it can also be omitted. Figure 6A , Figure 7 , Figure 8B In this case, the victim device and the target device can be set as the same device. Symbol Explanation

[0105] 1…Analysis device, 3…Vehicle-mounted device (monitoring target device) All publications, patents, and patent applications cited in this specification are incorporated herein by reference.

Claims

1. An analysis apparatus configured to communicate with multiple monitored target devices, characterized in that, Collect the monitoring results of each of the monitored devices. Based on the monitoring results, it is determined whether any abnormality has occurred in the monitored devices. Based on the results of the judgment and the code verification results of each monitored device, a decision is made on whether to output an abnormal notification indicating an anomaly. Each of the aforementioned monitoring devices is mounted on a vehicle. The code verification result is determined through a secure boot process, which checks whether the program executed by the monitored device has been tampered with at the start of the program. If it is determined that there has been no tampering with any of the monitored devices, it is decided not to output the abnormal notification.

2. The analytical apparatus according to claim 1, characterized in that, If an anomaly and tampering are determined to have occurred within a specified period for any of the monitored devices, it is decided to output the anomaly notification.

3. The analytical apparatus according to claim 1, characterized in that, Then, the decision on whether to output the abnormality notification is based on the number of times any of the monitored devices experienced an abnormality within the specified period, or the number of times the same abnormality occurred within the specified period.

4. The analytical apparatus according to claim 1, characterized in that, Then, based on the content of the anomaly occurring in any of the monitored devices, it is determined whether to output the anomaly notification.

5. The analytical apparatus according to claim 2, characterized in that, The specified period is the operation period of the vehicle equipped with the monitoring device or the operation period of the analysis device.

6. The analytical apparatus according to claim 1, characterized in that, The anomaly notifications include cumulative notifications related to the number of anomalies that occurred and immediate notifications related to the content of the anomalies. The exception notification includes information indicating whether it is a cumulative notification or an instant notification.

Images