Vehicle safety analysis system, vehicle safety analysis methods and procedures

Abstract

The vehicle safety analysis system of the present invention includes: an acquisition unit that acquires sensor log data related to in-vehicle devices mounted on a vehicle; a determination unit that determines whether the sensor log data acquired by the acquisition unit is sensor log data generated based on a phenomenon not caused by a cyber attack, based on status information indicating the status of the vehicle; an analysis unit that excludes the sensor log data generated based on a phenomenon not caused by the cyber attack and analyzes the sensor log data acquired by the acquisition unit; and an output unit that outputs the analysis result obtained by the analysis unit.

Description

Technical Field

[0001] This invention relates to a vehicle safety analysis system, a vehicle safety analysis method, and a program. Background Technology

[0002] There exists a vehicle security analysis system that acquires and analyzes sensor log data related to the onboard equipment of a vehicle in order to detect cyberattacks against automobiles and other vehicles.

[0003] Furthermore, an analysis device is known that determines whether to output an abnormality notification based on a determination result of whether an abnormality has occurred in the monitored device, and the code verification result of the monitored device (for example, see Patent Document 1).

[0004] <Prior art documents> <Patent Documents> Patent Document 1: Japanese Patent Application Publication No. 2022-138009 Summary of the Invention <Problem to be solved by this invention> In vehicle-mounted safety sensors designed for detecting cyberattacks, there are instances where phenomena not caused by cyberattacks are mistakenly detected as cyberattacks (false positives). When sensor log data generated based on such false detections is sent to the vehicle safety analysis system, problems arise during the analysis and processing within the system, such as useless analysis or reduced accuracy in attack detection.

[0005] The technology disclosed in Patent Document 1 can reduce the occurrence of false detections. However, in the existing technology, when false detections occur, there is still a problem: the vehicle safety analysis system cannot determine the erroneously detected sensor log data as false detections.

[0006] One embodiment of the present invention addresses the aforementioned issues, enabling a vehicle safety analysis system that acquires and analyzes sensor log data related to onboard devices mounted in a vehicle to identify erroneously detected sensor log data as false detections.

[0007] <Methods for solving problems> To address the aforementioned issues, an embodiment of the present invention provides a vehicle safety analysis system comprising: an acquisition unit that acquires sensor log data related to an onboard device mounted in a vehicle; a determination unit that determines, based on state information indicating the state of the vehicle, whether the sensor log data acquired by the acquisition unit is sensor log data generated based on a phenomenon not caused by a network attack; an analysis unit that excludes sensor log data generated based on a phenomenon not caused by a network attack and analyzes the sensor log data acquired by the acquisition unit; and an output unit that outputs the analysis results obtained by the analysis unit.

[0008] <The Effects of the Invention> According to one embodiment of the present invention, in a vehicle safety analysis system that acquires and analyzes sensor log data related to onboard devices mounted in a vehicle, it is possible to determine erroneously detected sensor log data as false detections. Attached Figure Description

[0009] Figure 1 This is a diagram illustrating a structural example of the vehicle safety analysis system according to this embodiment.

[0010] Figure 2 This is a diagram used to illustrate an example of the analysis and processing involved in this embodiment.

[0011] Figure 3 This is a diagram illustrating an example of the hardware structure of the computer involved in this embodiment.

[0012] Figure 4 This is a diagram illustrating an example of the functional structure of the SOC server according to this embodiment.

[0013] Figure 5 This is a schematic diagram illustrating an example of log data involved in this embodiment.

[0014] Figure 6 This is a schematic diagram illustrating an example of the analysis logic DB involved in this embodiment.

[0015] Figure 7 This is a schematic diagram illustrating an example of the state information involved in Embodiment 1.

[0016] Figure 8 This is a flowchart illustrating a processing example of the SOC server involved in Embodiment 1.

[0017] Figure 9 This is a flowchart illustrating a process example for determining or presuming the state of the vehicle involved in Embodiment 1.

[0018] Figure 10 This is a flowchart illustrating a determination process example involved in Embodiment 1.

[0019] Figure 11 This is a flowchart illustrating an analysis and processing example involved in Example 1.

[0020] Figure 12 This is a schematic diagram illustrating an example of the status information involved in Embodiment 2.

[0021] Figure 13 This is a flowchart illustrating an example of status information management and processing involved in Embodiment 2.

[0022] Figure 14 This is a flowchart illustrating a determination process example involved in Embodiment 2.

[0023] Figure 15 This diagram illustrates examples of other state information and determination methods involved in this embodiment.

[0024] Figure 16 This is a flowchart illustrating a determination process example involved in Embodiment 3. Detailed Implementation

[0025] Hereinafter, embodiments of the present invention (this embodiment) will be described with reference to the accompanying drawings. Furthermore, the embodiments described below are examples, and the application of the present invention is not limited to these embodiments.

[0026] <System Architecture> Figure 1 This is a diagram illustrating a structural example of the vehicle safety analysis system according to this embodiment. The vehicle safety analysis system 1 includes, for example, a SOC (Security Operation Center) server 10 and a SIRT (Security Incident Response Team) server 40 that are able to communicate with each other via a communication network.

[0027] The SOC server (vehicle security analysis device) 10 is, for example, an information processing device with a computer architecture, or a system including multiple computers. The SOC server 10 is an example of a vehicle security analysis device that acquires and analyzes sensor log data related to the on-board devices 21a, 21b, ... installed in the vehicle 20 in order to detect network attacks (hereinafter referred to as "attacks") against vehicles such as automobiles 20. Furthermore, in the following description, "on-board device 21" will be used to refer to any of the on-board devices 21a, 21b, ...

[0028] SOC server 10 performs analysis and processing 11 on the acquired sensor log data (hereinafter referred to as "log data"), and sends a report containing information related to the detected attack to SIRT server 40, etc., if an attack on vehicle 20 is detected.

