Analytical device

Abstract

To provide an analyzer that can properly output a notification of abnormalities by reducing false detection of attack events.SOLUTION: In an analyzer that can communicate with a monitoring target device, the analyzer collecting the result of monitoring of the monitoring target device, determining whether an abnormality happened in each monitoring target device on the basis of the results of monitoring, and determining whether to output the notification of abnormalities showing abnormalities on the basis of the results of the determination and the results of code verification of the monitor target device acquired before the determination.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to an analysis device, and more particularly to an analysis device that detects an abnormality based on the monitoring results of a monitored device mounted on a vehicle, and in particular to an analysis device that determines whether to output an abnormality notification to the outside of the vehicle. [Background technology]

[0002] Automotive Security Operation Centers (SOCs) are being considered to manage security during operation of vehicles after they are shipped. The SOC collects logs related to security events from the vehicle, and SOC operators and analysts use these logs to analyze the status of the vehicle and its impact on other vehicles, and then formulate and implement countermeasures. It is conceivable that the detection results of attack detection devices installed in the vehicle could be used as security events to be collected from the vehicle.

[0003] As the number of connected cars continues to increase, the number of vehicles monitored by SOCs will become larger. In such an environment, the more false positives an attack detection device makes, the greater the unnecessary workload for operators and analysts.

[0004] For this reason, attack detection technology is required to reduce false positives. As a technology for improving the accuracy of attack detection, Patent Document 1 discloses a technology for controlling the method of communication with the outside of the vehicle according to the depth of penetration of an unauthorized attack on an on-vehicle device. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Publication No. 2019-125344 Summary of the Invention [Problem to be solved by the invention]

[0006] However, the conventional technology has a problem in that it is not possible to output an abnormality notification appropriately.

[0007] The technology in Patent Document 1 is expected to increase the accuracy of an attack according to the depth of penetration of an unauthorized attack on an in-vehicle device, i.e., to reduce false positives. However, if another attack event is detected some time after the first detected attack event, it becomes difficult to determine whether it is a false positive or an attack. For example, there is no disclosure of a method for determining whether an attack event detected in a certain trip time (the period from when a vehicle starts to when it stops) and an attack event detected several or several tens of trip times later are actual attacks or false positives.

[0008] The present invention has been made in consideration of the above problems, and has an object to provide an analysis device that appropriately outputs an abnormality notification by reducing false positive detections of attack events. [Means for solving the problem]

[0009] An example of an analytical device according to the present invention is An analysis device configured to be able to communicate with a monitoring target device, The analysis device collecting monitoring results of the monitored devices; determining whether an abnormality has occurred in the monitored device based on the monitoring result; Based on the result of the determination and the code verification result of the monitored device acquired before the determination, it is determined whether or not to output an abnormality notification indicating an abnormality. [Effects of the Invention]

[0010] The analysis device according to the present invention can appropriately output anomaly notifications by reducing false positives of attack events. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram showing the configuration of an analysis device according to a first embodiment of the present invention. [Figure 2] FIG. 10 is a diagram showing an outline of a process flow for determining the timing of notification to the outside of the vehicle. [Figure 3] A diagram showing the detailed flow of step 206 in FIG. 2. [Figure 4] A diagram showing the outline of the processing flow for notification to the outside of the vehicle [Figure 5] FIG. 10 is a diagram showing an example of log information collected from an in-vehicle device. [Figure 6A] A diagram showing an example of an immediate notification rule based on an abnormal device. [Figure 6B] Diagram showing example of an instant notification rule based on log type [Figure 7] A diagram showing an example of the range of influence of an in-vehicle device [Figure 8A] FIG. 10 shows examples of whether or not each in-vehicle device is infringed. [Figure 8B] An example of vehicle-wide situation information [Figure 9] FIG. 10 is a diagram showing an example of the results of vehicle situation determination by the analysis device. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments of the present invention will be described in detail using examples with reference to the drawings. [Example]

[0013] The analysis device according to this embodiment executes a method for determining the timing of notification to the outside of the vehicle based on abnormality log information acquired from the in-vehicle device. However, the technical concept of the present invention is not limited to this embodiment. For example, the function of detecting an abnormality and the function of determining the timing of notification to the outside of the vehicle may be applied to the same device.

[0014] 1 shows the configuration of an analysis device 1 in this embodiment. The analysis device 1 is a device that is mounted on, for example, a vehicle 50 and analyzes information related to the vehicle 50. However, the analysis device 1 may not be mounted on the vehicle 50, and may be a device that analyzes information related to an object other than the vehicle 50.

