Analysis support system, analysis support method and program

Abstract

To provide an analysis support system or the like capable of supporting efficient analysis for responding to vulnerabilities.SOLUTION: An analysis support system 100 for supporting analysis for responding to a vulnerability of software installed in a vehicle is provided with a data reception unit 21 for acquiring configuration information of each of a plurality of vehicle types equipped with software having a vulnerability, and a determination unit 22 for making a first determination for classifying the plurality of vehicle types into two or more groups based on the acquired vehicle type information of each of the plurality of vehicle types.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to an analysis support system, an analysis support method, and a program.

Background Art

[0002] There is known a technique for analyzing the risk of a device reported to have a vulnerability in the installed software. For example, Patent Document 1 discloses a threat analysis system and an analysis method that enable threat analysis more suitable for the security requirements of a system.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, there is room for improvement in the technique of Patent Document 1 in efficiently performing analysis for coping with vulnerabilities.

[0005] Therefore, the present disclosure provides an analysis support system, an analysis support method, and a program capable of supporting efficient performance of analysis for coping with vulnerabilities.

Means for Solving the Problems

[0006] An analysis support system according to an aspect of the present disclosure is an analysis support system that supports analysis for coping with vulnerabilities of software installed in a vehicle, and includes an acquisition unit that acquires vehicle type information of each of a plurality of vehicle types in which software having vulnerabilities is installed, and a determination unit that makes a first determination for classifying the plurality of vehicle types into two or more groups for the analysis based on the acquired vehicle type information of each of the plurality of vehicle types.

[0007] An analysis support method according to an aspect of the present disclosure is an analysis support method for supporting an analysis for coping with vulnerabilities of software installed in a vehicle, the method including obtaining vehicle type information for each of a plurality of vehicle types in which software having vulnerabilities is installed, and performing a determination for classifying the plurality of vehicle types into two or more groups for the analysis based on the vehicle type information for each of the plurality of obtained vehicle types.

[0008] A program according to an aspect of the present disclosure is a program for causing a computer to execute the above-described analysis support method.

Effect of the Invention

[0009] According to an aspect of the present disclosure, it is possible to realize an analysis support system or the like that can efficiently support an analysis for coping with vulnerabilities.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6A

Figure 6B

Figure 6C

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

MODE FOR CARRYING OUT THE INVENTION

[0011] (Background Leading to the Present Disclosure) Prior to the description of the embodiments of the present disclosure, the background leading to the present disclosure will be described.

[0012] In a vehicle, with the increase in the scale of software and the increase in the ratio of OSS (Open Source Software), it is necessary to continuously monitor whether new software vulnerabilities have been discovered even after the vehicle is shipped, and if there are corresponding vulnerabilities, it is necessary to take corresponding measures in view of the risks. Therefore, for example, as shown in Patent Document 1, various studies have been conducted to perform analysis for coping with vulnerabilities.

[0013] When a new vulnerability is discovered, for the vehicle models (target vehicle models) equipped with the target ECU, which is the ECU containing the vulnerability, it is necessary to confirm the risk for each vehicle model and take corresponding measures. It is assumed that there are many vehicle models equipped with the target ECU due to derivative models of vehicle models or horizontal expansion of ECUs. That is, it is assumed that it is necessary to check a plurality of ECUs and a plurality of vehicles for one piece of vulnerable software. Also, even for the same software, since the effective functions, arrangements, peripheral devices, etc. differ depending on the vehicle model equipped and the ECU equipped, it is assumed that the scope of objects to be considered for countermeasures is wide. Conducting a detailed impact analysis and examining countermeasure methods for each target vehicle model (that is, performing analysis for coping with vulnerabilities) is costly, so efficiency improvement is required. Note that the determination of the countermeasure method is performed by, for example, a person in charge (analyst).

[0014] However, Patent Document 1 does not disclose a technique for improving the efficiency of analysis for coping with such vulnerabilities.

[0015] Therefore, the inventors of the present application have earnestly studied how to support the efficient performance of analysis for coping with vulnerabilities, and have devised an analysis support system and the like described below. For example, the inventors of the present application have focused on the fact that the original vehicle model and the derivative vehicle model often have similar configurations, and have devised an analysis support system and the like that can solve the problem that the examination contents overlap between the original vehicle model and the derivative vehicle model and the efficiency of analysis decreases.

[0016] The analysis support system according to the first aspect of the present disclosure is an analysis support system that supports analysis for addressing vulnerabilities in software installed in vehicles, and includes an acquisition unit that acquires vehicle type information for each of a plurality of vehicle types in which software having vulnerabilities is installed, and a determination unit that makes a first determination for classifying the plurality of vehicle types into two or more groups for the analysis based on the acquired vehicle type information for each of the plurality of vehicle types.

[0017] Thereby, based on the vehicle type information, one or more vehicle types that can have the same countermeasure content can be classified into one group. That is, since the official in charge of the analysis only needs to perform the analysis for each of the two or more groups, the time required for the analysis can be reduced compared to the case where each of the plurality of vehicle types is analyzed individually. Therefore, the analysis support system can support the official in charge to efficiently perform the analysis for addressing vulnerabilities.

[0018] Further, for example, the analysis support system according to the second aspect is the analysis support system according to the first aspect, wherein the vehicle type information includes information indicating the vehicle configuration of the vehicle type, and the determination unit may make the first determination based on the degree of coincidence of the vehicle configurations of each of the plurality of vehicle types.

[0019] Thereby, vehicle types with similar vehicle configurations can be grouped into one group. Since vehicle types with similar vehicle configurations are considered to be able to have the same countermeasure content, the time required for the analysis of vehicle types with similar vehicle configurations can be reduced.

[0020] Further, for example, the analysis support system according to the third aspect is the analysis support system according to the second aspect, wherein the information indicating the vehicle configuration includes information regarding one or more devices arranged on the predicted attack path based on the vulnerability, and the determination unit may make the first determination based on the degree of coincidence of the one or more devices of each of the plurality of vehicle types.

[0021] As a result, one or more devices arranged on the attack path can group similar vehicle models into one group. Since it is considered that vehicle models with one or more similar devices arranged on the attack path can have the same countermeasure content, the time required for analyzing vehicle models with one or more similar devices arranged on the attack path can be reduced.

[0022] Also, for example, the analysis support system according to the fourth aspect is the analysis support system according to the third aspect, wherein the information indicating the vehicle configuration includes information on one or more predetermined points arranged on the attack path predicted based on the vulnerability, and the determination unit may perform the first determination based on the degree of coincidence of one or more predetermined points of each of the plurality of vehicle models.

[0023] As a result, vehicle models with similar predetermined points on the attack path can be grouped into one group. Since it is considered that vehicle models with similar predetermined points on the attack path can have the same countermeasure content, the time required for analyzing vehicle models with similar predetermined points on the attack path can be reduced.

[0024] Also, for example, the analysis support system according to the fifth aspect is the analysis support system according to the fourth aspect, wherein the predetermined point may include at least one of an entry point, a device having a security countermeasure function, and an attack target asset.

[0025] As a result, the time required for analyzing vehicle models with at least one of an entry point, a device having a security countermeasure function, and an attack target asset being similar can be reduced.

[0026] Also, for example, the analysis support system according to the sixth aspect is the analysis support system according to any one of the second aspect to the fifth aspect, wherein the vehicle model information includes information indicating whether the vehicle model is a derivative vehicle model, and the determination unit may perform the first determination based on whether each of the plurality of vehicle models is a derivative vehicle model.

[0027] As a result, for example, a derivative vehicle model and the original vehicle model from which it is derived can be grouped together. Since it is considered that the derivative vehicle model and the original vehicle model may have the same countermeasure content, the time required for analyzing the derivative vehicle model can be reduced.

[0028] Also, for example, the analysis support system according to the seventh aspect is an analysis support system according to any one of the second to sixth aspects, and the device equipped with the vulnerable software has a plurality of functions, and the determination unit may perform the first determination based on the similarity of the effective and invalid settings of each of the plurality of functions of the device in each of the plurality of vehicle models.