[0029] exist Figure 1 In this example, the SOC server 10 obtains log data related to the on-board unit 21 installed in the vehicle 20 from the OEM (Original Equipment Manufacturing) server 30, which collects log data 31 from one or more vehicles 20. However, it is not limited to this; the SOC server 10 may also obtain log data related to the on-board unit 21 installed in the vehicle 20 from one or more vehicles 20 without going through the OEM server 30.

[0030] Furthermore, the SOC server 10 can obtain security information 51 from external servers 50 operated by organizations such as Auto-ISAC (Automotive Information Sharing and Analysis Center) via communication networks such as the Internet. This security information 51 includes various cybersecurity information, such as network threats related to connected vehicles and potential vulnerabilities. The SOC server 10 can also detect attacks on the vehicle 20 based on the obtained log data 31 and security information 51.

[0031] In addition, the SOC server 10 may also have the function of temporarily taking action against the vehicle 20 based on the security information 51 obtained or instructions from the SIRT server 40 when an attack on the vehicle 20 is detected.

[0032] SIRT server 40 is an information processing device with a computer architecture, or a system containing multiple computers. SIRT server 40 is, for example, a server operated by an organization (SIRT) that provides security responses to external threats to the safety of products manufactured and sold by vehicle manufacturers or in-vehicle device manufacturers to ensure the safety of their products. SIRT is also known as PSIRT (Product Security Incident Response Team) or CSIRT (Computer Security Incident Response Team).

[0033] SIRT server 40 has the function of implementing permanent measures on vehicle 20, including the response strategy, based on reports sent by SOC server 10, such as input of response strategies determined for each manufacturer. Furthermore, SIRT server 40 may also have the function of sharing security information 51 with external server 50 and instructing SOC server 10 or vehicle 20 on provisional measures for vehicle 20 based on security information 51.

[0034] (Analysis and processing example) Figure 2 This diagram illustrates an example of the analysis processing involved in this embodiment. For example, the SOC server 10 performs analysis processing 11 on log data 31 related to the vehicle-mounted device 21 installed in the vehicle 20, running multiple analysis logics 201.

[0035] Multiple analysis logics 201 describe each attack to be detected. For example, if an attack is detected by analysis logic B among the multiple analysis logics 201 through analysis processing 11, the SOC server 10 can determine the detected attack based on the description of analysis logic B. Preferably, the SOC server 10 generates a report 202 containing information about the detected attacks and outputs the generated report 202 to a given output destination such as the SIRT server 40.

[0036] Furthermore, the log data 31 obtained by the SOC server 10 contains false positives caused by misdetections that incorrectly identify phenomena not caused by a network attack as network attacks. Here, a false positive refers to a situation in security threat detection where a normal state, action, or operation is incorrectly detected as abnormal.

[0037] If the SOC server 10 receives false positive log data 31, it will execute multiple analysis logics 201 even if no attack has occurred. This results in useless analysis processing and reduced accuracy of attack detection.

[0038] The technology disclosed in Patent Document 1 can reduce the occurrence of false detections. However, in the existing technology, in the event of a false detection, the SOC server 10 cannot determine the erroneously detected log data 31 as a false positive.

[0039] Therefore, the SOC server 10 according to this embodiment has the following functions: acquiring log data related to the vehicle-mounted device 21 installed in the vehicle 20, and determining whether the acquired log data is a false positive based on the status information indicating the status of the vehicle 20. In addition, the SOC server 10 excludes the log data 31 that is determined to be a false positive from the acquired log data 31 and performs analysis processing 11.

[0040] Therefore, the vehicle safety analysis system 1 according to this embodiment can suppress useless analysis processing 11 caused by false positive log data 31 and improve the accuracy of attack detection.

[0041] <Hardware Structure> Figure 1 The SOC server 10, OEM server 30, SIRT server 40, and external server 50 described herein, for example, have... Figure 3 The hardware structure of computer 300 is shown. Alternatively, SOC server 10, OEM server 30, SIRT server 40, and external server 50 may be composed of multiple computers 300.

[0042] Figure 3 This is a diagram illustrating an example of the hardware structure of a computer according to one embodiment. The computer 300 includes, for example, a CPU (Central Processing Unit) 301, a memory 302, a storage device 303, a network I / F (Interface) 304, an external connection I / F 305, an output device 306, an input device 307, and an internal bus 308.

[0043] CPU 301 is, for example, a processor that performs various functions by executing programs stored in storage media such as memory 302 or storage device 303. Memory 302 includes, for example, volatile RAM (Random Access Memory) used as temporary storage for CPU 301, and non-volatile ROM (Read Only Memory) used as boot programs for CPU 301. Storage device 303 is, for example, a high-capacity, non-volatile storage device such as SSD (Solid State Drive) or HDD (Hard Disk Drive). Network I / F 304 includes one or more communication interfaces for connecting computer 300 to a communication network.

[0044] External connection I / F 305 is an interface for connecting external devices to computer 300. Output device 306 is an output device that outputs to the outside (e.g., a monitor, speaker, or indicator light). Input device 307 is an input device that accepts input from the outside (e.g., a keyboard, mouse, or microphone). Furthermore, input device 307 and output device 306 can also be an integrated input / output device (e.g., a touch panel display). Internal bus 308 is commonly connected to the above-mentioned components, transmitting, for example, address signals, data signals, and various control signals.

[0045] <Functional Structure> Next, the functional structure of the vehicle safety analysis system 1 involved in this embodiment will be described.

[0046] (Functional structure of a SOC server) Figure 4 This diagram illustrates an example of the functional structure of the SOC server according to this embodiment. The SOC server 10 implements, for example, [the following is an example of implementation details] by executing a given program on one or more computers 300 included with the SOC server 10. Figure 4 The functional structures are shown below. Figure 4 In the example, the SOC server 10 includes an acquisition unit 401, a status information management unit 402, a decision unit 403, an analysis unit 404, and an output unit 405. Furthermore, at least some of the above functional structures can also be implemented in hardware.