[0015] The analysis device 1 is connected to an in-vehicle device 3 via a communication bus 2. The in-vehicle device 3 is a device mounted on a vehicle 50, and is a monitored device monitored by the analysis device 1 in this embodiment. The analysis device 1 is connected to a plurality of in-vehicle devices 3 so as to be able to communicate with each other.

[0016] The communication bus 2 may physically include multiple communication buses, and the communication buses may all be of the same standard or may be of different standards, such as CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), Ethernet (registered trademark), etc.

[0017] The analytical device 1 includes a calculation means (not shown) and a storage means (not shown). The calculation means includes, for example, a CPU. The storage means includes, for example, a ROM and a RAM. The calculation means executes a program stored in the storage means, causing the analytical device 1 to realize the functions described in this specification.

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

[0019] The storage means also includes a storage unit 100. The storage unit 100 may be entirely non-volatile, or partly volatile. The analyzer 1 also includes a communication unit 11, which is a communication interface and performs calculations necessary for communication.

[0020] The functional block diagram shown in Fig. 1 is an example, and the units and names of the functions are not limited to this. For example, the functions realized by the log analysis unit 13 in this embodiment may be realized by other functional units shown in Fig. 1 or may be realized by functional units not shown in Fig. 1.

[0021] The communication unit 11 receives messages from the in-vehicle devices 3 via the communication bus 2, and also transmits messages to the in-vehicle devices 3 via the communication bus 2. The analysis device 1 uses the communication unit 11 to collect information (for example, information that can be used to determine an abnormal state) from each in-vehicle device 3. Note that logs detected by the analysis device 1 itself, as well as the in-vehicle devices 3, may be collected and stored.

[0022] The log collection unit 12 stores information collected from the in-vehicle device 3 in vehicle log information 101. The log analysis unit 13 analyzes the information collected from the in-vehicle device 3 to determine whether or not there is information indicating an abnormality. The immediate notification applicability determination unit 14 determines whether or not the information indicating an abnormality complies with the immediate notification rule 102. The predictive activity determination unit 15 determines whether or not information indicating an abnormality has been registered in the vehicle situation information 104 for a predetermined period (for example, the latest completed trip time). The vehicle state update unit 16 updates the vehicle situation information 104 based on the information indicating an abnormality. The attack detection determination unit 17 determines whether or not an attack has been detected based on the vehicle situation information 104, and updates the situation determination result 105. The notification information generation unit 18 generates information to be notified to the outside of the vehicle 50. The notification determination unit 19 determines whether or not to notify the outside of the vehicle 50 based on the situation determination result 105. The instruction content analysis unit 20 analyzes the instruction content regarding notification control received from the outside of the analysis device 1. The notification timing control unit 21 notifies the outside of the vehicle 50 of information relating to the detected abnormality at a predetermined timing.

[0023] The storage unit 100 has the following functional units. Vehicle log information 101 that holds information acquired from the vehicle-mounted device 3. An immediate notification rule 102 for determining whether or not to immediately output information about a detected abnormality to the outside of the vehicle 50 . Inter-device impact information 103 indicating the mutual impact relationships between the on-board devices 3. For example, it indicates the relationship between the on-board device 3 involved in the abnormality and other on-board devices 3 that may be targets of attack. Vehicle situation information 104 that stores whether or not there is an intrusion and the intrusion status of each vehicle-mounted device 3. - A situation assessment result 105 indicating the state of the vehicle 50 based on the vehicle situation information 104.

[0024] 1 is an example, and the units and names of the functions of the storage unit 100 are not limited to this. For example, the information stored in the vehicle log information 101 in this embodiment may be stored by another functional unit shown in the storage unit 100 in FIG. 1, or may be stored by a functional unit not shown in the storage unit 100 in FIG. 1.

[0025] 2 is a flowchart showing the process performed by the analysis device 1 when determining the timing to notify the outside of the vehicle 50 of an abnormality. Each step described below is executed by, for example, a CPU (not shown) of the analysis device 1.

[0026] In step 201, the log collection unit 12 collects monitoring results from each in-vehicle device 3 using the communication unit 11 and stores them in the vehicle log information 101 of the analysis device 1. The monitoring results are collected, for example, as log information. For example, the analysis device 1 may collect log information periodically after startup, or at a timing arbitrarily set in advance, or may receive log information transmitted from each in-vehicle device 3 at a timing determined by the in-vehicle device 3. The log collection unit 12 may also collect logs for a predetermined period. This predetermined period may include multiple trip times (or a portion thereof), for example, it may span multiple trip times. In the case where multiple trip times are spanned, when the first log is acquired from each in-vehicle device 3 after startup of the vehicle 50 or the analysis device 1, if the code verification result indicates that no program tampering has occurred (or if no tampering has occurred), the previously collected log (e.g., an abnormality log) may be erased. Alternatively, even if the trip time is crossed, the previous log may be left as it is regardless of the code verification result, and the log may be deleted after being notified to the outside of the vehicle 50.

