Vehicle security analysis system, vehicle security analysis method, and program

The vehicle security analysis system addresses the challenge of false positives in sensor log data by using a judgment unit to determine the validity of the data within the system, thereby enhancing the accuracy of cyberattack detection and reducing unnecessary analysis.

WO2025094585A1PCT designated stage expired Publication Date: 2025-05-08NTT SECURITY (JAPAN) KK
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
PCT/JP2024/035466
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-10-31
Filing Date
2024-10-03
Publication Date
2025-05-08

AI Technical Summary

Technical Problem

Existing vehicle security analysis systems cannot accurately determine whether sensor log data indicating a cyberattack is a false positive, leading to unnecessary analysis processing and reduced accuracy in attack detection.

Method used

A vehicle security analysis system that includes an acquisition unit for acquiring sensor log data, a judgment unit to determine if the data is based on vehicle status information or non-cyberattack events, an analysis unit to analyze the data, and an output unit to provide analysis results, thereby identifying and excluding false positive data.

Benefits of technology

The system effectively suppresses unnecessary analysis processing due to false positive log data and improves the accuracy of attack detection by accurately identifying and excluding erroneous sensor log data.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure JP2024035466_08052025_PF_FP_ABST
    Figure JP2024035466_08052025_PF_FP_ABST
Patent Text Reader

Abstract

This vehicle security analysis system comprises: an acquisition unit that acquires sensor log data relating to an in-vehicle device mounted in a vehicle; a determination unit that determines, on the basis of state information indicating the state of the vehicle, whether the sensor log data acquired by the acquisition unit is sensor log data generated on the basis of an event that is not caused by a cyber attack; an analysis unit that analyzes the sensor log data acquired by the acquisition unit except for sensor log data generated on the basis of the event that is not caused by the cyber attack; and an output unit that outputs the result of the analysis by the analysis unit.
Need to check novelty before this filing date? Find Prior Art

Description

Vehicle security analysis system, vehicle security analysis method, and program

[0001] The present invention relates to a vehicle security analysis system, a vehicle security analysis method, and a program.

[0002] In order to detect cyber attacks against vehicles such as automobiles, there is a vehicle security analysis system that acquires and analyzes sensor log data related to on-board devices installed in the vehicle.

[0003] In addition, an analysis device is known that determines whether or not an abnormality notification indicating an abnormality is to be output based on the monitoring results of the monitored device and the code verification results of the monitored device (see, for example, Patent Document 1).

[0004] Japanese Patent Application Laid-Open No. 2022-138009

[0005] In a security sensor installed in a vehicle for detecting cyberattacks, a false positive may occur, where an event that is not caused by a cyberattack is mistakenly detected as a cyberattack. If sensor log data generated based on such a false positive is transmitted to a vehicle security analysis system, the analysis process in the vehicle security analysis system may encounter problems such as unnecessary analysis processing or a decrease in the accuracy of attack detection.

[0006] The technology disclosed in Patent Document 1 can reduce the occurrence of false detections. However, the conventional technology has a problem in that, when a false detection occurs, the vehicle security analysis system cannot determine that the erroneously detected sensor log data is a false detection.

[0007] One embodiment of the present invention has been made in consideration of the above-mentioned problems, and enables a vehicle security analysis system that acquires and analyzes sensor log data related to onboard devices installed in a vehicle to determine that erroneously detected sensor log data is a false detection.

[0008] In order to solve the above problems, a vehicle security analysis system according to one embodiment of the present invention comprises an acquisition unit that acquires sensor log data relating to an onboard device installed in a vehicle, a determination unit that determines, based on status information indicating the status of the vehicle, whether the sensor log data acquired by the acquisition unit is sensor log data that has occurred due to an event that is not caused by a cyber-attack, an analysis unit that analyzes the sensor log data acquired by the acquisition unit while excluding sensor log data that has occurred due to an event that is not caused by the cyber-attack, and an output unit that outputs the analysis results by the analysis unit.

[0009] According to one embodiment of the present invention, in a vehicle security analysis system that acquires and analyzes sensor log data related to onboard devices installed in a vehicle, it becomes possible to determine that erroneously detected sensor log data is a false detection.

[0010] FIG. 1 is a diagram illustrating an example of the configuration of a vehicle security analysis system according to the present embodiment. FIG. 2 is a diagram for explaining an example of an analysis process according to the present embodiment. FIG. 3 is a diagram illustrating an example of the hardware configuration of a computer according to the present embodiment. FIG. 4 is a diagram illustrating an example of the functional configuration of an SOC server according to the present embodiment. FIG. 5 is a diagram illustrating an example of log data according to the present embodiment. FIG. 6 is a diagram illustrating an example of an analysis logic DB according to the present embodiment. FIG. 7 is a diagram illustrating an example of status information according to Example 1. FIG. 8 is a flowchart illustrating an example of processing of an SOC server according to Example 1. FIG. 9 is a flowchart illustrating an example of processing for identifying or estimating the status of a vehicle according to Example 1. FIG. 10 is a flowchart illustrating an example of determination processing according to Example 1. FIG. 11 is a flowchart illustrating an example of analysis processing according to Example 1. FIG. 12 is a diagram illustrating an example of status information according to Example 2. FIG. 13 is a flowchart illustrating an example of management processing of status information according to Example 2. FIG. 14 is a flowchart illustrating an example of determination processing according to Example 2. FIG. 15 is a diagram illustrating other examples of status information and a determination method according to the present embodiment. FIG. 16 is a flowchart illustrating an example of determination processing according to Example 3.