[0047] Furthermore, as an example, SOC server 10 in Figure 3 The storage unit, such as storage device 303, stores status information DB (Database) 411 and analysis logic DB 412. As another example, the SOC server 10 may also utilize the status information DB (Database) 411 or analysis logic DB 412 stored in an external storage server or cloud storage.

[0048] The acquisition unit 401 performs acquisition processing for acquiring log data (sensor log data) 31 related to the on-board unit 21 mounted on the vehicle 20. For example, the acquisition unit 401 acquires the log data 31 from an external server such as an OEM server 30 via a communication network. However, it is not limited to this; the acquisition unit 401 may also acquire the log data 31 from the vehicle 20 via a communication network.

[0049] Figure 5 This is a schematic diagram illustrating an example of log data involved in this embodiment. Figure 5In the example, log data 31 includes information such as "date and time," "vehicle identification number," "sensor," "SRC," "DST," etc., as an item. "Date and time" indicates the date and time when the phenomenon causing log data 31 was detected, the date and time log data 31 was generated, or the date and time it was sent. The vehicle identification number is, for example, an identification information used to identify vehicle 20, such as a VIN (Vehicle Identification Number).

[0050] “SENSOR,” “SRC,” “DST,” etc., are examples of data contained in log data 31. “SENSOR” is identification information (sensor ID, etc.) identifying the multiple on-board devices 21 or safety sensors installed in vehicle 20. “SRC” is identification information (IP address, etc.) identifying the source of the communication that caused the generation of log data 31. “DST” is identification information (IP address, etc.) identifying the destination of the communication that caused the generation of log data 31. Here, return to… Figure 4 Continuing with the explanation of the functional structure of SOC server 10.

[0051] The Status Information Management Unit 402 performs status information management processing to manage status information representing the status of each vehicle 20. For example, based on the log data 31 obtained by the Acquisition Unit 401, the Status Information Management Unit 402 estimates or determines the status of the vehicle 20, and stores the status information representing the status of the vehicle 20 in a corresponding manner with the vehicle identification number in the status information DB 411, etc., for management.

[0052] Alternatively, the status information management unit 402 may obtain the status of the vehicle 20 from an external vehicle management system or the vehicle 20 itself, and manage the status information representing the status of the vehicle 20. In addition, the status information management unit 402 may also estimate or determine the status of the vehicle 20 based on information obtained from an external vehicle management system or the vehicle 20, in addition to the log data 31 obtained by the acquisition unit 401.

[0053] The determination unit 403 performs the following determination process: based on the status information indicating the status of the vehicle 20, it determines whether the log data 31 acquired by the acquisition unit 401 is log data 31 generated based on a phenomenon not caused by a network attack. Preferably, the determination unit 403 determines log data 31 generated based on a phenomenon not caused by a network attack as a false positive. Furthermore, specific examples of status information and the determination process performed by the determination unit 403 will be described below with examples of several embodiments.

[0054] The analysis unit 404 excludes log data 31 (false positive log data 31) generated based on phenomena not caused by network attacks, and performs analysis processing to analyze the log data 31 obtained by the acquisition unit 401.

[0055] As an example, the analysis department 404 uses, for example... Figure 6 The analysis logic DB412 shown analyzes the log data 31 that was not judged as a false positive by the judgment unit 403.

[0056] Figure 6 This is a schematic diagram illustrating an example of the analysis logic DB involved in this embodiment. In the analysis logic DB412, as... Figure 6 As shown, multiple analysis logics 201 are pre-registered. The analysis unit 404 analyzes the log data 31, which is the object of analysis, by executing the multiple analysis logics 201 on the log data 31.

[0057] As described above, multiple analysis logics 201 are described for each attack to be detected. For example, analysis logic number 1 indicates that if the "SENSOR" value of log data 31 is "1" and the "DST" value is "10.0.0.1", it is an attack called "T001". Here, "T001" is identification information (attack ID, etc.) used to identify the attack.

[0058] Furthermore, the analysis logic for number 2 indicates that when the "SENSOR" value of log data 31 is "2" and the "SIGNATURE" value is "1", it is an attack known as "T002". Here, "SIGNATURE" is, for example, identification information (signature ID, etc.) that identifies data used to detect malware, specific communication patterns, or specific files.

[0059] The analysis unit 404 executes multiple analysis logics 201 on the log data 31 that the determination unit 403 determines to be analyzed. If an attack is detected, the information related to the detected attack is output as the analysis result.

[0060] Furthermore, the analysis method of the analysis unit 404 for the log data 31 described above is one example. In this embodiment, the analysis method of the analysis unit 404 for the log data 31 can also be any other arbitrary method.

[0061] The output unit 405 performs output processing to output the analysis results of the analysis unit 404 to a given output destination. For example, the output unit 405 sends the analysis results of the analysis unit 404 (such as report 202, etc.) to the SIRT server 40.

[0062] in addition, Figure 4The functional architecture of the SOC server 10 shown is an example. For example, Figure 4 The functional structures of the SOC server 10 shown can also be distributed across multiple devices. In this case, Figure 4 The functional structures of the SOC server 10 shown can be possessed by any device included in the vehicle safety analysis system 1.

[0063] Furthermore, if the status information managed by the status information management unit 402 is information that does not need to be maintained, the SOC server 10 (or vehicle safety analysis system 1) may not have status information DB411. In addition, the status information management unit 402 may also obtain and manage analysis and judgment information (such as safety information 51) that is unrelated to log data 31 from external servers such as 50.

[0064] [Example 1] Figure 7 This is a schematic diagram illustrating an example of the state information involved in Embodiment 1. For example... Figure 7 As shown, the status information management unit 402, for example, establishes a correspondence with the vehicle identification numbers of multiple vehicles 20 to manage status information 701 representing the status of each vehicle 20. Figure 7 In the example, vehicle 20 with vehicle identification number "JP00000000000005" is shown as "under repair," while vehicles 20 with vehicle identification numbers "JP000000000000006" and "JP00000000002000" are shown as "faulty." Furthermore, "N / A" in the status information indicates that vehicle 20 is neither "under repair" nor "faulty."