[0027] 5 shows an example of vehicle log information 101 that holds the log information collected in step 201. Each log included in the vehicle log information 101 is configured for each in-vehicle device. The logs include an abnormality log (a log indicating that an abnormality has occurred), and the abnormality log includes the following information: - Abnormality ID 1011, an identifier assigned to each type of abnormality log. - Anomaly content 1012, which is text data showing the content of the error log. An abnormality location 1013 indicating the location where the abnormality occurred in the in-vehicle device 3. - Time 1014 indicating the time when the abnormality was detected. This time 1014 indicates whether the log is included in any of the operation periods of the analysis device 1 or whether the log is included in any of the operation periods of the vehicle 50. Note that the operation period of the analysis device 1 may be, for example, the period from when the analysis device 1 starts to when it stops, and the operation period of the vehicle 50 may be, for example, the period from when the vehicle 50 starts to when it stops.

[0028] Prior to step 201, each in-vehicle device 3 can generate a log based on publicly known technology, etc. For example, if there is access from a terminal that is not registered as an external device via communication channel Ch1 monitored by in-vehicle device A, in-vehicle device A registers in the log the abnormality content 1012 "unregistered terminal access," the abnormality ID of the abnormality "0x001," the abnormality location 1013 "Ch1," and the detection time "2020 / 02 / 01 11:10:20." This log is collected in step 201.

[0029] In step 202, the log analysis unit 13 extracts an abnormality log by determining whether the vehicle log information 101 stored in step 201 includes an abnormality log. That is, the log analysis unit 13 determines whether an abnormality has occurred in each on-board device 3 based on the monitoring results of the on-board devices 3. In this embodiment, only the abnormality log is stored, but other log information may also be stored, in which case an identifier for identifying the abnormality log may be provided. This determination can be made, for example, based on the abnormality ID 1011. The log information may also include a code verification result. For example, the code verification result may include information indicating that tampering has occurred, that tampering has not occurred, or the like.

[0030] In step 203, if an error log is found to be included in step 202, the process proceeds to step 204. On the other hand, if an error log is not found, the process flow ends. After the process ends, the process may proceed to step 201 at a predetermined timing. As a modified example, the process may proceed to step 204 even if a log showing the code verification result is included. In that case, the process may proceed to step 204 if it is determined that no tampering has occurred as a result of the code verification.

[0031] In step 204, the immediate notification determining unit 14 determines, based on the immediate notification rule 102, whether or not the abnormality logs included in the vehicle log information 101 include an abnormality log that should be immediately notified to the outside of the vehicle 50.

[0032] 6A shows an example of the immediate notification rule 102 referred to by the immediate notification applicability determination unit 14 in step 204. This example is based on the abnormal device 1021. For example, if the in-vehicle device 3 related to the abnormality log corresponds to the abnormal device 1021 in the immediate notification rule 102, the immediate notification applicability determination unit 14 determines to output an immediate notification for the abnormality log. An immediate notification is a type of notification indicating an abnormality (abnormality notification). Determining to output an immediate notification for a certain abnormality log corresponds to deciding to output an abnormality notification for that abnormality log.

[0033] In the example of Fig. 6A, it is determined that an immediate notification is to be output for the abnormality log related to the in-vehicle device I. Furthermore, if an abnormality log related to the in-vehicle device G and an abnormality log related to the in-vehicle device H exist at the same time or within a predetermined time period, it is determined that an immediate notification is to be output for those abnormality logs.

[0034] 6A, the immediate notification appropriateness determining unit 14 can determine whether to output an abnormality notification based on the details of an abnormality (for example, a single abnormality) that has occurred in one of the in-vehicle devices 3 (example of in-vehicle device I). In this way, it is possible to reliably output an abnormality notification when a serious abnormality has occurred.

[0035] The immediate notification rule 102 may also include a condition that an abnormality log corresponding to the abnormal device 1021 occurs multiple times. For example, the immediate notification applicability determination unit 14 may further determine to output an immediate notification based on the number of times an abnormality occurs in any of the in-vehicle devices 3 within a predetermined period. For example, if multiple abnormality logs related to the same in-vehicle device 3 exist within a predetermined period, these abnormality logs may be determined to be subject to immediate notification. In this way, frequent abnormalities will not be overlooked.