[0011] Hereinafter, an embodiment of the present invention (the present embodiment) will be described with reference to the drawings. Note that the embodiment described below is an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0012] 1 is a diagram showing an example of the configuration of a vehicle security analysis system according to this embodiment. The vehicle security analysis system 1 includes, for example, a Security Operation Center (SOC) server 10 and a Security Incident Response Team (SIRT) server 40 that can communicate with each other via a communication network.

[0013] The SOC server (vehicle security analysis device) 10 is, for example, an information processing device having a computer configuration, 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 on-board devices 21a, 21b, ... mounted on a vehicle 20 in order to detect cyber-attacks (hereinafter simply referred to as "attacks") against the vehicle 20, such as an automobile. In the following description, the term "on-board device 21" will be used to refer to any of the on-board devices 21a, 21b, ....

[0014] The SOC server 10 performs an analysis process 11 on the acquired sensor log data (hereinafter simply referred to as "log data"), and if it detects an attack on the vehicle 20, it sends a report including information about the detected attack to the SIRT server 40, etc.

[0015] 1 , the SOC server 10 acquires log data related to the on-board devices 21 mounted on the vehicles 20 from an original equipment manufacturing (OEM) server 30 or the like that collects log data 31 from one or more vehicles 20. However, this is not limited thereto, and the SOC server 10 may acquire log data related to the on-board devices 21 mounted on the vehicles 20 from one or more vehicles 20 without going through the OEM server 30.

[0016] The SOC server 10 can also acquire security information 51 from an external server 50 operated by, for example, Automotive Information Sharing and Analysis Center (Auto-ISAC) or the like via a communication network such as the Internet. This security information 51 includes various cybersecurity information such as cyberthreats and potential vulnerabilities related to connected cars. The SOC server 10 may detect an attack on the vehicle 20 based on the acquired log data 31 and security information 51.

[0017] In addition, the SOC server 10 may have a function to implement temporary measures against the vehicle 20 based on the acquired security information 51 or instructions from the SIRT server 40 when an attack against the vehicle 20 is detected.

[0018] The SIRT server 40 is an information processing device having a computer configuration or a system including multiple computers. The SIRT server 40 is a server operated by an organization (SIRT) that handles security against external threats to the safety of products manufactured and sold by, for example, a vehicle manufacturer or an in-vehicle device manufacturer, in order to ensure the safety of the products manufactured and sold by the manufacturer. The SIRT is also called a Product Security Incident Response Team (PSIRT) or a Computer Security Incident Response Team (CSIRT).

[0019] The SIRT server 40 has a function of, when a response policy determined for each manufacturer is input based on the report transmitted by the SOC server 10, implementing permanent measures including the response policy on the vehicle 20. The SIRT server 40 may also have a function of sharing security information 51 with an external server 50 and instructing the SOC server 10 or the vehicle 20 to take temporary measures on the vehicle 20 based on the security information 51.

[0020] 2 is a diagram illustrating an example of the analysis process according to the present embodiment. The SOC server 10 executes an analysis process 11 in which a plurality of analysis logics 201 are executed on log data 31 related to an in-vehicle device 21 mounted on the vehicle 20.

[0021] The plurality of analysis logics 201 are written for each attack to be detected. For example, if the analysis process 11 detects an attack using analysis logic B among the plurality of analysis logics 201, the SOC server 10 can identify the detected attack based on the description of analysis logic B. Preferably, the SOC server 10 generates a report 202 including information about the detected attack and outputs the generated report 202 to a predetermined output destination such as the SIRT server 40.

[0022] The log data 31 acquired by the SOC server 10 may contain false positive log data due to erroneous detection, in which an event that is not caused by a cyber attack is mistakenly detected as a cyber attack. Here, a false positive refers to a situation in which a normal state, operation, or the like is mistakenly detected as an abnormality in security threat detection.

[0023] When false positive log data 31 is input to the SOC server 10, the SOC server 10 executes multiple analysis logics 201 even though no attack has occurred, resulting in unnecessary analysis processing and a decrease in the accuracy of attack detection.

[0024] The technology disclosed in Patent Document 1 can reduce the occurrence of false positives. However, with the conventional technology, when a false positive occurs, the SOC server 10 cannot determine that the erroneously detected log data 31 is a false positive.

[0025] Therefore, the SOC server 10 according to this embodiment has a function of acquiring log data related to the on-board device 21 installed in the vehicle 20 and determining whether the acquired log data is a false positive based on status information indicating the status of the vehicle 20. Furthermore, the SOC server 10 executes the analysis process 11 by excluding log data 31 determined to be a false positive from the acquired log data 31.

[0026] As a result, the vehicle security analysis system 1 according to this embodiment can suppress unnecessary analysis processing 11 due to false positive log data 31 and improve the accuracy of attack detection.

[0027] <Hardware Configuration> The SOC server 10, the OEM server 30, the SIRT server 40, the external server 50, etc. described in Fig. 1 have, for example, the hardware configuration of a computer 300 as shown in Fig. 3. Alternatively, the SOC server 10, the OEM server 30, the SIRT server 40, the external server 50, etc. are configured by a plurality of computers 300.

[0028] 3 is a diagram illustrating an example of the hardware configuration of a computer according to an embodiment. The computer 300 includes, for example, a CPU (Central Processing Unit) 301, 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.

[0029] The CPU 301 is a processor that realizes various functions by executing programs stored in a storage medium such as the memory 302 or the storage device 303. The memory 302 includes, for example, a random access memory (RAM), which is a volatile memory used by the CPU 301 as a temporary storage area, and a read-only memory (ROM), which is a non-volatile memory that stores programs for starting up the CPU 301. The storage device 303 is, for example, a large-capacity non-volatile storage device such as a solid state drive (SSD) or a hard disk drive (HDD). The network I / F 304 includes one or more communication interfaces for connecting the computer 300 to a communication network.