[0065] also, Figure 7 The status information 701 shown is an example for illustration; various other information representing the status of vehicle 20 can be used.

[0066] <Processing Flow> Next, the processing flow of the vehicle safety analysis method involved in Example 1 will be described.

[0067] (SOC server processing) Figure 8 This is a flowchart illustrating a processing example of the SOC server involved in Embodiment 1. The processing demonstrates, for example, having... Figure 4 A summary of the processes performed by the SOC server 10 in the shown functional structure.

[0068] In step S801, the acquisition unit 401 acquires log data 31 from the OEM server 30, etc.

[0069] In step S802, the status information management unit 402 estimates or determines the status of the vehicle 20 corresponding to the log data 31 based on the log data 31 obtained by the acquisition unit 401. For example, the status information management unit 402 executes... Figure 9 The process of determining or presuming the state of vehicle 20 as shown.

[0070] Figure 9 This is a flowchart illustrating an example of a process for determining or presuming a vehicle state as described in Embodiment 1. This process is illustrated, for example, in... Figure 8 This is an example of the processing performed by the Status Information Management Unit 402 in step S802.

[0071] In step S901, the status information management unit 402 extracts the information required to determine or estimate the status of the vehicle 20 from the log data 31 obtained by the acquisition unit 401.

[0072] In step S902, the status information management unit 402 determines whether the required information exists. For example, if the status information management unit 402 can extract the information needed to determine or estimate the status of the vehicle 20 in step S901, it determines that the required information exists. If the required information exists, the status information management unit 402 transfers the processing to step S903. On the other hand, if the required information does not exist, the status information management unit 402, for example, terminates the process. Figure 9 The processing.

[0073] When the process moves to step S903, the status information management unit 402 extracts the vehicle identification number used to identify the vehicle 20 from the log data 31 obtained by the acquisition unit 401.

[0074] In step S904, the status information management unit 402 determines or presumes the status of the vehicle 20 based on the information extracted in step S901.

[0075] In step S905, as Figure 7 As shown, the status information management unit 402 stores, for example, status information 701 indicating the status of vehicle 20 in a corresponding manner with vehicle identification number in status information DB411, etc.

[0076] also, Figure 9 The process of determining or presuming the status of a vehicle shown is one example. For example, in step S901, it is not limited to log data 31; the status information management unit 402 may also obtain the information required to determine or presum the status of the vehicle 20 from an external vehicle management system or other system that manages the status of the vehicle 20.

[0077] Here, return Figure 8Continuing with the explanation of the SOC server's processing. In step S803, the determination unit 403 determines a false positive based on the status information indicating the state of the vehicle 20. As a specific example, the determination unit 403 executes... Figure 10 The judgment and processing are as shown.

[0078] Figure 10 This is a flowchart illustrating an example of the determination process involved in Embodiment 1. This process is illustrated, for example, in... Figure 8 This is an example of the processing performed by the determination unit 403 in step S803.

[0079] In step S1001, the determination unit 403 extracts the vehicle identification number from the log data 31 obtained by the acquisition unit 401. Alternatively, the determination unit 403 may obtain the log data 31 obtained by the acquisition unit 401 from the status information management unit 402, or obtain it directly from the acquisition unit 401.

[0080] In step S1002, the determination unit 403 obtains status information corresponding to the extracted vehicle identification number. For example, the determination unit 403 obtains from... Figure 7 In the status information 701 shown, the status information corresponding to the extracted vehicle identification number is obtained.

[0081] In step S1003, the determination unit 403 determines whether status information exists. For example, the determination unit 403 determines whether status information exists from... Figure 7 If the status information 701 shown indicates a "faulty" or "repairing" status, it is determined that status information exists. If status information exists, the determination unit 403 transfers the processing to step S1004. Conversely, if no status information exists, the determination unit 403 terminates the process. Figure 10 The processing.

[0082] When the process moves to step S1004, the determination unit 403 determines whether the vehicle 20 is "under repair" or "in malfunction". If the vehicle 20 is "under repair" or "in malfunction", the determination unit 403 moves the process to step S1005. On the other hand, if the vehicle 20 is neither "under repair" nor "in malfunction", the determination unit 403 terminates the process. Figure 10 The processing.

[0083] When the process moves to step S1005, the determination unit 403 determines the log data 31 obtained by the acquisition unit 401 as a false positive.

[0084] Furthermore, "under repair" and "in malfunction" are examples of status information indicating the state of vehicle 20. Additionally, the processing in steps S1003 to S1005 is an example of a method for determining whether log data 31 is a false positive based on the status information indicating the state of vehicle 20. Examples of other status information and determination methods involved in this embodiment will be described later.

[0085] Here, let's return again. Figure 8 The processing of the SOC server will be explained further. In step S804, if the determination result of the determination unit 403 is not a false positive, the SOC server 10 executes the processing steps S805 and S806. On the other hand, if the determination result of the determination unit 403 is a false positive, the SOC server 10 terminates the processing without executing steps S805 and S806. Figure 8 The processing.

[0086] When the process moves to step S805, the analysis unit 404 performs analysis processing to analyze the log data 31 acquired by the acquisition unit 401. As a specific example, the analysis unit 404 performs... Figure 11 The analysis and processing are as shown.

[0087] Figure 11 This is a flowchart illustrating an example of the analysis process involved in Embodiment 1. This process is illustrated, for example, in... Figure 8 This is an example of the processing performed by the analysis unit 404 in step S805.

[0088] In step S1101, the analysis unit 404 extracts the vehicle identification number from the log data 31 obtained by the acquisition unit 401.