[0029] As a result, vehicle models with similar effective and invalid settings of the functions of the device can be grouped together. Since vehicle models with similar effective and invalid settings of the functions of the device may have the same countermeasure content, the time required for analyzing vehicle models with similar effective and invalid settings of the functions of the device can be reduced.

[0030] Also, for example, the analysis support system according to the eighth aspect is an analysis support system according to any one of the first to seventh aspects, and a plurality of determination conditions used for the first determination are set. The acquisition unit acquires a first vulnerability analysis result obtained by analyzing the vulnerability for each of the plurality of vehicle models equipped with the vulnerable software, and the determination unit performs the first determination based on a determination condition specified based on at least one of the vehicle model information and the first vulnerability analysis result among the plurality of determination conditions, or based on a combination of two or more determination conditions.

[0031] As a result, classification into groups can be performed using determination conditions corresponding to at least one of the vehicle model information and the first vulnerability analysis result, so that a plurality of vehicle models can be classified into more appropriate groups.

[0032] Further, for example, the analysis support system according to the ninth aspect is the analysis support system according to any one of the first to eighth aspects, wherein the acquisition unit further acquires information indicating the OTA (Over The Air) compatibility status in at least one of the vehicle type and the device equipped with the vulnerable software, and the determination unit may perform a second determination for classifying two or more vehicle types classified into the group into two or more sub-groups based on the information indicating the OTA compatibility status.

[0033] Thereby, the person in charge may determine the countermeasure content for each sub-group where the countermeasure content may be different. Therefore, the analysis support system can support the person in charge to determine the countermeasure content according to the OTA compatibility status.

[0034] Further, for example, the analysis support system according to the tenth aspect is the analysis support system according to the ninth aspect, wherein the determination unit determines whether the vehicle type is OTA compatible based on the information indicating the OTA compatibility status, and when the vehicle type is OTA compatible, further determines whether the device equipped with the vulnerable software is OTA compatible.

[0035] Thereby, based on the determination result of whether the vehicle type is OTA compatible and the determination result of whether the device is OTA compatible, a plurality of vehicle types can be classified into at least two or more sub-groups.

[0036] Further, for example, the analysis support system according to the eleventh aspect is the analysis support system according to any one of the first to tenth aspects, wherein the acquisition unit acquires, in each of the two or more classified groups, a second vulnerability analysis result of the vehicle type assuming that a countermeasure against the vulnerability of the software in the vehicle type included in the group has been executed, and the determination unit may exclude from the group a vehicle type in which the risk when assuming that the countermeasure has been executed is not lower than the risk before executing the countermeasure.

[0037] As a result, vehicle models that are considered to have errors in grouping can be excluded from the group. Therefore, a more accurate group can be created. This contributes to the person in charge determining more appropriate countermeasure content.

[0038] Also, for example, the analysis support system according to the 12th aspect may be the analysis support system according to any one of the 1st to 11th aspects, and may further include a notification unit that notifies the completion of the processing of the 1st determination by the determination unit.

[0039] As a result, the completion of the processing of the 1st determination can be notified to the person in charge. By such notification being performed, the person in charge can reduce time loss and can determine countermeasure content smoothly.

[0040] Also, for example, the analysis support system according to the 13th aspect may be the analysis support system according to any one of the 1st to 12th aspects, and may further include a display output unit for displaying the determination result of the determination unit on a display device.

[0041] As a result, the person in charge can use the determination result as a reference for determining countermeasure content. Therefore, the analysis support system can more effectively support the person in charge in efficiently performing analysis for coping with vulnerabilities.

[0042] Also, an analysis support method according to an aspect of the present disclosure is an analysis support method for supporting analysis for coping with vulnerabilities of software installed in a vehicle, acquiring vehicle type information of each of a plurality of vehicle models in which software having vulnerabilities is installed, and based on the vehicle type information of each of the plurality of acquired vehicle models, making a determination for classifying the plurality of vehicle models into two or more groups for the analysis. Also, a program according to an aspect of the present disclosure is a program for causing a computer to execute the above analysis support method.

[0043] As a result, the same effects as the above analysis support system are achieved.

[0044] Note that these general or specific aspects may be implemented in a system, method, integrated circuit, computer program, or non-transitory recording medium such as a CD-ROM readable by a computer, or may be implemented in any combination of a system, method, integrated circuit, computer program, or recording medium. The program may be pre-stored in the recording medium or may be supplied to the recording medium via a wide area communication network including the Internet or the like.

[0045] Hereinafter, embodiments will be specifically described with reference to the drawings.

[0046] Note that all of the embodiments described below show comprehensive or specific examples. The numerical values, shapes, components, arrangement positions and connection forms of the components, steps, order of steps, etc. shown in the following embodiments are merely examples and are not intended to limit the present disclosure. In addition, among the components in the following embodiments, the components not described in the independent claims are described as optional components.

[0047] Also, in each figure, substantially the same configuration is denoted by the same reference numeral, and overlapping descriptions are omitted or simplified.

[0048] Also, in this specification, numerical values and numerical ranges are not expressions representing only a strict meaning, but are expressions meaning that they include substantially equivalent ranges, for example, a difference of about several percent (or about 10%).

[0049] (Embodiment) Hereinafter, the analysis support system according to the present embodiment will be described with reference to FIGS. 1 to 17.

[0050] [1. Configuration of Analysis Support System] First, the configuration of the analysis support system according to this embodiment will be described with reference to FIGS. 1 to 6C. FIG. 1 is a diagram showing the configuration of the analysis support system 100 according to this embodiment. The analysis support system 100 is a system for supporting the analysis for coping with vulnerabilities of software installed in a vehicle.

[0051] As shown in FIG. 1, the analysis support system 100 includes a vulnerability analysis management system 1, a display device 30, an SBOM (Software Bill of Materials) monitoring unit 40, an SBOMDB 50, and a vehicle-related DB 60. The vulnerability analysis management system 1 is a system for efficiently performing an analysis for coping with a vulnerability when a new vulnerability of software is discovered, and includes a vulnerability analysis system 10 and a vulnerability management system 20.

[0052] The vulnerability analysis system 10 is a system that performs a vulnerability analysis on each device including the discovered vulnerability and performs a risk analysis based on the degree of impact and ease of attack. The vulnerability analysis system 10 outputs the vulnerability analysis result, which is the result of the risk analysis, to the vulnerability management system 20. FIG. 2 is a diagram for explaining the information acquired by the vulnerability management system 20 according to this embodiment.

[0053] As shown in FIG. 2, the vulnerability analysis result is the result of analyzing whether a certain vulnerability has an impact on vehicles (multiple vehicle models) of a certain OEM. As items, it includes the target vulnerability, ECUID, vehicle model ID, vehicle model-specific risk, and scenario. The vehicle model ID indicates an ID for specifying the vehicle model in which the ECU indicated by the ECUID that identifies the ECU including the target vulnerability is installed. When there are multiple vehicle models in which the ECU is installed, multiple IDs are included. The scenario includes a scenario ID, a threat scenario, an assumed attack path, a target asset (the asset to be attacked), ease of attack, degree of impact, and risk. Any known technology may be used for the analysis of each item of the scenario by the vulnerability analysis system 10. Each item of the scenario can be specified based on, for example, vehicle configuration information and software vulnerabilities.

[0054] In addition, the information within the thick frame shown in FIG. 2 is also described as vehicle type - specific analysis information. Also, although details will be described later, the ECU vehicle type - common information, ECU vehicle type - specific information, vehicle type information, and SBOM shown in FIG. 2 are information obtained by the vulnerability management system 20 reading from each DB.

[0055] Referring to FIG. 1 again, the vulnerability management system 20 is a system that executes processes for efficiently performing analysis to address vulnerabilities. The vulnerability management system 20 executes a process of grouping vehicle types (vehicle type - specific analysis information) for which the response methods to vulnerabilities are considered to be the same based on vehicle configuration information indicating the vehicle configuration of the vehicle type, etc. As a result, the processes for duplicate analysis and consideration are reduced, so that the efficiency of the analysis for addressing vulnerabilities can be realized. The vulnerability management system 20 may further execute a grouping process based on the vulnerability analysis results.