[0030] The external connection I / F 305 is an interface for connecting an external device to the computer 300. The output device 306 is an output device (e.g., a display, a speaker, or a lamp) that outputs to the outside. The input device 307 is an input device (e.g., a keyboard, a mouse, or a microphone) that receives input from the outside. Note that the input device 307 and the output device 306 may be an integrated input / output device (e.g., a touch panel display). The internal bus 308 is commonly connected to the above components and transmits, for example, address signals, data signals, and various control signals.

[0031] <Functional Configuration> Next, the functional configuration of the vehicle security analysis system 1 according to this embodiment will be described.

[0032] (Functional Configuration of SOC Server) FIG. 4 is a diagram showing an example of the functional configuration of the SOC server according to this embodiment. The SOC server 10 realizes, for example, each functional configuration shown in FIG. 4 by executing a predetermined program on one or more computers 300 included in the SOC server 10. In the example of FIG. 4, the SOC server 10 includes an acquisition unit 401, a state information management unit 402, a determination unit 403, an analysis unit 404, and an output unit 405. Note that at least a portion of each of the above functional configurations may be realized by hardware.

[0033] In addition, as an example, the SOC server 10 stores a state information DB (Database) 411, an analysis logic DB 412, and the like in a storage unit such as the storage device 303 in Fig. 3. As another example, the SOC server 10 may use the state information DB (Database) 411 or the analysis logic DB 412 stored in an external storage server, cloud storage, or the like.

[0034] The acquisition unit 401 executes an acquisition process to acquire log data (sensor log data) 31 related to the on-board device 21 mounted on the vehicle 20. For example, the acquisition unit 401 acquires the log data 31 from an external server such as the OEM server 30 via a communication network. However, the acquisition unit 401 is not limited to this, and may acquire the log data 31 from the vehicle 20 via a communication network.

[0035] 5 is a diagram showing an example of log data according to this embodiment. In the example of FIG. 5, the log data 31 includes information such as "date and time," "vehicle identification number," "SENSOR," "SRC," "DST," etc. The "date and time" is information indicating the date and time when an event that caused the log data 31 was detected, the date and time when the log data 31 was generated, or the date and time when the log data 31 was transmitted. The vehicle identification number is identification information that identifies the vehicle 20, such as a VIN (Vehicle Identification Number).

[0036] "SENSOR", "SRC", "DST", etc. are examples of data included in the log data 31. "SENSOR" is identification information (sensor ID, etc.) that identifies a plurality of on-board devices 21 mounted on the vehicle 20, or a security sensor, etc. "SRC" is identification information (IP address, etc.) that identifies the sender of the communication that caused the generation of the log data 31. "DST" is identification information (IP address, etc.) that identifies the destination of the communication that caused the generation of the log data 31. Now, returning to FIG. 4 , we will continue to explain the functional configuration of the SOC server 10.

[0037] The state information management unit 402 executes a state information management process for managing state information indicating the state of each vehicle 20. For example, the state information management unit 402 estimates or identifies the state of the vehicle 20 from the log data 31 acquired by the acquisition unit 401, associates the state information indicating the state of the vehicle 20 with the vehicle identification number, and stores and manages the state information in the state information DB 411 or the like.

[0038] Alternatively, the state information management unit 402 may acquire the state of the vehicle 20 from the vehicle 20 or an external vehicle management system that manages the state of the vehicle 20, and manage state information indicating the state of the vehicle 20. Furthermore, the state information management unit 402 may estimate or identify the state of the vehicle 20 based on information acquired from the external vehicle management system or the vehicle 20, in addition to the log data 31 acquired by the acquisition unit 401.

[0039] The determination unit 403 executes a determination process to determine whether the log data 31 acquired by the acquisition unit 401 is log data 31 generated based on an event not attributable to a cyber-attack, based on status information indicating the status of the vehicle 20. Preferably, the determination unit 403 determines that the log data 31 generated based on an event not attributable to a cyber-attack is a false positive. Note that specific examples of the status information and the determination process executed by the determination unit 403 will be described later using multiple examples.

[0040] The analysis unit 404 performs an analysis process to analyze the log data 31 acquired by the acquisition unit 401, excluding log data 31 generated based on events not caused by a cyber attack (false positive log data 31).

[0041] As an example, the analysis unit 404 analyzes the log data 31 that has not been determined to be a false positive by the determination unit 403, using an analysis logic DB 412 as shown in FIG.

[0042] 6 is a diagram showing an example of an analysis logic DB according to this embodiment. As shown in Fig. 6, a plurality of analysis logics 201 are registered in advance in the analysis logic DB 412. The analysis unit 404 analyzes the log data 31 to be analyzed by executing the plurality of analysis logics 201 on the log data 31 to be analyzed.

[0043] As described above, multiple analysis logics 201 are written for each attack to be detected. For example, analysis logic No. 1 indicates that if the value of "SENSOR" in log data 31 is "1" and the value of "DST" is "10.0.0.1," the attack is "T001." Here, "T001" is identification information (such as an attack ID) that identifies the attack.

[0044] Furthermore, the analysis logic of No. 2 indicates that the attack is "T002" when the value of "SENSOR" in the log data 31 is "2" and the value of "SIGNATURE" is "1." Here, "SIGNATURE" is identification information (such as a signature ID) that identifies a signature, which is data used to detect malware, a specific communication pattern, a specific file, or the like.

[0045] The analysis unit 404 executes a plurality of analysis logics 201 on the log data 31 that the determination unit 403 has determined to be analyzed, and if an attack is detected, outputs information about the detected attack as the analysis result.

[0046] The above-described method of analyzing the log data 31 by the analysis unit 404 is an example. In this embodiment, the method of analyzing the log data 31 by the analysis unit 404 may be any other method.