[0089] In step S1102, the analysis unit 404 obtains from, for example... Figure 6 In the analysis logic DB412 shown, an analysis logic group (multiple analysis logics 201) is obtained.

[0090] In step S1103, the analysis unit 404 selects one unselected analysis logic from the acquired analysis logic group.

[0091] In step S1104, the analysis unit 404 determines whether there is any unselected analysis logic. For example, if an unselected analysis logic can be selected in step S1103, the analysis unit 404 determines that there is unselected analysis logic. If there is unselected analysis logic, the analysis unit 404 transfers the process to step S1105. On the other hand, if there is no unselected analysis logic, the analysis unit 404 transfers the process to step S1106.

[0092] When the process moves to step S1105, the analysis unit 404 executes the selected analysis logic on the log data 31 and returns the processing to step S1103. Through the processing of steps S1103 to S1105, the analysis unit 404, for example, executes all the analysis logic contained in the acquired analysis logic group on the log data 31 acquired by the acquisition unit 401.

[0093] When the process moves to step S1106, the analysis unit 404 outputs the vehicle identification number extracted from the log data 31 obtained by the acquisition unit 401, as well as the analysis results obtained through steps S1103 to S1105, to the output unit. These analysis results may include, for example, information (attack ID, etc.) used to determine attacks detected by the analysis logic group.

[0094] Here, let's return again. Figure 8 This further explains the processing of the SOC server. In step S806, the output unit 405 outputs the analysis results obtained by the analysis unit 404 to a given output destination. For example, the output unit 405 generates a report 202 containing attack information detected by the analysis processing 11 of the analysis unit 404 and the vehicle identification number of the vehicle 20 that detected the attack, and sends the generated report 202 to the SIRT server 40, etc. Furthermore, if using... Figure 2 As explained, the generation of report 202 can also be performed in the analysis process 11 executed by the analysis unit 404.

[0095] In this way, the SOC server 10 involved in Embodiment 1 can determine the log data 31 related to the vehicle 20 as a false positive based on the status information representing the status of the vehicle 20, and exclude it from the objects of the analysis and processing 11.

[0096] [Example 2] Figure 12 This is a schematic diagram illustrating an example of the state information involved in Embodiment 2. For example... Figure 12 As shown, the status information management unit 402 involved in Embodiment 2 manages the information indicating whether or not log data 31 implying an attack is generated by establishing a correspondence between the status information 1201 and the vehicle identification numbers of multiple vehicles 20.

[0097] exist Figure 12 In the context of status information 1201, "FALSE" indicates that no log data 31 strongly suggesting an attack was detected in vehicle 20 corresponding to the vehicle identification number. On the other hand, "TRUE" in status information 1201 indicates that log data 31 strongly suggesting an attack was detected in vehicle 20 corresponding to the vehicle identification number.

[0098] <Processing Flow> Next, the processing flow of the vehicle safety analysis method involved in Example 2 will be described. Furthermore, the processing of the SOC server involved in Example 2 can be integrated with... Figure 8 The processing of the SOC server described in Embodiment 1 is the same. Furthermore, the analysis processing described in Embodiment 2 can be the same as that in... Figure 11 The analytical processing involved in Example 1 described herein is the same.

[0099] (Management Processing) Figure 13 This is a flowchart illustrating an example of the status information management process involved in Embodiment 2. This process is illustrated, for example, in... Figure 8 Another example of the processing performed by the Status Information Management Unit 402 in step S802.

[0100] In step S1301, the status information management unit 402 extracts the vehicle identification number from the log data 31 obtained by the acquisition unit 401.

[0101] In step S1302, the status information management unit 402 obtains status information corresponding to the extracted vehicle identification number. For example, the status information management unit 402 obtains from... Figure 12 In the status information 1201 shown, obtain the status information corresponding to the extracted vehicle identification number.

[0102] In step S1303, the status information management unit 402 determines whether there is any information in the log data 31 or the status information obtained by the acquisition unit 401 that suggests an attack (cyberattack) on the vehicle 20. For example, if the log data 31 obtained by the acquisition unit 401 contains information that strongly suggests an attack on the vehicle 20, and / or the obtained status information is "TRUE", the status information management unit 402 determines that there is information suggesting an attack. On the other hand, if the log data 31 obtained by the acquisition unit 401 does not contain information that strongly suggests an attack on the vehicle 20, and the obtained status information is "FALSE", the status information management unit 402 determines that there is no information suggesting an attack.

[0103] If information suggesting an attack exists, the status information management unit 402 transfers the processing to step S1304. On the other hand, if no information suggesting an attack exists, the status information management unit 402 transfers the processing to step S1305.

[0104] When the process moves to step S1304, the status information management unit 402 stores “TRUE” in the status information corresponding to the vehicle identification number.

[0105] On the other hand, when the process moves to step S1305, the status information management unit 402 stores "FALSE" in the status information corresponding to the vehicle identification number. Alternatively, the status information management unit 402 may omit the processing of step S1305 and maintain the status information corresponding to the vehicle identification number of the vehicle 20.

[0106] pass Figure 13 For example, the Status Information Management Department 402 can process the status information. Figure 12 The status information 1201 shown is stored in status information DB411 and other such storages for management.

[0107] (Judgment and processing) Figure 14 This is a flowchart illustrating an example of the determination process involved in Embodiment 2. This process is illustrated, for example, in... Figure 8 Another example of the processing performed by the determination unit 403 in step S803.

[0108] In step S1401, the determination unit 403 extracts the vehicle identification number from the log data 31 obtained by the acquisition unit 401.

[0109] In step S1402, the determination unit 403 obtains status information corresponding to the extracted vehicle identification number. For example, the determination unit 403 obtains from... Figure 12 In the status information 1201 shown, obtain the status information corresponding to the extracted vehicle identification number.