[0056] The vulnerability management system 20 includes a data reception unit 21, a determination unit 22, a notification unit 23, a display output unit 24, a user input unit 25, and a vulnerability management DB 26. Note that the analysis support system 100 only needs to include at least the data reception unit 21 and the determination unit 22.

[0057] The data reception unit 21 is a communication interface for receiving the vulnerability analysis result and / or the completion notification of the vulnerability analysis from the vulnerability analysis system 10. The data reception unit 21 receives, for example, the vulnerability analysis result shown in FIG. 2 from the vulnerability analysis system 10. The data reception unit 21 is configured to include, for example, a communication circuit (communication module).

[0058] Note that the data reception unit 21 is not limited to directly obtaining the vulnerability analysis result from the vulnerability analysis system 10. For example, the data reception unit 21 may obtain the vulnerability analysis result stored in the vulnerability management DB 26 or the like by the vulnerability analysis system 10 reading from the DB. The data reception unit 21 is an example of a data acquisition unit.

[0059] In addition, the data reception unit 21 acquires vehicle type information (refer to FIG. 6C described later) of each of a plurality of vehicle types equipped with software having vulnerabilities from the vehicle-related DB 60 or the like.

[0060] In addition, the data reception unit 21 may acquire ECU vehicle type-specific information (refer to FIG. 6C described later) and vehicle type information from the vehicle-related DB 60 or the like as information indicating the OTA (Over The Air) correspondence status in at least one of the target vehicle type and the device equipped with software having vulnerabilities.

[0061] The determination unit 22 determines and performs grouping of vehicle types (vehicle type-specific analysis information). For example, based on the configuration information of each target vehicle type, the determination unit 22 groups vehicle types (vehicle type-specific analysis information) that are considered to have the same response to vulnerabilities. It can also be said that the determination unit 22 makes a determination (first determination) for classifying the target vehicle types into two or more groups based on the configuration information of each target vehicle type. Note that the target vehicle types include, for example, two or more vehicles including the target ECU.

[0062] The determination unit 22 determines whether or not one vehicle type belongs to one group considered to have the same response to vulnerabilities by one or more combinations of the following determination methods. The determination conditions include at least one of "Condition 1. Degree of match of vehicle configuration (including parts and manufacturers)", "Condition 2. Whether it is a derivative vehicle type", "Condition 3. Degree of match of ECUs and modules appearing on the attack path", and "Condition 4. Degree of match of important points on the attack path".

[0063] Note that although it is not absolute depending on the conditions, the strictness of grouping is generally considered to tend to be (severe) Condition 1 > Condition 2 > Condition 3 > Condition 4 (greedy). In addition, the determination unit 22 may combine the functional characteristics of the target ECU in the determination. For example, the determination conditions may include "Condition 5. Similarity of the effective / invalid setting of the function of the target ECU".

[0064] "Condition 1. Degree of consistency of vehicle configuration (including parts and manufacturers)" includes the degree of consistency of the model numbers, manufacturer names, and connection information indicating the connection relationships of in-vehicle devices (ECUs) such as the TCU (Telematics Control Unit), IVI (In-Vehicle Infotainment), gateway (GW), and ADAS (Advanced Driver-Assistance Systems) equipped in the vehicle model. The degree of consistency may be, for example, the number of in-vehicle devices that match. The degree of consistency is an example of the degree of matching. The vehicle configuration can be obtained based on the vehicle configuration shown in FIG. 6C described later.

[0065] "Condition 2. Whether it is a derivative vehicle model" indicates whether the vehicle model is a derivative of another vehicle model. Whether it is a derivative vehicle model can be determined based on the origin shown in FIG. 6C described later.

[0066] "Condition 3. Degree of consistency of ECUs and modules appearing on the attack path" indicates the degree of consistency of ECUs and modules located on the assumed attack path included in the vulnerability analysis result. For example, the degree of consistency may be, for example, the number of ECUs and modules with the same function located on the assumed attack path. The degree of consistency is an example of the degree of matching. The ECUs and modules appearing on the attack path can be obtained from the assumed attack path shown in FIG. 2, the vehicle configuration shown in FIG. 6C, etc.

[0067] "Condition 4. Degree of consistency of important points on the attack path" indicates the degree of consistency of entry points, devices with security countermeasure functions (for example, devices with gateway or firewall functions), target assets of the attack, etc. For example, the degree of consistency may be, for example, the number of ECUs that match among the entry point, devices with security countermeasure functions, and target assets of the attack. At least one of the entry point, devices with security countermeasure functions, and target assets of the attack is an example of a predetermined point, and the degree of consistency is an example of the degree of matching.

[0068] "Condition 5. Similarity of enabling / disabling settings of functions of the target ECU" indicates the degree of similarity of the enabling / disabling settings of one or more functions of the target ECU. The enabling / disabling settings may vary depending on, for example, the vehicle model. The degree of similarity may be, for example, the number of identical functions among the enabled functions. The enabling / disabling settings of the functions of the target ECU can be obtained based on the function list shown in FIG. 6B described later.

[0069] The determination unit 22 may determine whether grouping is possible based on the degree of match of the vehicle configurations of each of the plurality of vehicle models according to Condition 1, or may determine whether grouping is possible based on the degree of match of one or more devices of each of the plurality of vehicle models according to Condition 3, or may determine whether grouping is possible based on the degree of match of one or more predetermined points of each of the plurality of vehicle models according to Condition 4.

[0070] The determination unit 22 may, for example, determine a method for selecting determination conditions according to the characteristics of the threat scenario (how each asset is attacked) of the target ECU. The characteristics include, for example, whether the target ECU is an entry point (an intrusion point from the outside), whether it holds the target asset of the attack, and the like.

[0071] For example, when the target ECU is an entry point and an ECU that holds the target asset of the attack, it is determined whether grouping is possible under Condition 5. When the target ECU is an entry point but does not hold the target asset of the attack, it may be determined whether grouping is possible with a combination of Conditions 3 and 5.

[0072] FIG. 3 is a diagram for explaining the concept of grouping according to the present embodiment. In grouping, a trade-off may occur depending on the accuracy (strictness) of the grouping. Whether to make the determination of grouping loose or strict, the former emphasizes efficiency and the latter emphasizes accuracy.

[0073] As shown in FIG. 3, as grouping policies, there are greedy grouping with loose grouping strictness and strict grouping with strict grouping strictness.

[0074] Greedy grouping tends to have a large number of vehicle models included in one group and a small number of groups. Also, the advantages of greedy grouping include high efficiency because the number of cases to be considered is reduced, and the disadvantages include the possibility of incorrect grouping, so reexamination may occur in some cases.

[0075] Strict grouping tends to have a small number of vehicle models included in one group and a large number of groups. Also, the advantages of strict grouping include a low possibility of incorrect grouping and the ability to appropriately consider necessary countermeasures, and the disadvantages include cases where even those with the same countermeasures are not grouped and efficiency cannot be achieved.

[0076] Depending on the combination of conditions used for grouping by the determination unit 22, the tendency of which grouping policy is stronger will differ.

[0077] The determination unit 22 may, for example, determine whether to group according to the value of the maximum risk of the vehicle model. The determination unit 22, for example, when the risk of the vehicle model is higher than a predetermined value (for example, risk 4, risk 5, etc.), determines by combining condition 1 and condition 5 because high-precision grouping is required. Also, the determination unit 22, when the risk is lower than the predetermined value (for example, risk 1), gives priority to expanding the grouping target over accuracy and combines condition 1 and condition 4. The determination unit 22, when the risk is medium (for example, risk 2 and risk 3, etc.), combines condition 3 and condition 5. Note that the combination of conditions is not limited to the above. For example, three or more conditions may be combined, or only one condition may be used.

[0078] Note that the determination unit 22 may perform a stricter determination (e.g., Conditions 1 and 5) as the number of vehicle models with a risk equal to or higher than the threshold value, or the number of pieces of vehicle model-specific analysis information, increases.

[0079] FIG. 4 is a diagram for explaining information output from the vulnerability management system 20 according to the present embodiment.