[0047] The output unit 405 executes an output process to output the analysis result by the analysis unit 404 to a predetermined output destination. For example, the output unit 405 transmits the analysis result by the analysis unit 404 (e.g., report 202, etc.) to the SIRT server 40.

[0048] The functional configuration of the SOC server 10 shown in Fig. 4 is an example. For example, the functional components of the SOC server 10 shown in Fig. 4 may be distributed across multiple devices. In this case, the functional components of the SOC server 10 shown in Fig. 4 may be included in any of the devices included in the vehicle security analysis system 1.

[0049] Furthermore, if the state information managed by the state information management unit 402 is information that does not need to be stored, the SOC server 10 (or the vehicle security analysis system 1) may not have the state information DB 411. Furthermore, the state information management unit 402 may acquire and manage analysis determination information (e.g., security information 51) that is not based on the log data 31 from an external server 50 or the like.

[0050] [First Embodiment] Fig. 7 is a diagram illustrating an example of status information according to a first embodiment. For example, as shown in Fig. 7, the status information management unit 402 manages status information 701 indicating the status of each vehicle 20 in association with the vehicle identification numbers of the multiple vehicles 20. The example in Fig. 7 indicates that the status of the vehicle 20 with the vehicle identification number "JP000000000000005" is "under repair," and the status of the vehicles 20 with the vehicle numbers "JP000000000000006" and "JP000000000002000" is "out of order." Furthermore, "N / A" in the status information indicates that the status of the vehicle 20 is neither "under repair" nor "out of order."

[0051] Note that the status information 701 shown in FIG. 7 is an example for explanation purposes, and various other information indicating the status of the vehicle 20 can be used.

[0052] <Processing Flow> Next, a processing flow of the vehicle security analysis method according to the first embodiment will be described.

[0053] (Processing of SOC Server) Fig. 8 is a flowchart illustrating an example of processing of the SOC server according to the embodiment 1. This processing shows an overview of processing executed by the SOC server 10 having the functional configuration shown in Fig. 4, for example.

[0054] In step S801, the acquisition unit 401 acquires the log data 31 from the OEM server 30 or the like.

[0055] In step S802, the state information management unit 402 estimates or identifies the state of the vehicle 20 corresponding to the log data 31 based on the log data 31 acquired by the acquisition unit 401. For example, the state information management unit 402 executes a process of identifying or estimating the state of the vehicle 20 as shown in FIG.

[0056] 9 is a flowchart illustrating an example of a process for identifying or estimating the state of a vehicle according to the embodiment 1. This process is an example of a process executed by the state information management unit 402 in step S802 in FIG.

[0057] In step S901, the state information management unit 402 extracts information necessary for identifying or estimating the state of the vehicle 20 from the log data 31 acquired by the acquisition unit 401.

[0058] In step S902, the state information management unit 402 determines whether necessary information is available. For example, if the state information management unit 402 has extracted information necessary to identify or estimate the state of the vehicle 20 in step S901, the state information management unit 402 determines that necessary information is available. If necessary information is available, the state information management unit 402 proceeds to step S903. On the other hand, if necessary information is not available, the state information management unit 402 ends the process of FIG. 9, for example.

[0059] In step S903, the state information management unit 402 extracts the vehicle identification number that identifies the vehicle 20 from the log data 31 acquired by the acquisition unit 401.

[0060] In step S904, the state information management unit 402 identifies or estimates the state of the vehicle 20 based on the information extracted in step S901.

[0061] In step S905, the state information management unit 402 stores state information 701 indicating the state of the vehicle 20 in the state information DB 411 or the like in association with the vehicle identification number, for example, as shown in FIG.

[0062] 9 is an example of the process for identifying or estimating the state of the vehicle 20. For example, in step S901, the state information management unit 402 may acquire information necessary for identifying or estimating the state of the vehicle 20 from an external vehicle management system that manages the state of the vehicle 20, instead of from the log data 31.

[0063] 8, the description of the processing of the SOC server will be continued. In step S803, the determination unit 403 determines a false positive based on the state information indicating the state of the vehicle 20. As a specific example, the determination unit 403 executes a determination process as shown in FIG.

[0064] 10 is a flowchart illustrating an example of a determination process according to the embodiment 1. This process is an example of a process executed by the determination unit 403 in step S803 of FIG.

[0065] In step S1001, the determination unit 403 extracts the vehicle identification number from the log data 31 acquired by the acquisition unit 401. Note that the determination unit 403 may acquire the log data 31 acquired by the acquisition unit 401 from the state information management unit 402 or from the acquisition unit 401.

[0066] In step S1002, the determination unit 403 acquires the state information corresponding to the extracted vehicle identification number. For example, the determination unit 403 acquires the state information corresponding to the extracted vehicle identification number from the state information 701 shown in FIG.

[0067] In step S1003, the determination unit 403 determines whether status information is available. For example, if the determination unit 403 can acquire status information such as "out of order" or "under repair" from the status information 701 shown in FIG. 7, the determination unit 403 determines that status information is available. If status information is available, the determination unit 403 shifts the process to step S1004. On the other hand, if status information is not available, the determination unit 403 ends the process of FIG. 10.

[0068] When the process proceeds to step S1004, the determination unit 403 determines whether the vehicle 20 is "under repair" or "out of order." If the vehicle 20 is "under repair" or "out of order," the determination unit 403 proceeds to step S1005. On the other hand, if the vehicle 20 is neither "under repair" nor "out of order," the determination unit 403 ends the process of FIG. 10.

[0069] In step S1005, the determining unit 403 determines that the log data 31 acquired by the acquiring unit 401 is a false positive.