[0036] 6B shows another example of the immediate notification rule 102 referenced by the immediate notification applicability determination unit 14 in step 204. This example is based on the type of abnormality log. For example, in step 204, the immediate notification applicability determination unit 14 determines that an immediate notification should be output if the abnormality ID 1011 corresponds to the immediate notification target abnormality ID 1022.

[0037] In the example of FIG. 6B, the immediate notification applicability determination unit 14 can determine whether to output an abnormality notification based on the content of a single abnormality that has occurred in any of the in-vehicle devices 3. However, as a modified example, the immediate notification rule 102 may include a condition that an abnormality log corresponding to the immediate notification target abnormality ID 1022 occurs multiple times. For example, the immediate notification applicability determination unit 14 may further determine to output an immediate notification based on the number of times the same abnormality has occurred within a predetermined period. For example, if multiple abnormality logs related to the same abnormality ID exist within a predetermined period, these abnormality logs may be determined to be subject to immediate notification. In this way, frequent abnormalities will not be overlooked.

[0038] 6A and 6B, either one of them may be used for the determination, or both may be used for the determination. When both are used, it may be determined that an immediate notification is to be output for an abnormality log that corresponds to either one of them, or it may be determined that an immediate notification is to be output only for an abnormality log that corresponds to both of them.

[0039] In step 205, if the immediate notification appropriateness determining unit 14 determines in step 204 that the immediate notification is to be output, the process proceeds to step 208;

[0040] In step 206, the attack detection / determination unit 17 determines whether or not an attack has occurred in the abnormality log extracted in step 202 based on the vehicle situation information 104, which will be described later, and determines whether or not to notify the outside of the vehicle. Details of this determination will be described later with reference to FIG. 3 etc.

[0041] In step 207, the attack detection determination unit 17 determines whether or not to output an abnormality notification based on the situation determination result 105 (described later in relation to FIG. 9, etc.). Note that the situation determination result 105 is generated based on whether or not an abnormality has occurred in each in-vehicle device 3 (step 203 described above) and the code verification result of each in-vehicle device 3 (step 302 described later). Therefore, it can be said that the attack detection determination unit 17 determines whether or not to output an abnormality notification based on the result of the determination as to whether or not an abnormality has occurred in each in-vehicle device 3 and the code verification result of each in-vehicle device 3.

[0042] Here, the attack detection determination unit 17's decision to output an abnormality notification corresponds to determining that either the vehicle 50 or the in-vehicle device 3 is under attack. Also, the attack detection determination unit 17's decision not to output an abnormality notification corresponds to determining that neither the vehicle 50 nor the in-vehicle device 3 is under attack, or to determining that there is a possibility that the vehicle 50 or the in-vehicle device 3 is under attack but that continued monitoring should be performed as a wait-and-see approach.

[0043] For example, if the situation judgment ID 1051 (described later in relation to FIG. 9 etc.) of the situation judgment result 105 is "0x00" or "0x01", it is determined not to output an abnormality notification, and if it is "0x10" or "0x11", it is determined to output an abnormality notification. The content of the abnormality notification to be output can be, for example, the above-mentioned immediate notification or the below-described cumulative notification.

[0044] If it is determined that an abnormality notification should be output, the process proceeds to step 208, and if it is determined that an abnormality notification should not be output, the process flow ends.

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

[0046] In step 209, the notification determination unit 19 outputs the abnormality notification generated in step 208 to the outside of the vehicle 50. The output destination may be a device outside the vehicle 50, in which case communication may be via one of the in-vehicle devices 3. The output destination may also be a device mounted on the vehicle 50, and for example, a lamp mounted on the vehicle 50 may be turned on so that the detection of an attack can be recognized from outside the vehicle 50.

[0047] In step 210, the analysis device 1 transitions to a response mode for taking security measures for the vehicle 50 based on the situation assessment result 105. The specific content of the operation in the response mode can be appropriately designed by a person skilled in the art based on publicly known technology, etc. Note that step 210 may be omitted.

[0048] By performing the above steps, the analysis device 1 can notify the outside of the vehicle of an abnormality at an appropriate timing when an attack is detected.

[0049] 3 is a detailed flowchart of the processing in step 206. Each step described below is executed by, for example, a CPU (not shown) of the analysis device 1. The processing in FIG. 3 is executed for each abnormality log, except for, for example, step 307, and step 307 is executed in response to the execution of the processing in FIG. 2.