[0080] As shown in FIG. 4, the information includes a group ID and group information as shown by the thick frame. For example, the information may be information obtained by adding a group ID and group information to information indicating a vulnerability analysis result.

[0081] The group ID indicates the ID of the group to which the vehicle model is grouped for the target vulnerability (the software in which the vulnerability is discovered).

[0082] The group information is information on the group created as a result of grouping, and includes a target vulnerability, a group risk, a representative case, a belonging case, and a countermeasure ID.

[0083] One target vulnerability is included for each group ID, and indicates information (e.g., CVE number) for specifying the vulnerability targeted by the group.

[0084] One group risk is included for each group ID, and indicates the maximum risk value among the risks of each vehicle model belonging to the group. The group risk may be used, for example, to determine the priority of analysis by official A. Note that the group risk is determined, for example, by the determination unit 22.

[0085] One representative case is included for each group ID, and indicates vehicle model-specific analysis information for each vehicle model belonging to the group. It can also be said that the representative case indicates the vehicle model-specific analysis information to be analyzed by official A. As the representative case, vehicle model-specific analysis information of the vehicle model having the highest risk (i.e., the group risk) among the vehicle models included in the group may be set. Note that the representative case is determined, for example, by the determination unit 22.

[0086] The case included one or more for each group ID and indicates vehicle type IDs grouped into groups indicated by the group ID.

[0087] The countermeasure ID included one or more for each group ID and indicates an ID for specifying a countermeasure when a countermeasure for the group is registered.

[0088] When there are multiple group IDs included in the group information, the group information includes the above items as many as the number of group IDs.

[0089] Referring to FIG. 1 again, the notification unit 23 notifies the display output unit 24 of the completion of the group process (determination process) by the determination unit 22 and / or notifies the person in charge A by mail or the like.

[0090] The display output unit 24 outputs information for causing the display device 30 to display the determination result of the determination unit 22. The display output unit 24 outputs, for example, information for displaying the grouping result (for example, the group information shown in FIG. 5 described later or the vulnerability analysis result shown in FIG. 9) and the vulnerability analysis result (for example, any of the vulnerability analysis results shown in FIGS. 8, 9, and 17 described later) to the display device 30.

[0091] The user input unit 25 receives an input from the person in charge A. The user input unit 25 receives, for example, a response method, a response result, a response status (for example, an OTA response status), etc. as user input and registers (stores) them in the vulnerability management DB 26. The user input unit 25 includes a keyboard, a mouse, a touch panel, etc., but may have a configuration for receiving input by voice.

[0092] The vulnerability management DB 26 is a database that stores various information such as vulnerability analysis results, group information (grouping results), and response statuses. FIG. 5 is a diagram showing an example of group information according to the present embodiment.

[0093] As shown in FIG. 5, the group information includes a group ID, a subgroup ID, a target vulnerability, a group risk, a representative vehicle model, an affiliated case, and a countermeasure ID.

[0094] The group ID indicates an ID for identifying a group.

[0095] The subgroup ID indicates an ID for identifying a subgroup to be classified when classified into two or more subgroups within one group. In the example of FIG. 5, no subgroups are set for the groups with group IDs 0x0001 and 0x0002, and an example is shown where two subgroups with subgroup IDs 1 and 2 are set for the group with group ID 0x0003.

[0096] The group risk indicates the risk corresponding to the group. The group risk is set based on the risks of one or more vehicle models included in the group. As the group risk, for example, the maximum value of the risks of one or more vehicle models included in the group may be set.

[0097] The representative vehicle model indicates the ID of one representative vehicle model among one or more vehicle models included in the group. As the representative vehicle model, for example, the ID of the vehicle model with the maximum risk is set.

[0098] Referring to FIG. 1 again, the display device 30 is a device for displaying information from the vulnerability management system 20 to the official A. The display device 30 is realized by, for example, a liquid crystal display device, etc., but may also be realized by, for example, an audio output device (e.g., a speaker) that outputs sound by voice. The display device 30 and the audio output device are examples of a presentation device. The presentation mode of the information in the presentation device is not particularly limited.

[0099] When a new vulnerability is discovered, the SBOM monitoring unit 40 monitors, using SBOM data (software configuration information) such as the SBOMDB 50, whether there is a device (e.g., ECU) equipped with software that includes the vulnerability, and if there is a device equipped with the software, extracts information indicating the device. The SBOM monitoring unit 40 obtains information on vulnerable software from public information, for example. Then, when a device equipped with software that includes a vulnerability is registered in the SBOMDB 50, the SBOM monitoring unit 40 notifies the vulnerability analysis management system 1.

[0100] The SBOMDB 50 is a database that stores the software configuration information of each ECU. An SBOM is a list of the supplier name, component name, component version, dependencies, SBOM data creator, timestamp, and other unique identifiers of all software, including, for example, open source, used in each ECU installed in a vehicle. The SBOM also includes information on vulnerabilities and can be used for detecting component vulnerabilities.

[0101] The vehicle-related DB 60 is a database that manages information related to vehicles. In the present embodiment, the vehicle-related DB 60 manages the information shown in FIGS. 6A to 6C. FIG. 6A is a diagram showing an example of ECU vehicle model common information according to the present embodiment. FIG. 6B is a diagram showing an example of ECU vehicle model specific information according to the present embodiment. FIG. 6C is a diagram showing an example of vehicle model information according to the present embodiment. FIGS. 6A to 6C are design information stored in the vehicle-related DB 60 in advance.

[0102] As shown in FIG. 6A, the ECU vehicle model common information indicates information common to each vehicle model among the information related to the target ECU. The ECU vehicle model common information includes an ECUID, a model number, a manufacturer name, and a list of functions.

[0103] The ECUID indicates the ID of the target ECU.

[0104] The model number indicates the model number of the target ECU.

[0105] The manufacturer name indicates the manufacturer of the target ECU.

[0106] The function list indicates a list of each function that the target ECU has. The target ECU may have multiple functions. When the target ECU has an OTA function, the function list includes information related to the OTA function. The function list is an example of information indicating the OTA compatibility status.

[0107] As shown in Figure 6B, the ECU vehicle model specific information indicates the information specific to each vehicle model among the information related to the target ECU. In Figure 6B, it shows the vehicle model specific information of the target ECU with an ECUID of 0x87029. The ECU vehicle model specific information includes a vehicle model ID and a function list.

[0108] The vehicle model ID indicates the ID of the vehicle model in which the target ECU is installed. Figure 6B shows the case where the target ECU with an ECUID of 0x87029 is installed in three vehicle models with vehicle model IDs of 0x0001 to 0x0003.

[0109] The function list indicates a list of the functions that are effectively set among the functions that the target ECU has. In Figure 6B, for the vehicle model with a vehicle model ID of 0x0001, all the functions that the target ECU with an ECUID of 0x87029 has are effectively set. For the vehicle models with vehicle model IDs of 0x0002 and 0x0003, it shows an example where some of the functions that the target ECU with an ECUID of 0x87029 has are effectively set and other functions are invalidly set. Also, even for the same ECU, the functions that are effectively set can be different if the vehicle models are different.

[0110] As shown in Figure 6C, the vehicle model information indicates information related to the target vehicle model. The vehicle model information includes a vehicle model ID, a model code, a model name, a vehicle configuration, a function list, and a derivation source.

[0111] The vehicle model ID indicates the ID of the target vehicle model.

[0112] The model code indicates a model that can identify the grade, specifications, etc. of the vehicle type.

[0113] The model name indicates the model type, generation, etc. of the vehicle type.

[0114] The vehicle configuration (information indicating the vehicle configuration) indicates the configuration of the in-vehicle network within the vehicle. The vehicle configuration includes information indicating the in-vehicle devices mounted on the vehicle and their connection information. The in-vehicle devices include IVI, TCU, GW, ADAS control, various ECUs, etc. The connection information indicates the connection relationship between the in-vehicle devices. The vehicle configuration includes information about one or more devices or one or more predetermined points (important points) arranged on the attack path predicted based on vulnerability, for example.