[0070] It should be noted that "under repair" and "out of order" are examples of status information indicating the status of the vehicle 20. The processes of steps S1003 to S1005 are also examples of a determination method for determining whether the log data 31 is a false positive based on the status information indicating the status of the vehicle 20. Other examples of status information and determination methods according to this embodiment will be described later.

[0071] 8, the description of the SOC server processing will be continued. In step S804, if the determination result by the determination unit 403 is not a false positive, the SOC server 10 executes the processing of steps S805 and S806. On the other hand, if the determination result by the determination unit 403 is a false positive, the SOC server 10 does not execute the processing of steps S805 and S806 and ends the processing of FIG. 8.

[0072] In step S805, the analysis unit 404 executes an analysis process for analyzing the log data 31 acquired by the acquisition unit 401. As a specific example, the analysis unit 404 executes an analysis process as shown in FIG.

[0073] 11 is a flowchart illustrating an example of analysis processing according to Example 1. This processing represents an example of processing executed by the analysis unit 404 in step S805 of FIG.

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

[0075] In step S1102, the analysis unit 404 acquires an analysis logic group (plurality of analysis logics 201) from, for example, the analysis logic DB 412 shown in FIG.

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

[0077] In step S1104, the analysis unit 404 determines whether there is any unselected analysis logic. For example, if the analysis unit 404 was able to select an unselected analysis logic in step S1103, it determines that there is any unselected analysis logic. If there is any unselected analysis logic, the analysis unit 404 shifts the process to step S1105. On the other hand, if there is no unselected analysis logic, the analysis unit 404 shifts the process to step S1106.

[0078] In step S1105, the analysis unit 404 executes the selected analysis logic on the log data 31 and returns the process to step S1103. Through the processes of steps S1103 to S1105, the analysis unit 404 executes, for example, all analysis logics included in the acquired analysis logic group on the log data 31 acquired by the acquisition unit 401.

[0079] In step S1106, the analysis unit 404 outputs the vehicle identification number extracted from the log data 31 acquired by the acquisition unit 401 and the analysis results analyzed in steps S1103 to S1105 to an output unit, etc. The analysis results include, for example, information (such as an attack ID) for identifying the attack detected by the analysis logic group.

[0080] Returning to FIG. 8 , the processing of the SOC server will now be further described. In step S806, the output unit 405 outputs the analysis results of the analysis unit 404 to a predetermined output destination. For example, the output unit 405 generates a report 202 including information on the attack detected in the analysis process 11 by the analysis unit 404 and the vehicle identification number of the vehicle 20 in which the attack was detected, and transmits the generated report 202 to the SIRT server 40, etc. Note that the report 202 may be generated in the analysis process 11 by the analysis unit 404, as described with reference to FIG. 2 .

[0081] In this way, the SOC server 10 according to the first embodiment can determine that the log data 31 relating to the vehicle 20 is a false positive based on the state information indicating the state of the vehicle 20 and can exclude the log data 31 from the target of the analysis process 11 .

[0082] 12 is a diagram illustrating an example of state information according to Example 2. As illustrated in Fig. 12 , the state information management unit 402 according to Example 2 manages, as state information 1201, information indicating whether or not log data 31 suggesting an attack has occurred, in association with the vehicle identification numbers of multiple vehicles 20.

[0083] 12, "FALSE" in the status information 1201 indicates that log data 31 strongly suggesting an attack has never been detected in the vehicle 20 corresponding to the vehicle identification number. On the other hand, "TRUE" in the status information 1201 indicates that log data 31 strongly suggesting an attack has been detected in the vehicle 20 corresponding to the vehicle identification number.

[0084] <Processing Flow> Next, a processing flow of a vehicle security analysis method according to Example 2 will be described. Note that the processing of the SOC server according to Example 2 may be similar to the processing of the SOC server according to Example 1 described with reference to Fig. 8. Furthermore, the analysis processing according to Example 2 may be similar to the analysis processing according to Example 1 described with reference to Fig. 11.

[0085] 13 is a flowchart illustrating an example of a management process of state information according to the embodiment 2. This process represents another example of the process executed by the state information management unit 402 in step S802 of FIG.

[0086] In step S1301 , the state information management unit 402 extracts the vehicle identification number from the log data 31 acquired by the acquisition unit 401 .

[0087] In step S1302, the state information management unit 402 acquires state information corresponding to the extracted vehicle identification number. For example, the state information management unit 402 acquires state information corresponding to the extracted vehicle identification number from state information 1201 as shown in FIG.

[0088] In step S1303, the state information management unit 402 determines whether the log data 31 acquired by the acquisition unit 401 or the acquired state information contains information suggesting an attack (cyber-attack) against the vehicle 20. For example, if the log data 31 acquired by the acquisition unit 401 contains information that strongly suggests an attack against the vehicle 20 and / or if the acquired state information is "TRUE", the state information management unit 402 determines that there is information suggesting an attack. On the other hand, if the log data 31 acquired by the acquisition unit 401 does not contain information that strongly suggests an attack against the vehicle 20 and the acquired state information is "FALSE", the state information management unit 402 determines that there is no information suggesting an attack.

[0089] If there is information suggesting an attack, the state information management unit 402 shifts the process to step S1304. On the other hand, if there is no information suggesting an attack, the state information management unit 402 shifts the process to step S1305.

[0090] In step S1304, the state information management unit 402 stores "TRUE" in the state information corresponding to the vehicle identification number.

[0091] On the other hand, when the process proceeds to step S1305, the state information management unit 402 stores "FALSE" in the state information corresponding to the vehicle identification number. Note that the state information management unit 402 may omit the process of step S1305 and maintain the state information corresponding to the vehicle identification number of the vehicle 20.

[0092] By the process of FIG. 13, the state information management unit 402 can store and manage, for example, state information 1201 as shown in FIG. 12 in the state information DB 411 or the like.

