Analyzer

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, more specifically, to an analysis device that detects an abnormality based on a monitoring result of a monitored device mounted in a vehicle, and in particular, to an analysis device that determines whether or not to output an abnormality notification to the outside of the vehicle. [Background technology]

[0002] Security Operation Centers (SOCs) for automobiles are being considered to manage security during operation after a vehicle is shipped. In the SOC, logs related to security events are collected from the vehicle, and SOC operators and analysts analyze the status of the vehicle and its impact on other vehicles based on the logs, and 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 gives, the greater the unnecessary workload for operators and analysts.

[0004] For this reason, there is a demand for attack detection technology that reduces false positives. As a technology for improving the accuracy of attack detection, Patent Document 1 discloses a technology for controlling a communication method to the outside of a 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] JP 2019-125344 A 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] According to the technology of Patent Document 1, it is expected that the accuracy of an attack will be increased according to the depth of penetration of an unauthorized attack on an in-vehicle device, that is, false positives will be reduced. However, if another attack event is detected some time after the first attack event is detected, it is 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 during the period from when the vehicle starts to when it stops and an attack event detected in 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 anomaly notification by reducing false positives 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 comprises: 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. Effect 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 description of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram showing a configuration of an analysis device according to a first embodiment of the present invention. [Diagram 2] FIG. 13 is a diagram showing an outline of a process flow for determining the timing of notification to the outside of the vehicle. [Diagram 3] FIG. 2 shows a detailed flow of step 206 in FIG. 2. [Figure 4] A diagram showing the outline of the process flow for notifying the outside of the vehicle [Diagram 5] FIG. 13 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 Instant Notification rule based on log type [Figure 7] FIG. 1 shows an example of the range of influence of an in-vehicle device. [Figure 8A] FIG. 13 shows an example of whether each in-vehicle device is infringed. [Figure 8B] A diagram showing an example of situation information for the entire vehicle [Figure 9] FIG. 13 is a diagram showing an example of a result of a vehicle situation determination performed by an analysis device; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0014] 1 shows the configuration of an analysis device 1 in this embodiment. The analysis device 1 is, for example, a device mounted on 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 standards of each communication bus may be the same or different, such as CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), Ethernet (registered trademark), etc.

[0017] The analysis 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, whereby the analysis device 1 realizes 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 includes a storage unit 100. The storage unit 100 may be entirely non-volatile, or may be partially volatile. The analysis device 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 those shown. 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 transmits messages to the in-vehicle devices 3 via the communication bus 2. The analysis device 1 collects information (e.g., information that can determine an abnormal state) from each in-vehicle device 3 using the communication unit 11. Note that logs detected not only by the in-vehicle devices 3 but also by the analysis device 1 itself may be collected and stored.

[0022] The log collection unit 12 stores the information collected from the vehicle-mounted device 3 in the vehicle log information 101. The log analysis unit 13 analyzes the presence or absence of information indicating an abnormality in the information collected from the vehicle-mounted device 3. The immediate notification applicable / invalidation determination unit 14 determines whether the information indicating an abnormality corresponds to the immediate notification rule 102. The predictive activity determination unit 15 determines whether information indicating an abnormality is registered in the vehicle situation information 104 during 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 the attack detection is confirmed 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 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 the notification control received from the outside of the analysis device 1. The notification timing control unit 21 notifies information relating to the detected abnormality to the outside of the vehicle 50 based on a predetermined timing.

[0023] The storage unit 100 has the following functional units. Vehicle log information 101 that holds information obtained from the vehicle-mounted device 3 . An immediate notification rule 102 for determining whether or not to immediately output a detected abnormality to the outside of the vehicle 50 . Inter-device impact information 103 indicating the 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 attacks. Vehicle situation information 104 that holds the presence or absence of an intrusion and the intrusion status of each vehicle-mounted device 3 . - A situation judgment result 105 indicating the state of the vehicle 50 based on the vehicle situation information 104.

[0024] Similarly, the functional block diagram of the storage unit 100 shown in Fig. 1 is merely an example, and the units and names of the functions are not limited thereto. For example, the information held by the vehicle log information 101 in this embodiment may be held by another functional unit shown in the storage unit 100 in Fig. 1, or may be held by a functional unit not shown in the storage unit 100 in Fig. 1.