[0050] In step 301, the predictive activity determination unit 15 determines whether or not predictive activity of an attack has been recorded by referring to the vehicle situation information 104. A specific example of the processing in step 301 will be described below with reference to Figures 7, 8A, and 8B.

[0051] FIG. 7 shows an example of inter-device impact information 103 that associates an on-board device 3 related to an abnormality log (victim device 1031) with an on-board device 3 (impacted device 1032) that is affected by the abnormality.

[0052] The affected device 1032 is related to the victim device 1031 in which an abnormality is occurring, and may be affected by an attack. The monitored group ID 1033 is identification information that identifies a group consisting of the victim device 1031 and the affected device 1032.

[0053] For example, for the abnormality log with abnormality ID 1011 of "0x002" shown in Figure 5, the predictive activity determination unit 15 identifies the on-board device "on-board device A" in which the abnormality ID is registered as the victim device, and identifies the affected device 1032 "on-board device D" corresponding to on-board device A in the victim device 1031 of the inter-device impact information 103.

[0054] 8A shows an example of vehicle situation information 104 in which predictive activity is recorded. The vehicle situation information 104 includes an on-board device ID 1041 that identifies the on-board device 3 installed in the vehicle 50, and an intrusion status 1042 that indicates whether or not the on-board device has been intruded into.

[0055] 8A can be generated prior to the execution of step 301. For example, a "1" can be recorded for an on-board device 3 in which an abnormality has occurred within a predetermined period (situation information recording period), and a "0" can be recorded for an on-board device 3 in which no abnormality has occurred.

[0056] Since the occurrence of an abnormality suggests the possibility of precursory activity to an attack, information indicating whether an abnormality occurred within the situation information recording period can also be said to be information indicating whether precursory activity to an attack occurred for each vehicle-mounted device 3.

[0057] The start and end points of the situation information recording period can be arbitrarily designed, but may be, for example, the operating period of the vehicle 50 (for example, the period from when the vehicle 50 starts to when it stops) or the operating period of the analysis device 1 (for example, the period from when the analysis device 1 starts to when it stops). In this way, the recording of the abnormality log can be aligned with the operating period of the analysis device 1 or the vehicle 50, allowing for more appropriate determination.

[0058] Furthermore, this situation information recording period may be a period determined based on a specific event signal, or may be a period based on a predetermined time.

[0059] The vehicle situation information 104 can be designed to be updated at any time. For example, it may be updated when a situation information recording period ends. For example, if the vehicle situation information 104 holds information about a first situation information recording period, when a second situation information recording period ends, the vehicle situation information 104 may be updated to content corresponding to the second situation information recording period. The situation assessment result 105 can be initialized at any time. For example, when the trip time changes (i.e., when the previous trip time ends and a new trip time begins), the situation assessment result 105 may be maintained, or may be initialized, i.e., set to “0x00.” The situation assessment result 105 may be initialized when a predetermined procedure is performed from outside the vehicle 50 (e.g., when a SOC confirms that there is no problem, a problematic program is corrected, etc.). Alternatively, the situation assessment result 105 may be initialized when logs indicating no tampering are collected as a code verification result from all on-board devices 3 or a relevant on-board device 3.

[0060] In step 301, for example, for an abnormality log in which the abnormality ID 1011 shown in Fig. 5 is "0x002", the predictive activity determination unit 15 first determines whether or not there has been any predictive activity in the in-vehicle device related to the abnormality log (in-vehicle device A in this case). For example, if the value of the intrusion presence / absence 1042 corresponding to in-vehicle device A is "1", it is determined that there has been any predictive activity, and if the value is "0", it is determined that there has been no predictive activity. In this example, the value of the intrusion presence / absence 1042 corresponding to the in-vehicle device ID 1041 of "in-vehicle device A" is "0", so it is determined that there has been no predictive activity for in-vehicle device A.

[0061] Next, the predictive activity determination unit 15 identifies the affected device as the in-vehicle device D based on the inter-device impact information 103 as described above, and determines whether or not there has been predictive activity in the in-vehicle device D. For example, if the value of the intrusion presence / absence 1042 corresponding to the in-vehicle device D is "1", it is determined that there has been predictive activity, and if the value is "0", it is determined that there has been no predictive activity. In this example, the value of the intrusion presence / absence 1042 corresponding to the in-vehicle device ID 1041, which is "in-vehicle device D", is "1", so it is determined that there has been predictive activity for the in-vehicle device D.