[0115] The function list indicates the functions provided by the target vehicle or effectively set in the target vehicle. Examples of such functions include connected functions, OTA functions, etc. The function list is an example of information indicating the OTA support status.

[0116] When the vehicle type is a derivative vehicle type, the origin indicates the ID of the origin vehicle type. FIG. 6C shows an example where the vehicle type with vehicle type ID 0x0002 is a derivative vehicle type of the vehicle type with vehicle type ID 0x0001. Also, when the origin is blank or invalid data (for example, N / A), it indicates that there is no origin. That is, it indicates that the vehicle type is the parent vehicle type.

[0117] [2. Operation of the Analysis Support System] Subsequently, the operation of the analysis support system 100 configured as described above will be described with reference to FIGS. 7 to 17. FIG. 7 is a sequence diagram showing the operation (analysis support method) of the analysis support system 100 according to the present embodiment.

[0118] As shown in FIG. 7, when the SBOM monitoring unit 40 detects a new vulnerability from public information or the like (S11), it performs primary triage (S12). The SBOM monitoring unit 40 determines whether the corresponding vulnerability is installed based on the SBOM data, and outputs the determination result to the vulnerability analysis system 10 (S13). Whether a vulnerability is installed means determining whether there is a device (such as an ECU) in which the software in which the vulnerability was discovered is installed. Further, the determination result includes information indicating the device in which the software in which the vulnerability was discovered is installed.

[0119] Referring to FIG. 7 again, next, the vulnerability analysis system 10 confirms the vehicle model equipped with the ECU (target vehicle model) (S14), and analyzes the vulnerability of the vehicle model equipped with the ECU (S15). The vulnerability analysis system 10 outputs the vulnerability analysis result (first vulnerability analysis result) to the vulnerability management system 20 (S16). The data reception unit 21 of the vulnerability management system 20 acquires the vulnerability analysis result by receiving the vulnerability analysis result.

[0120] Note that in step S16, the vulnerability analysis system 10 may output at least the information indicating the target vulnerability among the items included in the vulnerability analysis result to the vulnerability management system 20. In this case, the vulnerability analysis system 10 stores the information of the other items that were not output to the vulnerability management system 20 in step S16 in each DB (for example, the vulnerability management DB 26), and the data reception unit 21 may acquire the information of the other items from each DB as needed.

[0121] FIG. 8 is a diagram showing the vulnerability analysis result before grouping according to the present embodiment. FIG. 8 shows the vulnerability analysis result when three vehicle models with vehicle model IDs 0x0001 to 0x0003 are determined as target vehicle models. For example, the information shown in FIG. 8 is output from the vulnerability analysis system 10 to the vulnerability management system 20. Note that the information output from the vulnerability analysis system 10 to the vulnerability management system 20 may not include the items of the group ID and the countermeasure ID.

[0122] As shown in FIG. 8, the vulnerability analysis results include the information of each item of the vulnerability analysis results shown in FIG. 2. Since the grouping determination process by the determination unit 22 has not been executed, "N / A" is set for the group ID and the countermeasure ID. In addition, two scenarios are included for vehicle types with vehicle type IDs of 0x0001 and 0x0002. Thus, in the analysis results of the vulnerability analysis system 10, there may be cases where two or more scenarios are included for one target vehicle type (one target ECU). In this case, for each of the two or more scenarios, the analysis of each item of the scenario shown in FIG. 2 is performed.

[0123] In addition, the vehicle type-based risk is set based on the risks of each of the two or more scenarios. As the vehicle type risk, for example, the maximum risk among the risks of each of the two or more scenarios is set.

[0124] In addition, the target asset may be information such as settlement information stored, or software such as control software.

[0125] In addition, in the example of FIG. 8, an example is shown in which a numerical value up to a maximum of 5 is set as the ease of attack.

[0126] Referring to FIG. 7 again, next, the determination unit 22 of the vulnerability management system 20 determines a group based on the configuration information of the vehicle of the ECU-mounted vehicle type (S17). The determination unit 22 determines whether or not grouping is possible using at least one of the above conditions, and sets the vehicle types that can be grouped into one group. Note that the number of vehicle types included in one group is not particularly limited and may be one or more.

[0127] Next, the determination unit 22 registers / updates the group information regarding the group in the vulnerability management DB 26 (S18). For example, when a new group is set in step S17, the determination unit 22 registers (stores) the group information regarding the group in the vulnerability management DB 26. Further, for example, when it is determined in step S17 to newly add a vehicle type to an existing group, the determination unit 22 updates the group information by adding the information of the added vehicle type to the already registered group information.

[0128] Note that when classified into a group, for one target vulnerability, one vehicle type is classified into, for example, only one group. That is, for one target vulnerability, the determination by the determination unit 22 may be made so that one vehicle type is not included in two or more groups.

[0129] FIG. 9 is a diagram showing the vulnerability analysis result after grouping according to the present embodiment.

[0130] As shown in FIG. 9, since the vehicle types with vehicle type IDs 0x0001 and 0x0002 are determined to be in one group, the same group ID is set. Thus, based on the determination result of step S17, the information of the vulnerability analysis result may be updated. Note that since the vehicle type with vehicle type ID 0x0003 is not classified into any group, the group ID remains "N / A".

[0131] Referring to FIG. 7 again, next, when the determination process by the determination unit 22 is completed, the notification unit 23 notifies the person in charge A that the process has been completed (S19). The notification unit 23 may notify the completion to the display output unit 24 or the mobile terminal owned by the person in charge A. Thereby, it is possible to notify the person in charge A that the grouping process has been completed.

[0132] Note that the display output unit 24 may display the group information, the vulnerability analysis result shown in FIG. 9, etc. on the display device 30 instead of, or together with, the notification by the notification unit 23.

[0133] Next, with reference to FIGS. 10 to 14, each example of the process of determining the group shown in FIG. 7 will be described. FIGS. 10 to 14 are flowcharts showing each example of the detailed operation (analysis support method) of step S17 shown in FIG. 7. The processes shown in FIGS. 10 to 14 are executed, for example, by the determination unit 22.

[0134] As shown in FIG. 10, the determination unit 22 extracts the vehicle type (target vehicle type) equipped with the ECU (target ECU) from among a plurality of vehicle types (S171), and acquires the vehicle configuration information (information indicating the vehicle configuration in FIG. 6C) of the extracted vehicle type from the vehicle type information of the extracted vehicle type (see FIG. 6C) (S172). When the determination unit 22 extracts two or more vehicle types, it acquires the vehicle configuration information of each of the two or more extracted vehicle types.

[0135] Next, the determination unit 22 compares the degree of coincidence of the configurations of each of the two or more extracted vehicle types based on the vehicle configuration information of each of the two or more extracted vehicle types (S173), and determines whether the degree of coincidence is equal to or greater than a threshold value (S174). When the determination unit 22 determines that the degree of coincidence is equal to or greater than the threshold value (Yes in S174), it assigns a group ID to the vehicle types as the same group (S175). The determination unit 22 determines each of the vehicle types with a degree of coincidence equal to or greater than the threshold value as the same group and assigns the same group ID. Further, when the determination unit 22 determines that the degree of coincidence is not equal to or greater than the threshold value (No in S174), it does not assign a group ID to the vehicle type, or assigns a group ID different from the case where Yes in step S174, and proceeds to step S176.

[0136] Next, the determination unit 22 determines whether the determination of all target vehicle models has been completed (S176). When the determination unit 22 determines that the determination of all target vehicle models has been completed (Yes in S176), it determines whether there is any addition / updating of groups (S177). The addition of a group indicates that a new group has been added, and the updating of a group indicates that a new vehicle model has been newly added to an existing group. When the determination unit 22 determines that there is addition / updating of a group (Yes in S177), it registers / updates the group information in the vulnerability management DB26 (S178). When it determines that there is no addition / updating of a group (No in S177), it ends the process.

[0137] Also, when the determination unit 22 determines that the determination of all target vehicle models has not been completed (No in S176), it returns to step S172 and continues the processes after step S172 for the next vehicle model.