[0025] 2 is a flowchart showing a 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 the monitoring results of 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 the log information periodically after startup, or may collect the log information at a timing arbitrarily set in advance, or may receive the log information transmitted from the in-vehicle device 3 at a timing determined by each in-vehicle device 3. The log collection unit 12 may also collect logs for a determined period of time. This determined period may include multiple trip times (or a part of them), for example, may span multiple trip times. In the case where multiple trip times are spanned, when the code verification result indicates that no program tampering has occurred (or does not indicate that tampering has occurred) when first acquiring logs from each in-vehicle device 3 after startup of the vehicle 50 or the analysis device 1, the previously collected log (for example, an abnormality log) may be erased. Alternatively, even if the trip time has elapsed, 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. - Abnormality contents 1012, which is text data showing the contents of the abnormality 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 is started to when it is stopped, and the operation period of the vehicle 50 may be, for example, the period from when the vehicle 50 is started to when it is stopped.

[0028] Prior to step 201, each in-vehicle device 3 can generate a log based on publicly known technology, etc. For example, when an access is made from a terminal not registered as an external device via a communication channel Ch1 monitored by the in-vehicle device A, the 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 or not the vehicle log information 101 stored in step 201 includes an abnormality log. That is, the log analysis unit 13 determines whether or not an abnormality has occurred in each vehicle-mounted device 3 based on the monitoring result of the vehicle-mounted device 3. In this embodiment, only the abnormality log is stored, but other log information may 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 it has been determined that tampering has occurred, that it has been determined that no tampering has 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 notified to the outside of the vehicle 50 immediately.