[0093] (Determination Process) Fig. 14 is a flowchart showing an example of the determination process according to the embodiment 2. This process shows another example of the process executed by the determination unit 403 in step S803 of Fig. 8, for example.

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

[0095] In step S1402, the determination unit 403 acquires the state information corresponding to the extracted vehicle identification number. For example, the determination unit 403 acquires the state information corresponding to the extracted vehicle identification number from the state information 1201 shown in FIG.

[0096] 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 shifts the process to step S1404. On the other hand, if the acquired status information is not "TRUE" (if it is "FALSE"), the determination unit 403 shifts the process to step S1405.

[0097] When the process proceeds to step S1404, the determination unit 403 determines that the log data 31 acquired by the acquisition unit 401 is a true positive. On the other hand, when the process proceeds to step S1405, the determination unit 403 determines that the log data 31 acquired by the acquisition unit 401 is a false positive. Note that the processing of step S1404 is optional and not essential.

[0098] In this way, the SOC server 10 according to the second embodiment can determine that the log data 31 relating to the vehicle 20 is a false positive based on the state information indicating the state of the vehicle 20 and can exclude the log data 31 from the target of the analysis process 11 .

[0099] (Other Examples of Status Information) The status information described in Examples 1 and 2 is an example. The vehicle security analysis system 1 may determine whether the log data 31 acquired by the acquisition unit 401 is a false positive by using various other status information such as those shown in FIG.

[0100] 15 is a diagram showing other examples of status information and a determination method according to this embodiment. As an example, the vehicle security analysis system 1 may use "vehicle location" as status information, as shown in FIG. 15. In this case, the status information management unit 402 may acquire location information indicating the location of the vehicle 20 from an external vehicle management system that manages the status of the vehicle 20, the vehicle 20, or the like. Alternatively, the status information management unit 402 may acquire location information indicating the location of the vehicle 20 from the log data 31.

[0101] For example, when the vehicle 20 is at a production base or a maintenance base for the vehicle 20, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 is a false positive, assuming that a large number of false positives occur due to production work or maintenance work.

[0102] Alternatively, when the vehicle 20 is near a location where a false positive occurred in the past, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 is a false positive. This is on the assumption that a false positive occurs due to specific conditions (road conditions, strong electric fields, electromagnetic interference, etc.) that depend on the geographical location.

[0103] 15 , the vehicle security analysis system 1 may use "whether the vehicle is under repair" as the status information. In this case, the status information management unit 402 may acquire information indicating whether the vehicle 20 is under repair from an external vehicle management system that manages the status of the vehicle 20, the vehicle 20, or the like. Alternatively, the status information management unit 402 may acquire information indicating whether the vehicle 20 is under repair from the log data 31.

[0104] For example, when the vehicle 20 is undergoing repair, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 is a false positive, assuming that a large number of false positives will occur during repair work.

[0105] As another example, the vehicle security analysis system 1 may use "presence or absence of a malfunction" as the status information, as shown in FIG. 15 . In this case, the status information management unit 402 may acquire the presence or absence of a malfunction of the vehicle 20 from an external vehicle management system that manages the status of the vehicle 20, the vehicle 20, or the like. Alternatively, the status information management unit 402 may acquire the presence or absence of a malfunction of the vehicle 20 from the log data 31. In this case, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 is a false positive when the vehicle 20 is malfunctioning. This is based on the assumption that a large number of false positives will occur during a malfunction.

[0106] 15 , the vehicle security analysis system 1 may use, as the status information, "whether the vehicle is connected to the outside." In this case, the status information management unit 402 may acquire information indicating whether the vehicle 20 is connected to an external network (such as the Internet or V2X) or an external device (such as a diagnostic device) from the vehicle 20, an external vehicle management system that manages the status of the vehicle 20, or the vehicle 20. Alternatively, the status information management unit 402 may acquire information indicating whether the vehicle 20 is connected to the outside from the log data 31.

[0107] V2X stands for "Vehicle to everything" and is a general term for technologies that connect the vehicle 20 to something (another vehicle, a pedestrian, infrastructure, a network, etc.) via communication and enable mutual cooperation. In this case, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 is a false positive when the vehicle 20 is not connected to the outside. This is based on the premise that attacks on the vehicle 20 are mostly external threats and other threats are acceptable.

[0108] As another example, the vehicle security analysis system 1 may use "whether the vehicle is in operation" as the status information, as shown in FIG. 15 . In this case, the status information management unit 402 may acquire information indicating whether the vehicle 20 is in operation from an external vehicle management system that manages the status of the vehicle 20, the vehicle 20, or the like. Alternatively, the status information management unit 402 may acquire information indicating whether the vehicle 20 is in operation from the log data 31. In this case, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 is a false positive when the vehicle 20 is in operation. This is based on the assumption that a large number of false positives will occur while the vehicle 20 is in operation.

[0109] 15, the vehicle security analysis system 1 may use "time elapsed since the start of driving" as the state information. In this case, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 within a predetermined time from the start of driving of the vehicle 20 is a false positive. This is on the assumption that the mechanical or electrical state of the vehicle 20 is unstable immediately after the start of driving of the vehicle 20, and a false positive occurs.

[0110] 15, the vehicle security analysis system 1 may use "the elapsed time since the end of driving" as the state information. In this case, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 within a predetermined time from the end of driving of the vehicle 20 is a false positive. This is based on the assumption that the mechanical or electrical state of the vehicle 20 is unstable immediately after the end of driving of the vehicle 20, and a false positive occurs.