[0110] In step S1403, the determination unit 403 determines whether the acquired status information is "TRUE". If the acquired status information is "TRUE", the determination unit 403 transfers the process to step S1404. On the other hand, if the acquired status information is not "TRUE" (is "FALSE"), the determination unit 403 transfers the process to step S1405.

[0111] When the process proceeds to step S1404, the determination unit 403 determines the log data 31 obtained by the acquisition unit 401 as a true positive. On the other hand, when the process proceeds to step S1405, the determination unit 403 determines the log data 31 obtained by the acquisition unit 401 as a false positive. Furthermore, the processing in step S1404 is optional and not mandatory.

[0112] In this way, the SOC server 10 involved in Embodiment 2 can determine the log data 31 related to the vehicle 20 as a false positive based on the status information representing the status of the vehicle 20, and exclude it from the objects of the analysis and processing 11.

[0113] (Examples of other status information) The status information described in Examples 1 and 2 is one example. The vehicle safety analysis system 1 can also use, for example, the following: Figure 15 The system uses various other status information, as shown, to determine whether the log data 31 obtained by the acquisition unit 401 is a false positive.

[0114] Figure 15 This diagram illustrates examples of other state information and determination methods involved in this embodiment. For example, such as... Figure 15 As shown, the vehicle safety analysis system 1 can also use "vehicle location" as status information. In this case, the status information management unit 402 can obtain location information indicating the location of the vehicle 20 from an external vehicle management system that manages the status of the vehicle 20 or from the vehicle 20 itself. Alternatively, the status information management unit 402 can also obtain location information indicating the location of the vehicle 20 from log data 31.

[0115] For example, the determination unit 403 may also determine the log data 31 obtained by the acquisition unit 401 as a false positive when the vehicle 20 is located at the production site or maintenance site of the vehicle 20. This is based on the assumption that many false positives may occur during production or maintenance operations.

[0116] Alternatively, the determination unit 403 may also determine the log data 31 obtained by the acquisition unit 401 as a false positive if the vehicle 20 is located near a location where false positives have occurred in the past. This is based on the assumption that false positives can occur due to specific conditions that depend on geographical location (road conditions, strong electric fields, electromagnetic interference waves, etc.).

[0117] As another example, such as Figure 15 As shown, the vehicle safety analysis system 1 can also use "whether the vehicle is under repair" as status information. In this case, the status information management unit 402 can obtain information indicating whether the vehicle 20 is under repair from an external vehicle management system that manages the status of the vehicle 20 or from the vehicle 20 itself. Alternatively, the status information management unit 402 can also obtain information indicating whether the vehicle 20 is under repair from log data 31.

[0118] For example, the determination unit 403 can determine the log data 31 obtained by the acquisition unit 401 as a false positive when the vehicle 20 is under repair. This is based on the assumption that many false positives may occur during repair work.

[0119] As another example, such as Figure 15As shown, the vehicle safety analysis system 1 can also use "presence or absence of a fault" as status information. In this case, the status information management unit 402 can obtain the presence or absence of a fault in the vehicle 20 from an external vehicle management system that manages the status of the vehicle 20 or from the vehicle 20 itself. Alternatively, the status information management unit 402 can also obtain the presence or absence of a fault in the vehicle 20 from the log data 31. In this case, the determination unit 403 can determine the log data 31 obtained by the acquisition unit 401 as a false positive if the vehicle 20 is in a fault state. This is based on the assumption that many false positives can occur during a fault.

[0120] As another example, such as Figure 15 As shown, the vehicle safety analysis system 1 can also use "whether the vehicle is connected to the outside" as status information. In this case, the status information management unit 402 can obtain information indicating whether the vehicle 20 is connected to an external network (Internet or V2X, etc.) or an external device (diagnostic machine, etc.) from an external vehicle management system that manages the status of the vehicle 20 or from the vehicle 20 itself. Alternatively, the status information management unit 402 can also obtain information indicating whether the vehicle 20 is connected to the outside from log data 31.

[0121] Furthermore, V2X stands for "Vehicle to Everything," a general term for technologies that connect and coordinate vehicle 20 with everything (other vehicles, pedestrians, infrastructure, networks, etc.) through communication. In this case, the determination unit 403 can determine the log data 31 obtained by the acquisition unit 401 as a false positive even when vehicle 20 is not connected to the outside world. This is based on the premise that most attacks on vehicle 20 are external threats, and other threats are acceptable.

[0122] As another example, such as Figure 15 As shown, the vehicle safety analysis system 1 can also use "whether the vehicle is in operation" as status information. In this case, the status information management unit 402 can obtain information indicating whether the vehicle 20 is in operation from an external vehicle management system that manages the status of the vehicle 20 or from the vehicle 20 itself. Alternatively, the status information management unit 402 can also obtain information indicating whether the vehicle 20 is in operation from log data 31. In this case, the determination unit 403 can determine the log data 31 obtained by the acquisition unit 401 as a false positive when the vehicle 20 is in operation. This is based on the assumption that many false positives may occur when the vehicle 20 is in operation.

[0123] As another example, such as Figure 15As shown, the vehicle safety analysis system 1 can also use "the elapsed time since the start of driving" as status information. In this case, the determination unit 403 can determine the log data 31 acquired by the acquisition unit 401 as a false positive within a given time period since the start of driving of the vehicle 20. This is based on the assumption that after the start of driving of the vehicle 20, the state of the vehicle 20 is unstable in a mechanical or electrical way, which may lead to a false positive.

[0124] As another example, such as Figure 15 As shown, the vehicle safety analysis system 1 can also use "the elapsed time since the end of driving" as status information. In this case, the determination unit 403 can determine the log data 31 obtained by the acquisition unit 401 as a false positive within a given time period since the end of driving of the vehicle 20. This is based on the assumption that the state of the vehicle 20 is unstable mechanically or electrically immediately after driving of the vehicle 20, which may lead to a false positive.