[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, when the in-vehicle device 3 related to the abnormal 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 abnormal 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. Also, when 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, 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 or not to output an abnormality notification based on the details of an abnormality (for example, a single abnormality) that has occurred in any 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 occurs.

[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 appropriateness determining 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, when 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 referred to by the immediate notification applicability determination unit 14 in the above step 204. This example is based on the type of abnormality log. For example, in the above step 204, the immediate notification applicability determination unit 14 determines to output an immediate notification when the abnormality ID 1011 corresponds to the immediate notification target abnormality ID 1022.

[0037] In the example of FIG. 6B, the immediate notification appropriateness determining unit 14 can determine whether or not 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 appropriateness determining 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, when multiple abnormality logs related to a certain same abnormality ID exist within a predetermined period, these abnormality logs may be determined to be the object of immediate notification. In this way, frequent abnormalities will not be overlooked.

[0038] The rule shown in Fig. 6A and the rule shown in Fig. 6B may be used for the judgment using either one of them, or both of them. When using both of them, it may be determined that an immediate notification is to be output for an abnormality log corresponding to either one of them, or it may be determined that an immediate notification is to be output only for an abnormality log corresponding to both of them.

[0039] In step 205 , if the immediate notification appropriateness determining unit 14 determines in step 204 above that the immediate notification is to be output, the process proceeds to step 208 , and if it determines that the immediate notification is not to be output, the process proceeds to step 206 .

[0040] In step 206, the attack detection and determination unit 17 determines whether or not an attack has occurred for the abnormality log extracted in step 202 based on the vehicle situation information 104 described below, 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 and 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 vehicle-mounted device 3 (step 203 described above) and the code verification result of each vehicle-mounted device 3 (step 302 described later), so it can be said that the attack detection and 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 vehicle-mounted device 3 and the code verification result of each vehicle-mounted device 3.

[0042] Here, the decision by the attack detection determination unit 17 to output an abnormality notification corresponds to a determination that either the vehicle 50 or the in-vehicle device 3 is under attack. Also, the decision by the attack detection determination unit 17 not to output an abnormality notification corresponds to a determination that neither the vehicle 50 nor the in-vehicle device 3 is under attack, or corresponds to a determination that although there is a possibility that the vehicle 50 or the in-vehicle device 3 is under attack, it should be continued to be monitored 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 output abnormality notification can be, for example, the above-mentioned immediate notification or the below-mentioned accumulated notification.

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

[0045] In step 208, the notification information generating 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 any 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 the 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 contents of the operation in the response mode can be appropriately designed by a person skilled in the art based on known techniques, 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] Fig. 3 is a detailed flowchart of the process in step 206. Each step described below is executed, for example, by a CPU (not shown) of the analysis device 1. The process in Fig. 3 is executed for each abnormality log, except for step 307, and step 307 is executed in response to the execution of the process 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 effect information 103 that associates an on-board device 3 related to an abnormality log (victim device 1031) with an on-board device 3 (affected 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. In addition, 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 an abnormality log with abnormality ID 1011 of "0x002" shown in Figure 5, the predictive activity determination unit 15 identifies the in-vehicle device "in-vehicle device A" in which the abnormality ID is registered as the victim device, and identifies the affected device 1032 "in-vehicle device D" corresponding to in-vehicle 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 mounted on the vehicle 50, and an intrusion status 1042 that indicates whether or not the on-board device has been intruded.

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

[0056] Since the occurrence of an abnormality indicates the possibility of a precursor activity to an attack, information indicating whether or not an abnormality has occurred within the situation information recording period can also be said to be information indicating whether or not there has been a precursor activity to an attack 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 operation period of the vehicle 50 (for example, the period from when the vehicle 50 starts to when it stops) or the operation 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 operation period of the analysis device 1 or the vehicle 50, allowing for more appropriate judgment.

[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 timing. For example, it may be updated in response to the end of a situation information recording period. For example, in a case where the vehicle situation information 104 holds information on a first situation information recording period, when a second situation information recording period ends, the vehicle situation information 104 may be updated to the content corresponding to the second situation information recording period. The situation judgment result 105 can be initialized at any timing. For example, when the trip time changes (i.e., when the previous trip time ends and a new trip time starts), the situation judgment result 105 may be maintained, or the situation judgment result 105 may be initialized, i.e., set to "0x00". The situation judgment result 105 may be initialized when a predetermined procedure from outside the vehicle 50 (for example, when it is confirmed by the SOC that there is no problem, when a problematic program is corrected, etc.) is performed. Alternatively, the situation judgment result 105 may be initialized when logs indicating that there was no tampering as a code verification result are collected from all the in-vehicle devices 3 or the relevant in-vehicle device 3.

[0060] In step 301, for example, for an abnormality log with abnormality ID 1011 of "0x002" as shown in Fig. 5, the predictive activity determination unit 15 first determines whether or not there has been a 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 intrusion presence / absence 1042 corresponding to in-vehicle device A is "1", it is determined that there has been a predictive activity, and if the value is "0", it is determined that there has been no predictive activity. In this example, since the value of intrusion presence / absence 1042 corresponding to in-vehicle device ID 1041 of "in-vehicle device A" is "0", 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 destination 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 a 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 a predictive activity, and if the value is "0", it is determined that there has been no predictive activity. In this example, since the value of the intrusion presence / absence 1042 corresponding to the in-vehicle device ID 1041 that is "in-vehicle device D" is "1", it is determined that there has been a predictive activity for the in-vehicle device D.

[0062] 7, for example, for an abnormality log related to the vehicle-mounted device C, when the victim device 1031 is the vehicle-mounted device C, a group including the vehicle-mounted device D and the vehicle-mounted device E and a group including only the vehicle-mounted device F are associated as the affected device 1032. For this reason, for an abnormality log related to the vehicle-mounted device C, when either or both of the infringement presence / absence 1042 corresponding to the vehicle-mounted device D and the infringement presence / absence 1042 corresponding to the vehicle-mounted device E are "1", it is determined that there has been a predictive activity for the vehicle-mounted device D or the vehicle-mounted device E, or both, and when both are "0", it is determined that there has been no predictive activity for the vehicle-mounted device D and the vehicle-mounted device E. When the infringement presence / absence 1042 corresponding to the vehicle-mounted device F is "1", it is determined that there has been a predictive activity for the vehicle-mounted device F, and when it is "0", it is determined that there has been no predictive activity for the vehicle-mounted 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 thereby determine the presence or absence of an attack predictor.

[0064] As a result of the determination in step 301, if it is determined that a predictive activity has occurred in any of the in-vehicle devices, the process proceeds to step 302, and if it is determined that a 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 determined to have had a predictive activity in step 301 is referred to. A specific example of the code verification result is not particularly illustrated, but it indicates, for example, whether or not a program executed by the in-vehicle device 3 has been tampered with, and can be generated based on publicly known technology. If the log acquired in the above step 201 is a log indicating the code verification result of the in-vehicle device 3 (for example, whether or not tampering has occurred), in step 302, it may be determined 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 the above 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] 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 at the start of execution of the program. Note that the code verification result is not limited to the result of the secure boot process, and may be the result of a verification executed at any timing after the start of execution of the program.

[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] Fig. 8B shows an example of the vehicle situation information 104 updated in step 303. In this embodiment, the vehicle situation information 104 includes both the information shown in Fig. 8A and the information shown in Fig. 8B, but these pieces of information may be included in different areas (for example, different databases, RAMs, data flashes).

[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, they 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 infringement 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 Fig. 7, and if the infringement situation 1045 of the corresponding group in Fig. 8B (which is {1, 1} in the example of Fig. 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 is to 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 is to 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 the case where the sum does not exceed the threshold value).

[0074] In step 307 , the vehicle state update unit 16 updates the situation judgment result 105 depending on 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 for identifying the situation of the vehicle, and a status 1052 for indicating the contents of the situation of the vehicle.

[0076] For example, in the initial state (eg, 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 becomes "0x01" and the status 1052 becomes "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 has been exceeded, the situation determination ID 1051 becomes "0x10" and the status 1052 becomes "accumulated notification." If step 306 is executed before step 307 and the threshold has not been exceeded, the situation determination ID 1051 becomes "0x01" and the status 1052 becomes "continuous monitoring."

[0080] If the results differ for multiple abnormality logs, the maximum value among the results is given priority for the situation judgment ID 1051. For example, if one abnormality log is judged as "continuous monitoring" (situation judgment ID 1051 is "0x01") and another abnormality log is judged as "immediate notification" (situation judgment ID 1051 is "0x11"), the resulting situation judgment ID 1051 will be "0x11".

[0081] As shown in FIG. 9, in this embodiment, the abnormality notification includes a cumulative notification related to the number of times an abnormality has occurred and an immediate notification related 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, so that the content of the abnormality can be output in more detail.

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

[0084] 3, the analysis device 1 decides to output an abnormality notification when it is determined that predictive activity has occurred (i.e., an abnormality has occurred within a predetermined period) and that tampering has occurred for any of the in-vehicle 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 in-vehicle device to the outside of the vehicle. The analysis device 1 may output an abnormality notification by the process shown in FIG. 4 in addition to or instead of step 209 shown in FIG.

[0086] 4, in particular, a case where the report is output as a regular report and a case where the report is output according to an instruction from outside the vehicle will be described. 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 repeatedly at regular intervals, or may be executed after an abnormality is notified.

[0087] In step 401, the instruction content analysis unit 20 checks whether or not a notification instruction has been received from outside the vehicle. If a notification instruction has been received, the process proceeds to step 402; if a notification instruction has not been received, the process 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 the outside of 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 based on the confirmation result in step 405 that the current time is the predetermined timing, the process proceeds to step 407, otherwise the process flow ends.

[0093] In step 407, the notification information generating unit 18 generates standardized data to be output to the outside of the vehicle. For example, information consisting of a part or all of the information held in the memory unit of the analysis device 1 is generated.

[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 in step 209 in FIG.

[0095] According to the above process, the analysis device 1 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.

[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 a situation where it is determined that an attack has occurred, it is possible to flexibly notify additional information in accordance with requests 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 vehicle-mounted 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 result, 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 an abnormality notification to be output immediately if an abnormality log requiring urgency is detected.

[0100] Moreover, according to the first embodiment, it is possible to reduce the number of cases where a notification is issued 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 linking 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 when it is determined that there has been no tampering with any of the in-vehicle devices 3. In this case, it is possible to suppress false positives of attacks based on abnormality logs.

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

[0104] In addition, 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 comprises: 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 a result of the determination and a code verification result of the monitoring target device acquired before the determination; Analyzer.

2. The analysis device according to claim 1 , 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. Analyzer.

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

4. The analysis device according to claim 2, 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 monitored devices; Analyzer.

5. The analysis device according to claim 2, 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.

6. The analysis device according to claim 1 , 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 of time or the number of times the same abnormality has occurred within a predetermined period of time. Analyzer.

7. The analysis device according to claim 1 , 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.

8. The analysis device according to claim 4, 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.

9. The analysis device according to claim 1 , 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.

10. The analysis device according to claim 2, When the code verification result spans multiple trip times, If there is no tampering with the program executed by the monitored device, Erase the previous code verification result and / or notify the code verification result to the outside of the vehicle; Analyzer.

Images