[0111] As another example, the vehicle security analysis system 1 may use "whether or not a software update is in progress" as state information, as shown in FIG. 15 . In this case, the state information management unit 402 may acquire whether or not the vehicle 20 is undergoing a software update from an external vehicle management system that manages the state of the vehicle 20, the vehicle 20, or the like. Alternatively, the state information management unit 402 may acquire whether or not the vehicle 20 is undergoing a software update from the log data 31. In this case, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 is a false positive when the vehicle 20 is undergoing a software update. This is based on the assumption that the vehicle 20 is in a state different from normal during a software update, which may result in a false positive.

[0112] 15, the vehicle security analysis system 1 may use "vehicle acceleration" as state information. In this case, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 is a false positive if the change in acceleration of the vehicle 20 is outside a predetermined range. This is on the assumption that a sudden acceleration or deceleration of the vehicle 20 may destabilize the mechanical or electrical state of the vehicle 20, resulting in a false positive.

[0113] As another example, the vehicle security analysis system 1 may use "vehicle load" as the state information, as shown in Fig. 15. In this case, the determination unit 403 may determine that the log data 31 acquired by the acquisition unit 401 is a false positive if the load of the vehicle 20 is outside a predetermined range. This is on the assumption that overloading of the vehicle 20 may cause the mechanical or electrical state of the vehicle 20 to become unstable, resulting in a false positive.

[0114] As another example, the vehicle security analysis system 1 may use "statistical characteristics of driving" as state information, as shown in Fig. 15. In this case, the state information management unit 402 may acquire the statistical characteristics of driving of the vehicle 20 from an external system that manages the state or operation of the vehicle 20. In this case, the determination unit 403 may compare the driver model with the statistical characteristics of driving, and if there is little difference, determine that the log data 31 acquired by the acquisition unit 401 is a false positive.

[0115] Furthermore, the vehicle security analysis system 1 may combine the above-mentioned multiple pieces of status information to determine whether the log data 31 acquired by the acquisition unit 401 is a false positive.

[0116] 16 is a flowchart showing an example of a determination process according to the third embodiment. This process shows an example of an analysis process when there are multiple pieces of status information.

[0117] The processing of the SOC server according to the third embodiment may be similar to the processing of the SOC server according to the first embodiment described with reference to Fig. 8. The analysis processing according to the third embodiment may be similar to the analysis processing according to the first embodiment described with reference to Fig. 11. The state information management unit 402 is assumed to manage four pieces of state information: "Whether or not log data suggesting an attack has been generated," "Whether or not the vehicle is being repaired," "Whether or not a malfunction has occurred," and "Whether or not software is being updated."

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

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

[0120] In step S1603, the determination unit 403 determines whether log data suggesting an attack has been generated. For example, when the status information indicating "whether or not log data suggesting an attack has been generated" as shown in Fig. 12 is "TRUE," the determination unit 403 determines that log data suggesting an attack has been generated.

[0121] If log data suggesting an attack has occurred, the determination unit 403 shifts the process to step S1604. On the other hand, if log data suggesting an attack has not occurred, the determination unit 403 shifts the process to step S1605.

[0122] In step S1604, the determining unit 403 determines that the log data 31 acquired by the acquiring unit 401 is a false positive.

[0123] On the other hand, when the process proceeds to step S1605, the determination unit 403 determines whether the vehicle 20 is under repair, has a malfunction, or is undergoing a software update, based on the acquired status information. If the vehicle 20 is under repair, has a malfunction, or is undergoing a software update, the determination unit 403 proceeds to step S1604. On the other hand, if the vehicle 20 is not under repair, has a malfunction, or is not undergoing a software update, the determination unit 403 ends the process of FIG. 16 .

[0124] In this way, the determining unit 403 may combine a plurality of pieces of status information to determine whether the log data 31 acquired by the acquiring unit 401 is a false positive.

[0125] As described above, according to this embodiment, in a vehicle security analysis system that acquires and analyzes sensor log data related to on-board devices installed in a vehicle, it becomes possible to determine that erroneously detected sensor log data is a false detection.

[0126] Summary of Embodiments This specification discloses at least the following vehicle security analysis systems, vehicle security analysis methods, and programs: (1) A vehicle security analysis system comprising: an acquisition unit that acquires sensor log data related to an on-board device mounted on a vehicle; a determination unit that determines, based on status information indicating the status of the vehicle, whether the sensor log data acquired by the acquisition unit is sensor log data generated due to an event not attributable to a cyber-attack; an analysis unit that analyzes the sensor log data acquired by the acquisition unit while excluding sensor log data generated due to the event not attributable to the cyber-attack; and an output unit that outputs an analysis result by the analysis unit. (2) The vehicle security analysis system described in paragraph 1, comprising: a status information management unit that identifies or estimates the status of the vehicle based on the sensor log data acquired by the acquisition unit. (3) The vehicle security analysis system described in paragraph 1, comprising: a status information management unit that acquires information about the vehicle from the vehicle or an external server and manages the status information based on the vehicle information. (4) The vehicle security analysis system according to any one of paragraphs 1 to 3, wherein the determination unit determines sensor log data generated based on an event not attributable to the cyber-attack to be a false positive. (5) The vehicle security analysis system according to any one of paragraphs 1 to 4, wherein the status information includes information indicating whether the sensor log data suggesting a cyber-attack has ever occurred in the vehicle, and the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on an event not attributable to the cyber-attack if the sensor log data suggesting a cyber-attack has never occurred in the vehicle. (6) The vehicle security analysis system according to any one of paragraphs 1 to 5, wherein the status information includes information indicating whether the vehicle is under repair, has a breakdown, or is undergoing a software update, and the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on the event not attributable to the cyber-attack if the vehicle is under repair, has a breakdown, or is undergoing a software update.(7) The vehicle security analysis system according to any one of paragraphs 1 to 6, wherein the status information includes information indicating whether the vehicle is connected to an external network or an external device, and the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data that was generated based on an event that is not attributable to the cyber-attack if the vehicle is not connected to an external network or an external device. (8) The vehicle security analysis system according to any one of paragraphs 1 to 7, wherein the status information includes information that indicates a location of the vehicle, and the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data that was generated based on an event that is not attributable to the cyber-attack if the vehicle is located at a production base or maintenance base for the vehicle, or near a point where a false positive occurred in the past. (Item 9) A vehicle security analysis method, in which a computer executes the following steps: an acquisition process to acquire sensor log data related to an on-board device mounted on a vehicle; a determination process to determine, based on status information indicating the status of the vehicle, whether the sensor log data acquired in the acquisition process is sensor log data that occurred due to an event that is not attributable to a cyber-attack; an analysis process to analyze the sensor log data acquired in the acquisition process while excluding the sensor log data that occurred due to the event that is not attributable to the cyber-attack; and an output process to output the analysis result of the analysis process. (Item 10) A program, in which a computer executes the following steps: an acquisition process to acquire sensor log data related to an on-board device mounted on a vehicle; a determination process to determine, based on status information indicating the status of the vehicle, whether the sensor log data acquired in the acquisition process is sensor log data that occurred due to an event that is not attributable to a cyber-attack; an analysis process to analyze the sensor log data acquired in the acquisition process while excluding the sensor log data that occurred due to the event that is not attributable to the cyber-attack; and an output process to output the analysis result of the analysis process.