[0125] As another example, such as Figure 15 As shown, the vehicle safety analysis system 1 can also use "whether it is undergoing a software update" as status information. In this case, the status information management unit 402 can obtain whether the vehicle 20 is undergoing a software update from an external vehicle management system that manages the status of the vehicle 20 or from the vehicle 20 itself. Alternatively, the status information management unit 402 can also obtain whether the vehicle 20 is undergoing a software update from the log data 31. In this case, the determination unit 403 can determine the log data 31 obtained by the acquisition unit 401 as a false positive if the vehicle 20 is undergoing a software update. This is based on the assumption that during a software update, the vehicle 20 may be in a different state than usual, leading to false positives.

[0126] As another example, such as Figure 15 As shown, the vehicle safety analysis system 1 can also use "vehicle acceleration" as status information. In this case, the determination unit 403 can determine the log data 31 acquired by the acquisition unit 401 as a false positive if the change in the acceleration of the vehicle 20 is outside a given range. This is based on the assumption that rapid acceleration or deceleration of the vehicle 20 can cause instability in the mechanical or electrical state of the vehicle 20, resulting in a false positive.

[0127] As another example, such as Figure 15 As shown, the vehicle safety analysis system 1 can also use "vehicle load" as status information. In this case, the determination unit 403 can determine the log data 31 obtained by the acquisition unit 401 as a false positive if the load of the vehicle 20 is outside a given range. This is based on the assumption that overloading the vehicle 20 will cause instability in the mechanical or electrical state of the vehicle 20, resulting in a false positive.

[0128] As another example, such as Figure 15 As shown, the vehicle safety analysis system 1 can also use "driving statistical characteristics" as status information. In this case, the status information management unit 402 can obtain the driving statistical characteristics of the vehicle 20 from the status of the vehicle 20 or from external systems in operation. In this case, the determination unit 403 can compare the driver model with the driving statistical characteristics, and if the difference is small, determine the log data 31 obtained by the acquisition unit 401 as a false positive.

[0129] In addition, the vehicle safety analysis system 1 can also combine the above-mentioned multiple status information to determine whether the log data 31 obtained by the acquisition unit 401 is a false positive.

[0130] [Third Implementation] Figure 16 This is a flowchart illustrating an example of the determination process according to the third embodiment. This process shows an example of the analysis process when there are multiple state information items.

[0131] Furthermore, the processing of the SOC server involved in Example 3 can be combined with... Figure 8 The processing of the SOC server described in Example 1 is the same. Furthermore, the analysis processing described in Example 3 can be the same as that in... Figure 11 The analysis and processing involved in Embodiment 1 described herein are the same. In addition, the Status Information Management Unit 402 manages four status information: "whether log data suggesting an attack has been generated", "whether the vehicle is under repair", "whether there is a fault", and "whether it is undergoing a software update".

[0132] In step S1601, the determination unit 403 extracts the vehicle identification number from the log data 31 obtained by the acquisition unit 401.

[0133] In step S1602, the determination unit 403 obtains the status information corresponding to the extracted vehicle identification number. For example, the determination unit 403 obtains the four status information mentioned above.

[0134] In step S1603, the determination unit 403 determines whether log data suggesting an attack has been generated. For example, the determination unit 403... Figure 12 If the status information indicating whether "log data suggesting an attack has been generated" is "TRUE", it is determined that log data suggesting an attack has been generated.

[0135] If log data suggesting an attack is generated, the determination unit 403 transfers the process to step S1604. On the other hand, if log data suggesting an attack is not generated, the determination unit 403 transfers the process to step S1605.

[0136] When the process moves to step S1604, the determination unit 403 determines the log data 31 obtained by the acquisition unit 401 as a false positive.

[0137] On the other hand, when the process proceeds to step S1605, the determination unit 403 determines, based on the acquired status information, whether the vehicle 20 is under repair, experiencing a malfunction, or undergoing a software update. If the vehicle 20 is under repair, experiencing a malfunction, or undergoing a software update, the determination unit 403 transfers the process to step S1604. Conversely, if the vehicle 20 is not under repair, experiencing a malfunction, or undergoing a software update, the determination unit 403 terminates the process. Figure 16 The processing.

[0138] In this way, the determination unit 403 can also combine multiple status information to determine whether the log data 31 obtained by the acquisition unit 401 is a false positive.

[0139] According to this embodiment, in a vehicle safety analysis system that acquires and analyzes sensor log data related to an onboard device mounted in a vehicle, it is possible to determine erroneously detected sensor log data as false detections.

[0140] <Summary of Implementation Methods> This specification discloses a vehicle safety analysis system, vehicle safety analysis method, and procedure that include at least the following.

[0141] (Item 1) A vehicle safety analysis system, which has the following features: The acquisition unit acquires sensor log data related to onboard devices installed in the vehicle; The determination unit determines, based on the status information indicating the state of the vehicle, whether the sensor log data obtained by the acquisition unit is sensor log data generated based on a phenomenon not caused by a network attack. The analysis unit analyzes the sensor log data acquired by the acquisition unit, excluding sensor log data generated based on phenomena not caused by the aforementioned network attack; and The output unit outputs the analysis results obtained by the analysis unit.

[0142] (Item 2) The vehicle safety analysis system according to item 1 has the following features: The Status Information Management Department determines or estimates the status of the vehicle based on the sensor log data obtained by the Acquisition Department.

[0143] (Item 3) The vehicle safety analysis system according to item 1 has the following features: The status information management department obtains information about the vehicle from the vehicle or an external server, and manages the status information based on the vehicle information.

[0144] (Item 4) The vehicle safety analysis system according to any one of items 1 to 3, wherein, The determination unit will identify sensor log data generated based on phenomena not caused by the network attack as false positives.

[0145] (Item 5) The vehicle safety analysis system according to any one of items 1 to 4, wherein, The status information includes information indicating whether sensor log data suggesting a cyberattack has occurred in the vehicle. If no sensor log data indicating a network attack occurs is generated in the vehicle, the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on phenomena not caused by the network attack.