[0062] 7, for example, for an abnormality log related to on-board device C, when the victim device 1031 is on-board device C, a group including on-board device D and on-board device E and a group including only on-board device F are associated as affected devices 1032. Therefore, for an abnormality log related to on-board device C, if either or both of the intrusion presence / absence 1042 corresponding to on-board device D and the intrusion presence / absence 1042 corresponding to on-board device E are "1", it is determined that predictive activity has occurred for on-board device D or on-board device E, or for both, and if both are "0", it is determined that no predictive activity has occurred for on-board device D or on-board device E. Furthermore, when the intrusion presence / absence 1042 corresponding to on-board device F is "1", it is determined that predictive activity has occurred for on-board device F, and if it is "0", it is determined that no predictive activity has occurred for on-board device F.

[0063] The predictive activity determination unit 15 may determine the presence or absence of predictive activity for all abnormality logs as described above. Alternatively, the predictive activity determination unit 15 may identify the victim device in which an abnormality is occurring based on the abnormality log extracted from the vehicle log information 101 in step 202, identify the impact range of the victim device using the inter-device impact information 103, and refer to the intrusion presence / absence 1042 for the victim in-vehicle device and the in-vehicle devices included in the impact range to determine the presence or absence of a predictive attack.

[0064] As a result of the determination in step 301, if it is determined that predictive activity has occurred in any of the in-vehicle devices, the process proceeds to step 302; if it is determined that predictive activity has not occurred, the process proceeds to step 303.

[0065] In step 302, the attack detection / determination unit 17 refers to the code verification result. For example, the code verification result of the in-vehicle device 3 for which it is determined in step 301 that predictive activity has occurred is referenced. Although a specific example of the code verification result is not particularly illustrated, it indicates, for example, whether or not tampering has occurred in a program executed by the in-vehicle device 3, and can be generated based on publicly known technology. Note that if the log acquired in step 201 above is a log indicating the code verification result of the in-vehicle device 3 (e.g., whether or not tampering has occurred), it may be determined in step 302 whether or not the content of the log indicates that tampering has occurred. For example, the analysis device 1 may collect the code verification result (whether or not tampering has occurred) of each in-vehicle device 3 from each in-vehicle device 3 in step 201 above when the vehicle 50 is started (or when the analysis device 1 is started), and determine the code verification result in step 302.

[0066] The code verification result is generated, for example, by a secure boot process. The secure boot process is a process for determining whether or not a program executed by the in-vehicle device 3 has been tampered with before the execution of the program starts. Note that the code verification result is not limited to that generated by the secure boot process, and may be the result of verification executed at any timing after the execution of the program starts.

[0067] If it is determined that the program executed by the vehicle-mounted device 3 in which predictive activity has occurred has been tampered with, the process proceeds to step 304. If not, the process proceeds to step 305.

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

[0069] Figure 8B shows an example of vehicle situation information 104 updated in step 303. In this embodiment, vehicle situation information 104 includes both the information shown in Figure 8A and the information shown in Figure 8B, but these pieces of information may be included in different areas (for example, different databases, RAM, data flash).

[0070] The vehicle situation information 104 shown in FIG. 8B includes the following information: - A monitored group ID 1043 that identifies a group of devices that are related to each other. - Associated devices 1044 indicating the in-vehicle devices included in each group. The relationships between the devices included in each group may correspond to the inter-device impact information 103 in Fig. 7. In this embodiment, the relationships shown in Fig. 8B correspond to the relationships shown in Fig. 7, but in modified examples, these do not need to correspond. - Infringement status 1045 indicating the infringement status of each on-board device. A threshold value 1046 indicating a threshold value used when determining whether or not to output an abnormality notification based on the infringement status 1045.

[0071] The vehicle state update unit 16 updates the intrusion presence / absence 1042 corresponding to the in-vehicle device related to the abnormality log (for example, in-vehicle device A) from "0" to "1." For example, for the abnormality log related to in-vehicle device A, the ID {0x01} of the group in which the in-vehicle device A is the victim device 1031 is obtained from the monitored group ID 1033 in Figure 7, and if the intrusion situation 1045 of the corresponding group in Figure 8B (which is {1, 1} in the example of Figure 8B) is {0, 0}, it updates it to {1, 0}.

[0072] In step 306, the attack detection determination unit 17 compares the intrusion situation 1045 in the vehicle situation information 104 with the threshold value 1046. For example, for each group, the sum of the numbers included in the intrusion situation 1045 is compared with the threshold value. If the sum exceeds the threshold value, it is determined that a cumulative notification should be output. A cumulative notification is a type of abnormality notification. If the sum does not exceed the threshold value, it is determined that no abnormality notification should be output.