[0127] Although one embodiment of the present invention has been described in detail above, the present invention can be modified and applied in various ways within the scope of the gist described in the claims.

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

[0129] REFERENCE SIGNS LIST 1 Vehicle security analysis system 10 SOC server (vehicle security analysis device) 20 Vehicle 21, 21a, 21b In-vehicle device 31 Log data (sensor log data) 300 Computer 401 Acquisition unit 402 Status information management unit 403 Determination unit 404 Analysis unit 405 Output unit 411 Status information DB 412 Analysis logic DB 701, 1201 Status information

Claims

1. A vehicle security analysis system comprising: an acquisition unit that acquires sensor log data related to an on-board device mounted on a vehicle; a determination unit that determines whether the sensor log data acquired by the acquisition unit is sensor log data that has occurred due to an event not caused by a cyber-attack based on status information that indicates the status of the vehicle; an analysis unit that analyzes the sensor log data acquired by the acquisition unit while excluding the sensor log data that has occurred due to the event not caused by the cyber-attack; and an output unit that outputs the analysis results by the analysis unit.

2. A vehicle security analysis system as described in claim 1, further comprising a state information management unit that identifies or estimates the state of the vehicle based on the sensor log data acquired by the acquisition unit.

3. A vehicle security analysis system as described in claim 1, further comprising a status information management unit that acquires information about the vehicle from the vehicle or an external server, and manages the status information based on the vehicle information.

4. A vehicle security analysis system as described in claim 1, wherein the judgment unit judges sensor log data generated based on an event not caused by the cyber attack to be a false positive.

5. A vehicle security analysis system as described in any one of claims 1 to 4, wherein the status information includes information indicating whether or not sensor log data suggesting the occurrence of a cyber-attack has ever occurred in the vehicle, and when the sensor log data suggesting the occurrence of a cyber-attack has not occurred in the vehicle, the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data that has occurred based on an event not caused by the cyber-attack.

6. A vehicle security analysis system as described in any one of claims 1 to 4, wherein the status information includes information indicating whether the vehicle is undergoing repair, has a breakdown, or is undergoing a software update, and when the vehicle is undergoing repair, has a breakdown, or is undergoing a software update, the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on an event not caused by the cyber-attack.

7. A vehicle security analysis system as described in any one of claims 1 to 4, wherein the status information includes information indicating whether the vehicle is connected to an external network or an external device, and the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on an event not caused by the cyber-attack when the vehicle is not connected to an external network or an external device.

8. A vehicle security analysis system as described in any one of claims 1 to 4, wherein the status information includes information indicating the location of the vehicle, and the determination unit determines that the sensor log data acquired by the acquisition unit is sensor log data generated based on an event not caused by the cyber-attack when the location of the vehicle is a production or maintenance base for the vehicle, or when the location of the vehicle is near a point where a false positive occurred in the past.

9. A vehicle security analysis method, in which a computer executes the following steps: an acquisition process for acquiring sensor log data related to an on-board device mounted in a vehicle; a determination process for determining whether the sensor log data acquired in the acquisition process is sensor log data generated based on an event not caused by a cyber-attack, based on status information indicating the status of the vehicle; an analysis process for analyzing the sensor log data acquired in the acquisition process while excluding the sensor log data generated based on the event not caused by a cyber-attack; and an output process for outputting the analysis results obtained by the analysis process.

10. A program that causes a computer to execute the following steps: an acquisition process for acquiring sensor log data related to an on-board device installed in a vehicle; a determination process for determining whether the sensor log data acquired in the acquisition process is sensor log data that has occurred due to an event not caused by a cyber-attack, based on status information indicating the status of the vehicle; an analysis process for analyzing the sensor log data acquired in the acquisition process while excluding the sensor log data that has occurred due to the event not caused by the cyber-attack; and an output process for outputting the analysis results obtained by the analysis process.

Citation Information

Patent Citations

  • Analyzer

    JP2022138009A

  • Vehicle security analysis system, vehicle security analysis method, and program

    JP2025075389A

  • Equipment communication method and device, medium and electronic equipment

    CN113938302A

  • Cybersecurity response by a driver of a vehicle

    EP4184862A1

  • Vehicle diagnostic system

    JP2023132005A