[0138] In addition, when an OTA - compliant vehicle model and an OTA - non - compliant vehicle model are mixed in one group, the determination unit 22 may add information (for example, a flag) indicating that they are mixed to the group information and the like. Thereby, it can notify the person in charge A that they are mixed.

[0139] Note that the degree of configuration match between two or more vehicle models, whether each vehicle model is a derivative vehicle model, etc. do not depend on the target vulnerability. Therefore, the result of the group determination once performed may be stored as a past group record, and the group determination may be performed using the past group record.

[0140] Subsequently, the operation when narrowing down the target vehicle models to be analyzed based on whether the target vehicle model is a derivative vehicle model will be described with reference to FIG. 11.

[0141] As shown in FIG. 11, after step S171, the determination unit 22 determines whether or not the vehicle type (target vehicle type) is a derivative vehicle type based on the vehicle type information of the vehicle type (S271). The determination unit 22 determines whether or not it is a derivative vehicle type based on the information indicating the origin in the vehicle information of the vehicle type. In the example of FIG. 6C, among the vehicle type IDs from 0x0001 to 0X0004, only the vehicle type ID of 0x0002 is determined to be a derivative vehicle type.

[0142] Next, when the determination unit 22 determines that the vehicle type is a derivative vehicle type (Yes in S271), it proceeds to step S272, and when it determines that the vehicle type is not a derivative vehicle type (No in S271), it proceeds to step S176. When it is No in step S271, the determination regarding grouping is not performed for the vehicle type.

[0143] Next, the determination unit 22 acquires the vehicle configuration information of the target vehicle type and the origin vehicle type (S272). Then, in step S173, the determination unit 22 compares the degree of configuration match between the target vehicle type and the origin vehicle type.

[0144] Thereby, the number of vehicle types for which the determination of whether or not to group is to be made can be reduced, so that the processing amount of the determination unit 22 can be reduced. When it is expected that there are few differences for each derivative vehicle type depending on the vehicle manufacturer, etc., being a derivative vehicle type (being determined Yes in step S271) may be regarded as the same group, and steps S272, S173, and S174 may be skipped, and it may proceed from step S271 to step S175.

[0145] Subsequently, the operation of varying the determination conditions for grouping according to the value of the maximum risk will be described with reference to FIG. 12.

[0146] As shown in FIG. 12, after step S171, the determination unit 22 checks the maximum risk among vehicle types based on the vulnerability analysis result (S371), and determines whether the maximum risk is equal to or greater than a threshold value (S372). The determination unit 22 acquires the risk of each target vehicle type equipped with the ECU (target ECU) from the vulnerability analysis result, sets the largest risk among the acquired risks as the maximum risk, and determines whether the maximum risk is equal to or greater than the threshold value.

[0147] One maximum risk is set for one vulnerability, and the determination in step S372 is executed for each vulnerability.

[0148] Next, when the determination unit 22 determines that the maximum risk is equal to or greater than the threshold value (Yes in S372), it acquires the vehicle configuration information of the target vehicle type (here, for example, the ECU vehicle type specific information shown in FIG. 6B) from the vehicle relationship DB60 (S373), checks the valid functions of the target ECU based on the vehicle type configuration information of the target vehicle type (S374), and when it determines that the valid functions of the target ECU match (match in S374), it determines whether grouping is possible. Also, when the determination unit 22 determines that the valid functions of the target ECU do not match (do not match in S374), it proceeds to step S176. When there is no match in step S374, the determination regarding grouping is not performed for the vehicle type.

[0149] Thereby, the number of vehicle types to be determined whether to group can be reduced, so that the processing amount of the determination unit 22 can be reduced.

[0150] Also, when the determination unit 22 determines that the determination of all target vehicle types has not been completed (No in S176), it returns to step S373 and continues the processing after step S373 for the next vehicle type.

[0151] Further, when the determination unit 22 determines that the maximum risk is not equal to or greater than the threshold value (No in S372), it acquires an attack route corresponding to the maximum risk of each target vehicle type (S375). For example, the determination unit 22 acquires, as the attack route corresponding to the maximum risk, the attack route (assumed attack route) included in the vulnerability analysis result of the vehicle type having the maximum risk.

[0152] Next, the determination unit 22 acquires information on the entry point of its own vehicle type and important ECUs on the attack route based on the vehicle configuration information (S376). The important ECU may be, for example, an ECU having a security countermeasure function such as a gateway or an ECU having a firewall function, or an ECU that is a target asset to be attacked, or a combination thereof. The entry point and the important ECU are important points on the attack route.

[0153] Next, the determination unit 22 determines whether the entry point and the ECU that is an important point match (S377). If it determines that they match (match in S377), it proceeds to step S378. If it determines that they do not match (do not match in S377), it proceeds to step S379.

[0154] Note that the operations in steps S378 to S381 are the same as the operations in steps S175 to S178, so the description thereof is omitted.

[0155] In this way, when the risk is high, the determination unit 22 makes a determination using conditions (conditions 1 and 5 in the example of FIG. 12) that perform more accurate grouping. When the risk is low, the determination unit 22 makes a determination using conditions (condition 4 in the example of FIG. 12) that prioritize expanding the grouping target. Note that the vulnerability management DB 26 stores a table in which the maximum risk and the conditions used for determination are associated with each other, and the determination unit 22 may determine the determination conditions based on the table. In the above description, conditions 1 and 5 and condition 4 are used, but the conditions used and the combinations of conditions are not limited to this. Also, three or more conditions or combinations of conditions may be set according to the risk.

[0156] Next, with reference to FIG. 13, the operation when using stricter determination conditions as the number of vehicle models with a risk equal to or higher than the threshold is larger will be described.

[0157] As shown in FIG. 13, after step S171, the determination unit 22 acquires the number of vehicle models with a maximum risk equal to or higher than the threshold (S471). For example, the determination unit 22 may acquire the number of vehicle models by comparing the maximum risk of each vehicle model (target vehicle model) equipped with the ECU (target ECU) with the threshold. The maximum risk of a vehicle model is, for example, the risk indicated by the risk for each vehicle model.

[0158] Next, the determination unit 22 determines whether the number of vehicle models acquired in step S471 is equal to or higher than the threshold (S472). If it is determined that the number of vehicle models is equal to or higher than the threshold (Yes in S472), the process proceeds to step S373. If it is determined that the number of vehicle models is less than the threshold (No in S472), the process proceeds to step S375. Since the subsequent processing is the same as that in FIG. 12, the description thereof is omitted.

[0159] As described above, when the number of vehicle models with a maximum risk equal to or higher than the threshold is large, the determination unit 22 performs determination using conditions (conditions 1 and 5 in the example of FIG. 13) that perform more accurate grouping. When the number of vehicle models with a maximum risk equal to or higher than the threshold is small, the determination unit 22 performs determination using conditions (condition 4 in the example of FIG. 13) that prioritize expanding the grouping target. Note that the vulnerability management DB 26 stores a table in which the number of vehicle models with a maximum risk equal to or higher than the threshold is associated with the conditions used for determination, and the determination unit 22 may determine the determination conditions based on the table. In the above description, conditions 1 and 5 and condition 4 are used, but the conditions used and the combinations of conditions are not limited thereto. Also, three or more conditions or combinations of conditions may be set according to the number of vehicle models.

[0160] As shown in FIGS. 12 and 13 described above, the determination unit 22 may perform a first determination based on a determination condition or a combination of two or more determination conditions specified based on at least one of vehicle model information and a vulnerability analysis result among a plurality of determination conditions.

[0161] Next, the operation when using the determination conditions according to the characteristics of the threat scenario of the target ECU will be described with reference to FIG. 14.

[0162] As shown in FIG. 14, after step S171, the determination unit 22 acquires attack route / asset information / vehicle configuration information of the vehicle type (target vehicle type) equipped with the ECU (target ECU) from the vehicle-related DB 60 (S571), and determines whether the target ECU is an entry point based on the acquired information (S572). When the determination unit 22 determines that the target ECU is an entry point (Yes in S572), it proceeds to step S573; when it determines that the target ECU is not an entry point (No in S572), it proceeds to step S173.