[0146] (Item 6) The vehicle safety analysis system according to any one of items 1 to 5, wherein, The status information includes information indicating whether the vehicle is under repair, experiencing a malfunction, or undergoing a software update. When the vehicle is under repair, malfunctioning, or undergoing software updates, the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on phenomena not caused by the network attack.

[0147] (Item 7) The vehicle safety analysis system according to any one of items 1 to 6, wherein, The status information includes information indicating whether the vehicle is connected to an external network or external device. If the vehicle is not connected to an external network or external device, the determination unit determines that the sensor log data obtained by the acquisition unit is sensor log data generated based on a phenomenon not caused by the network attack.

[0148] (Item 8) The vehicle safety analysis system according to any one of items 1 to 7, wherein, The status information includes information indicating the location of the vehicle. If the vehicle's location is near the vehicle's production or maintenance site, or if the vehicle's location is near a location where false positives have occurred in the past, the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on a phenomenon not caused by the network attack.

[0149] (Item 9) A vehicle safety analysis method, wherein a computer performs the following processing: Obtain and process sensor log data related to onboard devices installed in the vehicle; The determination process, based on the status information representing the state of the vehicle, determines whether the sensor log data obtained by the acquisition process is sensor log data generated based on a phenomenon not caused by a network attack. The analysis process excludes sensor log data generated based on phenomena not caused by the aforementioned network attack, and analyzes the sensor log data obtained by the acquisition process; and Output processing: Output the analysis results of the analysis processing.

[0150] (Item 10) A program that causes a computer to perform the following processing: Obtain and process sensor log data related to onboard devices installed in the vehicle; The determination process, based on the status information representing the state of the vehicle, determines whether the sensor log data obtained by the acquisition process is sensor log data generated based on a phenomenon not caused by a network attack. The analysis process excludes sensor log data generated based on phenomena not caused by the aforementioned network attack, and analyzes the sensor log data obtained by the acquisition process; and Output processing: Output the analysis results of the analysis processing.

[0151] The embodiments of the present invention have been described in detail above, but the present invention can be modified and applied in various ways within the scope of the spirit described in the claims.

[0152] This application claims priority to basic application No. 2023-186504 filed with the Japan Patent Office on October 31, 2023, the entire contents of which are incorporated herein by reference.

[0153] Symbol Explanation 1: Vehicle Safety Analysis System 10: SOC Server (Vehicle Safety Analysis Device) 20: Vehicles 21, 21a, 21b: Vehicle-mounted devices 31: Log data (sensor log data) 300: Computer 401: Acquisition Department 402: Status Information Management Department 403: Judgment Department 404: Analysis Department 405: Output Section 411: Status Information DB 412: Analyze the logical DB 701, 1201: Status information.

Claims

1. A vehicle safety analysis system, comprising: The acquisition unit acquires sensor log data related to onboard devices installed in the vehicle; The determination unit determines, based on the status information indicating the state of the vehicle, whether the sensor log data acquired by the acquisition unit is sensor log data generated based on a phenomenon not caused by a network attack. The analysis unit analyzes the sensor log data acquired by the acquisition unit, excluding sensor log data generated based on phenomena not caused by the network attack; and The output unit outputs the analysis results obtained by the analysis unit.

2. The vehicle safety analysis system according to claim 1, comprising: The status information management unit determines or estimates the status of the vehicle based on the sensor log data obtained by the acquisition unit.

3. The vehicle safety analysis system according to claim 1, comprising: The status information management department obtains information about the vehicle from the vehicle or an external server, and manages the status information based on the vehicle information.

4. The vehicle safety analysis system according to claim 1, wherein, The determination unit will identify sensor log data generated based on phenomena not caused by the network attack as false positives.

5. The vehicle safety analysis system according to any one of claims 1 to 4, wherein, The status information includes information indicating whether sensor log data suggesting a cyberattack has occurred in the vehicle. If no sensor log data indicating a network attack occurs is generated in the vehicle, the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on phenomena not caused by the network attack.

6. The vehicle safety analysis system according to any one of claims 1 to 4, wherein, The status information includes information indicating whether the vehicle is under repair, experiencing a malfunction, or undergoing a software update. When the vehicle is under repair, malfunctioning, or undergoing software updates, the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on phenomena not caused by the network attack.

7. The vehicle safety analysis system according to any one of claims 1 to 4, wherein, The status information includes information indicating whether the vehicle is connected to an external network or external device. If the vehicle is not connected to an external network or external device, the determination unit determines that the sensor log data obtained by the acquisition unit is sensor log data generated based on a phenomenon not caused by the network attack.

8. The vehicle safety analysis system according to any one of claims 1 to 4, wherein, The status information includes information indicating the location of the vehicle. If the vehicle's location is near the vehicle's production or maintenance site, or if the vehicle's location is near a location where false positives have occurred in the past, the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on a phenomenon not caused by the network attack.

9. A vehicle safety analysis method, wherein, The computer performs the following processing: Obtain and process sensor log data related to onboard devices installed in the vehicle; The determination process, based on the status information representing the state of the vehicle, determines whether the sensor log data obtained by the acquisition process is sensor log data generated based on a phenomenon not caused by a network attack. The analysis process excludes sensor log data generated based on phenomena not caused by the aforementioned network attack, and analyzes the sensor log data obtained by the acquisition process; and Output processing: Output the analysis results of the analysis processing.

10. A program for causing a computer to perform the following processes: Obtain and process sensor log data related to onboard devices installed in the vehicle; The determination process, based on the status information representing the state of the vehicle, determines whether the sensor log data obtained by the acquisition process is sensor log data generated based on a phenomenon not caused by a network attack. The analysis process excludes sensor log data generated based on phenomena not caused by the aforementioned network attack, and analyzes the sensor log data obtained by the acquisition process; and Output processing: Output the analysis results of the analysis processing.

Images