[0073] As a modified example, the determination in step 306 may be omitted, in which case it may be decided not to output an abnormality notification (similar to when the sum does not exceed the threshold value).

[0074] In step 307, the vehicle state update unit 16 updates the situation assessment result 105 according to the result of step 303, 304 or 306.

[0075] 9 shows an example of the situation determination result 105. The situation determination result 105 includes a situation determination ID 1051 that identifies the situation of the vehicle, and a status 1052 that indicates the content of the situation of the vehicle.

[0076] For example, in the initial state (for example, a state in which no abnormality logs are recorded), the situation judgment ID 1051 is "0x00" and the status 1052 is "normal."

[0077] If step 303 has been executed before step 307, the situation judgment ID 1051 will be "0x01" and the status 1052 will be "continuous monitoring."

[0078] If step 304 has been executed before step 307, the situation judgment ID 1051 will be "0x11" and the status 1052 will be "immediate notification."

[0079] If step 306 is executed before step 307 and the threshold is exceeded, the situation determination ID 1051 becomes "0x10" and the status 1052 becomes "cumulative notification." If step 306 is executed before step 307 and the threshold is not exceeded, the situation determination ID 1051 becomes "0x01" and the status 1052 becomes "continuous monitoring."

[0080] If the results for multiple error logs are different, the largest value among the results will take precedence as the situation determination ID 1051. For example, if one error log is determined to be "continuous monitoring" (the situation determination ID 1051 is "0x01") and another error log is determined to be "immediate notification" (the situation determination ID 1051 is "0x11"), the resulting situation determination ID 1051 will be "0x11".

[0081] As shown in FIG. 9, in this embodiment, the abnormality notification includes a cumulative notification relating to the number of times an abnormality has occurred and an immediate notification relating to the content of the abnormality that has occurred.

[0082] The abnormality notification may include information indicating whether the abnormality notification is a cumulative notification or an immediate notification, which allows the content of the abnormality to be output in more detail.

[0083] Through the above processing, the analysis device 1 can determine whether to output an abnormality notification to the outside of the vehicle. If it is determined that an abnormality notification should be output, the notification can be sent to the outside of the vehicle at an appropriate timing to lead to early action.

[0084] 3, the analysis device 1 determines to output an abnormality notification when it determines that predictive activity has occurred (i.e., an abnormality has occurred within a predetermined period) and that tampering has occurred for any of the on-board devices 3. This allows for more appropriate determination based on past predictive activity and the latest code verification results.

[0085] 4 is a flowchart showing an example of a process in which the analysis device 1 outputs information about the on-board device to the outside of the vehicle. In addition to or instead of step 209 shown in FIG. 2, the analysis device 1 may output an abnormality notification by the process shown in FIG. 4.

[0086] 4 particularly describes a case where the report is output as a regular report and a case where the report is output in accordance with an instruction from outside the vehicle. Each step described below is executed, for example, by a CPU (not shown) of the analysis device 1. This processing flow is executed, for example, when the vehicle 50 is started. This processing flow may be executed at a predetermined timing, may be executed periodically and repeatedly, or may be executed after an abnormality is notified.

[0087] In step 401, the instruction content analysis unit 20 checks whether a notification instruction has been received from outside the vehicle, and if a notification instruction has been received, proceeds to step 402, and if a notification instruction has not been received, proceeds to step 405.

[0088] In step 402, the instruction content analysis unit 20 analyzes 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 to be additionally collected from other in-vehicle devices, a specification for other information held in the vehicle, etc. 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 generating unit 18 collects necessary information from the analysis device 1 or the in-vehicle device 3 based on the content analyzed in step 402 above.

[0090] In step 404, the notification information generating unit 18 generates information to be output to the outside of the vehicle from the information collected in step 403 above.

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

[0092] In step 406, if notification timing control unit 21 determines that the current time is the predetermined timing based on the check result in step 405, it proceeds to step 407, otherwise it ends this processing flow.

[0093] In step 407, the notification information generating unit 18 generates standard data to be output to the outside of the vehicle. For example, the notification information generating unit 18 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 notification determination unit 19 outputs the information generated in step 404 or step 407 to the outside of the vehicle. The output destination can be designed in the same way as step 209 in FIG.

[0095] According to the above process, the analysis device 1 determines whether to output an abnormality notification based on the result of the determination as to whether an abnormality has occurred in each in-vehicle device 3 and the code verification result of each in-vehicle device 3.