[0163] Next, when the determination unit 22 determines that the target ECU is an entry point, it further determines whether the target ECU has the target asset of the attack (S573). When the determination unit 22 determines that the target ECU has the target asset of the attack (Yes in S573), it further checks the valid functions of the target ECU (S574). When the determination unit 22 determines that the valid functions of the target ECU match (match in S574), it proceeds to step S577; when it determines that the valid functions of the target ECU do not match (do not match in S574), it proceeds to step S578.

[0164] Also, when the determination unit 22 determines that the target ECU does not have the target asset of the attack (No in S573), it compares the attack route and the target asset (S575), and determines whether the degree of coincidence is equal to or greater than the threshold value (S576).

[0165] Note that the operations in steps S576 to S580 are the same as the operations in steps S174 to S178, so the description is omitted.

[0166] In this way, the determination unit 22 may use determination conditions according to the characteristics of the threat scenario of the target ECU, such as whether the target ECU is an entry point or whether the target ECU holds the target asset of the attack.

[0167] Next, the processing after the group determination will be described with reference to FIGS. 15 to 17. First, the process of classifying a plurality of vehicle models included in one group into two or more sub-groups will be described with reference to FIG. 15. FIG. 15 is a flowchart showing an operation (analysis support method) for determining a sub-group after the group determination according to the present embodiment. Steps S601 to S607 shown in FIG. 15 are executed between steps S17 and S18 shown in FIG. 7. Also, the processing shown in FIG. 15 may be executed for each of the plurality of groups created in step S17.

[0168] As shown in FIG. 15, the determination unit 22 acquires the OTA support status for the vehicle models within the group (S601). The determination unit 22 acquires the OTA support status for each of the one or more vehicle models based on the vehicle model information (see FIG. 6C) of each of the one or more vehicle models included in the group.

[0169] Next, the determination unit 22 determines whether the support status is the same for all vehicle models included in the group (S602). Whether it is the same means, for example, that each of whether the vehicle model supports OTA and whether the target ECU supports OTA is the same. When the determination unit 22 determines that the support status is the same for all vehicle models included in the group (Yes in S602), it is considered that the countermeasures for all vehicle models are common, and the process ends. Also, when the determination unit 22 determines that the support status is not the same for all vehicle models included in the group (No in S602), for each of all vehicle models, it is determined whether the vehicle model (vehicle) supports OTA based on the vehicle information (S603).

[0170] When the determination unit 22 determines that the vehicle type (vehicle) supports OTA (Yes in S603), it further determines whether the target ECU supports OTA based on the ECU vehicle type specific information (see FIG. 6B) (S604). When the determination unit 22 determines that the target ECU supports OTA (Yes in S604), it sets subgroup 1 for the vehicle type (S605). When the determination unit 22 determines that the target ECU does not support OTA (No in S604), it sets subgroup 2 for the vehicle type (S606). Further, when the determination unit 22 determines that the vehicle type (vehicle) does not support OTA (No in S603), it sets subgroup 3 for the vehicle type (S607).

[0171] Next, the determination unit 22 registers / updates the group information in the vulnerability management DB 26 according to the setting result of the subgroup (S608). The determination unit 22 registers the ID corresponding to the set subgroup in the subgroup ID included in the group information.

[0172] Here, the countermeasures for each vehicle type in the three subgroups may be different. For example, the vehicle types included in subgroup 1 can, for example, address the vulnerability of the target ECU through communication updates or the like. Also, for the vehicle types included in subgroup 2, for example, if an ECU other than the target ECU and located on the attack path to the target ECU supports OTA, it can be addressed by performing updates or the like to improve the security performance of the OTA-supported ECU. Also, for the vehicle types included in subgroup 3, since communication-based countermeasures cannot be applied, it can be addressed, for example, by bringing it to a repair shop or the like.

[0173] In this way, the determination unit 22 classifies one group into three subgroups with potentially different countermeasures according to the OTA support status of each of the vehicle type and the target ECU. Note that the number of subgroups divided is not limited to three, and may be two or four or more. Also, it is sufficient that the countermeasures for at least one of the plurality of subgroups are different from the countermeasures of the other subgroups.

[0174] Note that the process of classifying into subgroups may be executed, for example, based on an instruction by official A, or may be executed for a group including a predetermined number or more of vehicle models.

[0175] Note that the determination unit 22 may further determine the OTA compatibility of important ECUs such as the entry point and the gateway, and classify them into subgroups according to the determination result. The determination unit 22 may determine the OTA compatibility of the ECUs on the attack path to the target ECU or the ECUs around the target ECU (for example, the ECUs connected to the target ECU) based on the vehicle model information. In this case, the vehicle models determined to be OTA-compatible and the vehicle models determined to be non-OTA-compatible are classified into different subgroups.

[0176] Subsequently, the process of examining the countermeasures determined by official A will be described with reference to FIG. 16. FIG. 16 is a flowchart showing the operation (analysis support method) of examining the countermeasures according to the present embodiment.

[0177] As shown in FIG. 16, the determination unit 22 determines whether or not the vehicle model belongs to a group (whether or not it belongs to a group) (S701).

[0178] Next, when the determination unit 22 determines that the vehicle model does not belong to a group (No in S701), it registers countermeasures for the specified vehicle model information (for example, vulnerability analysis results) (S702), and requests a vulnerability analysis from the vulnerability analysis system 10 for the vehicle model of the specified vehicle model information (S703).

[0179] FIG. 17 is a diagram showing the vulnerability analysis results after registering countermeasures according to the present embodiment. FIG. 17 shows an example in which countermeasures are registered (added) to the vulnerability analysis results.

[0180] As shown in FIG. 17, an ID corresponding to the registered countermeasure is added to the countermeasure ID in the vulnerability analysis result. In FIG. 17, the countermeasure IDs of vehicle types with vehicle type IDs 0x0001 and 0X0002 having the same group ID are the same. Also, the countermeasure ID of the vehicle type with vehicle type ID 0x0003 for which the group ID is not set is different from the countermeasure IDs of the vehicle types with vehicle type IDs 0x0001 and 0X0002. Note that the display output unit 24 may display the information shown in FIG. 17 on the display device 30.

[0181] Also, when the determination unit 22 determines that the vehicle type belongs to a group (Yes in S701), it refers to the group information of the group to which the vehicle type belongs (S704). The determination unit 22 acquires the group information of the group from, for example, the vulnerability management DB 26.

[0182] Next, the determination unit 22 registers countermeasures in the vehicle type-specific information of each vehicle type belonging to the group (S705), and requests a vulnerability analysis to the vulnerability analysis system 10 for each vehicle type (S706). Then, the data reception unit 21 acquires the vulnerability analysis results (second vulnerability component results) of each vehicle type from the vulnerability analysis system 10 (S707). The data reception unit 21 can also be said to acquire the vulnerability analysis results of the corresponding vehicle types when it is assumed that countermeasures against software vulnerabilities in the target vehicle types included in the group are executed in each of two or more classified groups, for example.

[0183] Note that at this point, the countermeasures are not determined, and the vulnerability analysis system 10 performs a vulnerability analysis of each vehicle type assuming that the countermeasures determined by the person in charge A are executed. The risk of the vehicle types included in the result of the vulnerability analysis is also described as the updated risk.

[0184] Next, the determination unit 22 checks the post-update risks within the group (S708) and determines whether there is a vehicle type for which the risk has not decreased (S709). The determination unit 22 determines for each vehicle type whether the risk decreases compared to before the countermeasure is executed assuming that the countermeasure for the vehicle type is executed. When the determination unit 22 determines that there is a vehicle type for which the risk has not decreased (Yes in S709), it updates the group (S710). The determination unit 22 excludes the vehicle type for which the risk has not decreased from the group. The determination unit 22, for example, deletes the vehicle type ID of the vehicle type for which the risk has not decreased from the group information. Further, the determination unit 22 may add information indicating that the risk has not decreased to the vehicle type information of the excluded vehicle type, etc.

[0185] Also, when the determination unit 22 determines that there is no vehicle type for which the risk has not decreased (No in S709), it proceeds to step S711.