[0096] In addition, for example, it is possible to notify specified information periodically at a timing that takes into account the operational load and data communication costs on the center side, and in situations where it is determined that an attack has occurred, it is possible to flexibly notify additional information in accordance with requests and instructions from outside the vehicle.

[0097] Therefore, the analysis device 1 can output an abnormality notification to the outside of the vehicle at an appropriate timing based on the abnormality log acquired from the in-vehicle device and the immediate notification rule.

[0098] More specifically, the analysis device 1 can determine that an attack is occurring based on the abnormality log and predictive activity, and output an abnormality notification to the outside of the vehicle.

[0099] Regardless of the code verification results, an abnormality notification can be output to the outside of the vehicle based on the degree of infringement of the vehicle's condition. This allows for immediate output of an abnormality notification if an abnormality log requiring urgent action is detected.

[0100] Furthermore, according to the first embodiment, it is possible to reduce the number of cases where notifications are sent when there is no attack, while at the same time making it difficult to overlook cases where there is a high possibility of an attack. This makes it possible to optimize the load when cooperating with a center service such as a SOC.

[0101] Furthermore, according to the first embodiment, the code verification result can be generated by the secure boot process, so that the result of the secure boot process can be effectively utilized.

[0102] Furthermore, according to a modification in which step 306 of the first embodiment is omitted, the analysis device 1 decides not to output an abnormality notification if it is determined that no tampering has occurred in any of the in-vehicle devices 3. In this case, it is possible to suppress false detection of attacks based on abnormality logs.

[0103] 2 and 3 in the first embodiment are merely examples and can be modified as appropriate. For example, the criteria for determination in step 204, the criteria for determination in step 302, etc. can be changed as desired. Also, for example, step 301 may be omitted, and step 302 may always be executed in step 206.

[0104] The format of the information used for the determination can be added, omitted, or changed as appropriate. For example, the information in Figures 6A, 7, and 8B may be omitted, in which case the victim device and the affected device may be the same device. [Explanation of symbols]

[0105] 1...Analysis device, 3...In-vehicle device (monitored device)

Claims

1. An analysis device configured to be able to communicate with a monitoring target device, The analysis device collecting monitoring results of the monitored devices; determining whether an abnormality has occurred in the monitored device based on the monitoring result; determining whether to output an abnormality notification indicating an abnormality based on the result of the determination and a code verification result of the monitoring target device acquired before the determination; the code verification result is determined by a secure boot process that determines whether or not a program executed by the monitoring target device has been tampered with when the program starts to be executed; the analysis device determines to output the abnormality notification when it is determined that an abnormality has occurred within a predetermined period of time and that tampering has occurred in any of the monitoring target devices; Analyzer.

2. An analysis device configured to be able to communicate with a monitoring target device, The analysis device collecting monitoring results of the monitored devices; determining whether an abnormality has occurred in the monitored device based on the monitoring result; determining whether to output an abnormality notification indicating an abnormality based on the result of the determination and a code verification result of the monitoring target device acquired before the determination; the code verification result is determined by a secure boot process that determines whether or not a program executed by the monitoring target device has been tampered with when the program starts to be executed; the analysis device determines not to output the abnormality notification when it is determined that no tampering has occurred with any of the monitoring target devices; Analyzer.

3. The analytical device according to claim 1 or 2, The monitored device is mounted on a vehicle. Analyzer.

4. The analytical device according to claim 1 or 2, The analysis device further determines whether to output the abnormality notification based on the number of times an abnormality has occurred in any of the monitored devices within a predetermined period or the number of times the same abnormality has occurred within a predetermined period. Analyzer.

5. The analytical device according to claim 1 or 2, The analysis device further determines whether to output the abnormality notification based on the content of the abnormality that has occurred in any of the monitored devices. Analyzer.

6. The analytical device according to claim 1 , the predetermined period is an operation period of a vehicle in which the monitored device is mounted or an operation period of the analysis device; Analyzer.

7. The analytical device according to claim 1 or 2, The abnormality notification includes a cumulative notification regarding the number of times an abnormality has occurred and an immediate notification regarding the content of the abnormality that has occurred, The abnormality notification includes information indicating whether the abnormality notification is the cumulative notification or the immediate notification. Analyzer.

8. The analytical device according to claim 1 or 2, When the code verification result spans multiple trip times, If there is no tampering with the program executed by the monitored device, Clearing the previous code verification result and / or notifying the code verification result to an external device of the vehicle; Analyzer.

Images