[0186] Next, the notification unit 23 notifies the person in charge A of the results of the vulnerability analysis by the vulnerability analysis system 10, the updated group information, etc. (S711). Thereby, the person in charge A can know how the risk, group, etc. change due to the countermeasure determined by himself / herself, that is, whether the countermeasure is effective. Such information can be effective information when the person in charge A finally determines the countermeasure.

[0187] (Other embodiments) As described above, the analysis support system etc. according to one or more aspects have been described based on the embodiments. However, the present disclosure is not limited to this embodiment. As long as the gist of the present disclosure is not deviated from, various modifications conceived by those skilled in the art applied to this embodiment or forms constructed by combining components in different embodiments may also be included in the present disclosure.

[0188] For example, in the above embodiments and the like, each component may be configured by dedicated hardware or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or a processor reading and executing a software program recorded on a recording medium such as a hard disk or a semiconductor memory.

[0189] Also, the order in which each step in the flowchart is executed is for illustrative purposes to specifically describe the present disclosure, and may be an order other than the above. Also, some of the above steps may be executed simultaneously (in parallel) with other steps, or some of the above steps may not be executed.

[0190] Also, the division of the functional blocks in the block diagram is an example, and a plurality of functional blocks may be realized as one functional block, one functional block may be divided into a plurality, or some functions may be transferred to other functional blocks. Also, the functions of a plurality of functional blocks having similar functions may be processed by a single piece of hardware or software in parallel or in time division.

[0191] Also, the vulnerability analysis system according to the above embodiment may be realized as a single device or may be realized by a plurality of devices. When the vulnerability analysis system is realized by a plurality of devices, each component of the vulnerability analysis system may be distributed among the plurality of devices in any manner. When the vulnerability analysis system is realized by a plurality of devices, the communication method between the plurality of devices is not particularly limited, and may be wireless communication or may be wired communication. Also, wireless communication and wired communication may be combined between the devices.

[0192] Further, each component described in the above embodiments may be implemented as software, or typically, may be implemented as an LSI which is an integrated circuit. These may be integrated into individual chips, or may be integrated into one chip so as to include some or all of them. Here, an LSI is mentioned, but depending on the degree of integration, it may also be referred to as an IC, a system LSI, a super LSI, or an ultra LSI. Also, the method of integrating circuits is not limited to LSI, and it may be implemented by a dedicated circuit (a general-purpose circuit that executes a dedicated program) or a general-purpose processor. After manufacturing the LSI, an FPGA (Field Programmable Gate Array) that can be programmed, or a reconfigurable processor that can reconfigure the connection or setting of circuit cells inside the LSI may be used. Furthermore, if a technology for integrating circuits that replaces the LSI appears due to the progress of semiconductor technology or a derived alternative technology, naturally, the integration of components may be performed using that technology.

[0193] A system LSI is a super multi-functional LSI manufactured by integrating a plurality of processing units on one chip. Specifically, it is a computer system including a microprocessor, a ROM (Read Only Memory), a RAM (Random Access Memory), etc. A computer program is stored in the ROM. By operating according to the computer program, the microprocessor enables the system LSI to achieve its functions.

[0194] Also, one aspect of the present disclosure may be a computer program that causes a computer to execute each characteristic step included in the analysis support method shown in any one of FIGS. 7 and 10 to 16.

[0195] Also, for example, the program may be a program for causing a computer to execute. Further, one aspect of the present disclosure may be a computer-readable non-transitory recording medium on which such a program is recorded. For example, such a program may be recorded on a recording medium and distributed or circulated. For example, the distributed program may be installed in a device having another processor, and by causing the processor to execute the program, it becomes possible to cause the device to perform each of the above processes.

Industrial Applicability

[0196] The present disclosure is useful for a system or the like for coping with vulnerabilities of software mounted on a vehicle.

Explanation of Signs

[0197] 1 Vulnerability Analysis Management System 10 Vulnerability Analysis System 20 Vulnerability Management System 21 Data Reception Unit (Acquisition Unit) 22 Determination Unit 23 Notification Unit 24 Display Output Unit 25 User Input Unit 26 Vulnerability Management DB 30 Display Device 40 SBOM Monitoring Unit 50 SBOMDB 60 Vehicle-Related DB 100 Analysis Support System A Responsible Officer

Claims

1. An analysis support system for supporting analysis to address vulnerabilities in software installed in a vehicle, comprising: an acquisition unit that acquires vehicle type information for each of a plurality of vehicle types in which software having vulnerabilities is installed; a determination unit that performs a first determination for classifying the plurality of vehicle types into two or more groups for the analysis based on the acquired vehicle type information for each of the plurality of vehicle types. The analysis support system.

2. The vehicle type information includes information indicating the vehicle configuration of the vehicle type, and the determination unit performs the first determination based on the degree of coincidence of the vehicle configurations of each of the plurality of vehicle types. The analysis support system according to Claim 1.

3. The information indicating the vehicle configuration includes information regarding one or more devices arranged on an attack path predicted based on the vulnerability, and the determination unit performs the first determination based on the degree of coincidence of the one or more devices of each of the plurality of vehicle types. The analysis support system according to Claim 2.

4. The information indicating the vehicle configuration includes information regarding one or more predetermined points arranged on an attack path predicted based on the vulnerability, and the determination unit performs the first determination based on the degree of coincidence of the one or more predetermined points of each of the plurality of vehicle types. The analysis support system according to Claim 3.

5. The predetermined points include at least one of an entry point, a device having a security countermeasure function, and an attack target asset. The analysis support system according to Claim 4.

6. The vehicle type information includes information indicating whether the vehicle type is a derivative vehicle type, and the determination unit performs the first determination based on whether each of the plurality of vehicle types is a derivative vehicle type. The analysis support system according to Claim 2.

7. The device in which software having vulnerabilities is installed has a plurality of functions, and the determination unit performs the first determination based on the similarity of the valid and invalid settings of each of the plurality of functions of the device in each of the plurality of vehicle types. The analysis support system according to Claim 2.

8. A plurality of determination conditions used for the first determination are set, and the acquisition unit acquires a first vulnerability analysis result obtained by analyzing the vulnerability for each of the plurality of vehicle types in which software having vulnerabilities is installed. The determination unit performs the first determination based on a determination condition specified based on at least one of the vehicle type information and the first vulnerability analysis result among a plurality of determination conditions, or a combination of two or more determination conditions. The analysis support system according to claim 1.

9. The acquisition unit further acquires information indicating the OTA (Over The Air) compatibility status in at least one of the vehicle type and the device equipped with vulnerable software. The determination unit performs a second determination for classifying two or more vehicle types classified into the group into two or more subgroups based on the information indicating the OTA compatibility status. The analysis support system according to any one of claims 1 to 8.

10. The determination unit determines whether the vehicle type is OTA compatible based on the information indicating the OTA compatibility status, and when the vehicle type is OTA compatible, further determines whether the device equipped with vulnerable software is OTA compatible. The analysis support system according to claim 9.

11. The acquisition unit acquires, in each of the two or more classified groups, a second vulnerability analysis result of the vehicle type assuming that a countermeasure against the vulnerability of the software in the vehicle type included in the group has been executed. The determination unit excludes, from the group, vehicle types for which the risk when assuming that the countermeasure has been executed is not lower than the risk before the execution of the countermeasure. The analysis support system according to any one of claims 1 to 8.

12. The system further includes a notification unit that notifies of the completion of the process of the first determination by the determination unit. The analysis support system according to any one of claims 1 to 8.

13. The system further includes a display output unit for causing a display device to display the determination result of the determination unit. The analysis support system according to any one of claims 1 to 8.

14. An analysis support method for supporting an analysis for coping with vulnerabilities of software mounted on a vehicle, comprising: acquiring vehicle type information of each of a plurality of vehicle types equipped with vulnerable software; performing a determination for classifying the plurality of vehicle types into two or more groups for the analysis based on the acquired vehicle type information of each of the plurality of vehicle types. Analysis support method.

15. A program for causing a computer to execute the analysis support method according to claim 14.

Images