Vulnerability analysis system, vulnerability analysis method, and program

Abstract

To provide a vulnerability analysis system capable of improving the accuracy of vulnerability analysis.SOLUTION: A vulnerability analysis system 10 comprises: a classification storage unit 12 for storing classification information indicating an asset type for each asset owned by a vehicle; a classification specification unit 11 for acquiring design information d1 indicating assets held by an analysis target item, and referring to the classification information to specify the asset type indicated by the design information d1; an applicability determination unit 13 for determining whether or not each of one or more first vulnerabilities that are pre-associated with the specified type corresponds to the analysis target item; and an output unit 17 for outputting an analysis result report d2 indicating the determination result by the applicability determination unit 13. The plurality of types indicated by the classification information include the type related to in-vehicle security.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a vulnerability analysis system that analyzes vulnerabilities of an item to be analyzed. [Background technology]

[0002] For example, Patent Document 1 discloses a vulnerability assessment device as a vulnerability analysis system. This vulnerability assessment device calculates the threat level of a security hole for each component of a product based on asset value and determines the priority of security measures to be implemented. Information indicating the asset value and security holes is stored in a storage unit for each component of the product. The vulnerability assessment device also includes an attack map storage unit that stores an attack map linking the names of elements that form attack paths with vulnerability information corresponding to those element names. The vulnerability assessment device also includes a security countermeasure classification storage unit that stores, for each security measure, the component to be defended and a coefficient that quantifies the effectiveness of the measure, linked to each other. The vulnerability assessment device also sets a vulnerability assessment value based on the result of multiplying the asset value by the difficulty of attacking the security hole. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6995726 Summary of the Invention [Problem to be solved by the invention]

[0004] However, the vulnerability assessment device of Patent Document 1 has a problem in that the accuracy of vulnerability analysis is low.

[0005] Therefore, the present disclosure provides a vulnerability analysis system and the like that can improve the accuracy of vulnerability analysis. [Means for solving the problem]

[0006] A vulnerability analysis system according to one embodiment of the present disclosure includes a classification storage unit that stores classification information indicating the type of asset for each asset held by a vehicle; a classification identification unit that acquires design information indicating the assets held by an item to be analyzed and identifies the type of asset indicated by the design information by referring to the classification information; a suitability determination unit that determines whether each of one or more first vulnerabilities that are pre-associated with the identified type applies to the item to be analyzed; and an output unit that outputs an analysis result report indicating the determination result by the suitability determination unit, wherein the multiple types indicated by the classification information include a type related to in-vehicle security.

[0007] The comprehensive or specific aspects may be realized as an apparatus, a method, an integrated circuit, a computer program, or a computer-readable recording medium such as a CD-ROM, or may be realized as any combination of the apparatus, the method, the integrated circuit, the computer program, and the recording medium. The recording medium may also be a non-transitory recording medium. [Effects of the Invention]

[0008] The vulnerability analysis system of the present disclosure can improve the accuracy of vulnerability analysis.

[0009] Further advantages and effects of one aspect of the present disclosure will become apparent from the specification and drawings. Such advantages and / or effects are provided by the configurations described in the embodiments and the specification and drawings, but not all of the configurations are necessarily required. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration of a vulnerability analysis system according to an embodiment. [Figure 2] FIG. 2 is a diagram showing an example of a screen for generating design information according to the embodiment. [Figure 3]FIG. 3 is a diagram illustrating an example of processing performed by the category specifying unit and the relevant / non-relevant determining unit in the embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of processing performed by the pertinence determining unit in the embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of the configuration of the priority derivation unit according to the embodiment. [Figure 6] FIG. 6 is a diagram for explaining the processing of the first priority derivation unit in the embodiment. [Figure 7] FIG. 7 is a diagram for explaining the processing of the second priority derivation unit in the embodiment. [Figure 8] FIG. 8 is a diagram for explaining the processing of the third priority derivation unit in the embodiment. [Figure 9] FIG. 9 is a diagram for explaining an example of how the threat analysis system determines a risk value. [Figure 10] FIG. 10 is a diagram showing an example of an analysis result report output from the output unit in the embodiment. [Figure 11] FIG. 11 is a flowchart showing an example of a series of processing operations of the category specifying unit, the pertinence determining unit, and the reason deriving unit in the embodiment. [Figure 12] FIG. 12 is a flowchart illustrating an example of the processing operation of the priority derivation unit according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] A vulnerability analysis system according to a first aspect of the present disclosure includes: a classification storage unit that stores classification information indicating a type of asset for each asset owned by a vehicle; a classification identification unit that acquires design information indicating assets owned by an analysis target item and identifies the asset type indicated by the design information by referring to the classification information; a correlation determination unit that determines whether one or more first vulnerabilities pre-associated with the identified types apply to the analysis target item; and an output unit that outputs an analysis result report indicating the determination result by the correlation determination unit, wherein the multiple types indicated by the classification information include a type related to in-vehicle security. Note that the first vulnerabilities are vulnerabilities identified by, for example, a Common Weakness Enumeration (CWE)-ID and are also called vulnerability types.

[0012] As a result, since the multiple types indicated by the classification information include types related to in-vehicle security, a type specific to in-vehicle security may be identified as the asset type. In such a case, it is determined whether a first vulnerability specific to in-vehicle security corresponds to the item to be analyzed. Therefore, the first vulnerability can be determined from a perspective specific to in-vehicle security. This can improve the accuracy of vulnerability analysis.

[0013] In addition, in a vulnerability analysis system according to a second aspect, the classification storage unit may include a first classification storage unit that stores first classification information indicating, in association with each of one or more types of in-vehicle security, one or more assets classified into the type, and a second classification storage unit that stores second classification information indicating, in association with each of one or more types of security not limited to the in-vehicle security, one or more assets classified into the type. Note that the second aspect may be subordinate to the first aspect.

[0014] This allows the first vulnerability to be determined based on a viewpoint specific to in-vehicle security and a viewpoint of general security, thereby more effectively improving the accuracy of vulnerability analysis.

[0015] The vulnerability analysis system according to the third aspect may further include a priority derivation unit that derives, for each of the first vulnerabilities determined to correspond to the analysis target item, a priority of a countermeasure against the vulnerability as a countermeasure priority. Note that the third aspect may be subordinate to the first or second aspect.

[0016] As a result, a countermeasure priority is derived for each of the multiple first vulnerabilities determined to correspond to the analysis target item, i.e., the multiple relevant vulnerabilities. The multiple relevant vulnerabilities may include a relevant vulnerability specific to in-vehicle security. In such a case, a higher countermeasure priority can be derived for the relevant vulnerability specific to in-vehicle security than for other relevant vulnerabilities. Alternatively, a countermeasure priority can be derived for the relevant vulnerability specific to in-vehicle security using a method specific to in-vehicle security. As a result, appropriate countermeasure priorities can be derived for the multiple relevant vulnerabilities, and insufficient or delayed countermeasures for the relevant vulnerabilities can be prevented. Furthermore, even if there are a large number of relevant vulnerabilities, the countermeasure priorities can be appropriately derived, allowing the countermeasures for the relevant vulnerabilities to be implemented in an appropriate order.

[0017] In a vulnerability analysis system according to a fourth aspect, the priority derivation unit may derive the countermeasure priority for the vulnerability using at least one of (a) the impact of the vulnerability on the operation of a vehicle having the item being analyzed, (b) the number of times a second vulnerability belonging to the vulnerability has been found in multiple vehicles in the past, and (c) the actual amount of work required to address the vulnerability in the past. The fourth aspect may be subordinate to a third aspect, which is subordinate to the first or second aspect. The operation of a vehicle corresponds to functions such as running, turning, and stopping. The second vulnerability is, for example, a vulnerability identified by a CVE (Common Vulnerabilities and Exposures)-ID.

[0018] This makes it possible to derive with high accuracy the priority of countermeasures from the perspective of the impact of the vulnerability on vehicle operation, the number of cases of secondary vulnerabilities, and the actual labor hours required to counter the vulnerability.

[0019] In a vulnerability analysis system according to a fifth aspect, the priority derivation unit may derive the countermeasure priority of the vulnerability using an impact level, which is the magnitude of the impact on an architecture of the asset that the analysis target item has. Note that the fifth aspect may be dependent on a third aspect, which is dependent on the first or second aspect, or on a fourth aspect.

[0020] This makes it possible to derive the priority of countermeasures with high accuracy from the viewpoint of the magnitude of the impact on the architecture.

[0021] In a vulnerability analysis system according to a sixth aspect, the priority derivation unit may derive the countermeasure priority for the vulnerability using the level of impact that the analysis target item will have due to an attack on the asset, the level of possibility of an attack on the asset, and the number of attack paths to the asset. Note that the sixth aspect may be subordinate to the third, fourth, or fifth aspect, which are subordinate to the first or second aspect. Note that an attack path is also called an attack path.

[0022] This allows for highly accurate calculation of countermeasure priorities from the perspective of the level of impact, the level of attack possibility, and the number of attack paths.

[0023] Furthermore, the vulnerability analysis system according to the seventh aspect may further include a reason derivation unit that derives, for the first vulnerability determined not to correspond to the analysis target item, a reason why the first vulnerability does not correspond to the analysis target item. Note that the seventh aspect may be subordinate to any one of the first to sixth aspects.

[0024] This allows the reason for non-application to be derived, thereby ensuring the reliability of the determination result by the pertinence determination unit.

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

[0026] The embodiments described below are all comprehensive or specific examples. The numerical values, shapes, materials, components, component placement and connection configurations, steps, and step order shown in the following embodiments are merely examples and are not intended to limit the present disclosure. Furthermore, among the components in the following embodiments, components that are not described in the independent claims that represent the highest concepts are described as optional components.

[0027] In addition, each drawing is a schematic diagram and is not necessarily an exact illustration. In addition, the same components are denoted by the same reference numerals in each drawing.

[0028] (Embodiment) FIG. 1 is a diagram showing an example of the configuration of a vulnerability analysis system according to this embodiment.

[0029] The vulnerability analysis system 10 in this embodiment is a system that analyzes information security vulnerabilities in an analysis target item included in, for example, a vehicle. That is, the vulnerability analysis system 10 acquires design information d1 of the analysis target item and analyzes the vulnerability of each of one or more assets indicated in the design information d1. The vulnerability analysis system 10 then outputs an analysis result report d2 as information indicating the analysis results of the vulnerabilities.

[0030] The analysis target items and assets may be, for example, functions realized by a program. The analysis target items may be, for example, an ECU (Electronic Control Unit) installed in a vehicle. The vulnerability analysis system 10 may be, for example, a system that complies with the ISO (International Organization for Standardization) / SAE (Society of Automotive Engineers) 21434 regulations.

[0031] Such a vulnerability analysis system 10 includes a classification specifying unit 11 , a classification storage unit 12 , a vulnerability determination unit 13 , a vulnerability management storage unit 14 , a reason deriving unit 15 , a priority deriving unit 16 , and an output unit 17 .

[0032] The classification storage unit 12 is a recording medium that stores classification information indicating the type of asset for each asset owned by the vehicle. The classification information can also be said to be information indicating the results of classifying the assets. In this embodiment, the classification storage unit 12 includes a first classification storage unit 12a and a second classification storage unit 12b.

[0033] The first classification storage unit 12a is a recording medium that stores first classification information indicating the result of classifying a plurality of assets from a viewpoint specific to a vehicle. Specifically, the first classification information indicates one or more types related to in-vehicle security in association with one or more assets classified into that type. In other words, in the first classification information, the plurality of assets are classified from the viewpoint specific to a vehicle, a vehicle, or an in-vehicle security.

[0034] The second classification storage unit 12b is a recording medium that stores second classification information indicating the result of classifying a plurality of assets from a general security perspective. Specifically, the second classification information indicates one or more types of security, not limited to in-vehicle security, in association with one or more assets classified into the type.

[0035] That is, the classification information in this embodiment includes first classification information and second classification information. The multiple types indicated by the classification information include types related to in-vehicle security. Note that the in-vehicle security is, for example, security in an information processing system or program installed in a vehicle.

[0036] The vulnerability management storage unit 14 is a recording medium that stores vulnerability management information that indicates each of a plurality of types in association with one or more first vulnerabilities corresponding to that type.

[0037] In this embodiment, the first vulnerability is a vulnerability identified by a CWE-ID. A CWE-ID is identification information for a category or type of vulnerability. In other words, in this embodiment, the first vulnerability is a vulnerability with a high level of abstraction, and is also called a vulnerability type. Specifically, CWE is a common standard published by the MITRE Corporation for identifying types of security vulnerabilities in software. CWE-IDs are classified by view, category, or the like.

[0038] The recording media for the first classification storage unit 12a, the second classification storage unit 12b, the vulnerability management storage unit 14, etc. may be, for example, a hard disk drive, a RAM (Random Access Memory), a ROM (Read Only Memory), or a semiconductor memory. Such recording media may be volatile or non-volatile.

[0039] The category identification unit 11 acquires design information d1 indicating the asset held by the analysis target item. Then, the category identification unit 11 identifies the type of asset indicated by the design information d1 by referring to the above-mentioned classification information (i.e., the first classification information and the second classification information). Note that the category identification unit 11 may identify multiple types for one asset.

[0040] The pertinence determination unit 13 determines whether or not each of the one or more first vulnerabilities previously associated with the type identified by the category identification unit 11 corresponds to the analysis target item. That is, the pertinence determination unit 13 refers to the vulnerability management information in the vulnerability management storage unit 14, and searches the vulnerability management information for each of the one or more first vulnerabilities previously associated with the type identified by the category identification unit 11. The pertinence determination unit 13 then determines whether or not each of the searched one or more first vulnerabilities corresponds to the analysis target item. The pertinence determination unit 13 outputs determination result information indicating the determination result to the reason deriving unit 15, the priority deriving unit 16, and the output unit 17.

[0041] When the reason deriving unit 15 acquires the determination result information from the pertinence determination unit 13, the reason deriving unit 15 derives, based on the determination result information, a reason why a first vulnerability determined not to correspond to the analysis target item does not correspond to the analysis target item. Note that a first vulnerability determined to correspond to the analysis target item is also referred to as a pertinent vulnerability hereinafter. Then, the reason deriving unit 15 outputs reason information indicating the derived reason to the output unit 17.

[0042] The priority derivation unit 16 derives, for each first vulnerability determined to correspond to the analysis target item, i.e., each relevant vulnerability, the priority of the countermeasure for that vulnerability as a countermeasure priority. Then, the priority derivation unit 16 outputs priority information indicating the derived countermeasure priority to the output unit 17. Even when the analysis target item has a large number of assets and each of those assets has a large number of relevant vulnerabilities, the priority derivation unit 16 in this embodiment derives countermeasure priorities for those relevant vulnerabilities.

[0043] The output unit 17 acquires the determination result information from the pertinence determination unit 13, acquires the reason information from the reason derivation unit 15, and acquires the priority information from the priority derivation unit 16. The output unit 17 then outputs an analysis result report d2 including the determination result information, reason information, and priority information. In other words, the analysis result report d2 shows the determination result by the pertinence determination unit 13.

[0044] FIG. 2 is a diagram showing an example of a screen for generating design information d1.

[0045] For example, the computer displays the screen shown in FIG. 2 on a display. This screen is for asking a question to the user and receiving an answer to the question from the user. The question is about the item to be analyzed. By receiving an answer from the user via this screen, the computer generates design information d1 indicating one or more assets according to the answer and outputs the design information d1 to the classification identification unit 11.

[0046] Specifically, the screen includes question 1-1, "Is this a program that communicates with an external device?" Furthermore, if the answer to that question is "Yes," the screen includes another question, 1-2, "Please list all combinations of the external interface to be used, the device to which the program connects, the protocol to be used, and the authentication method for the connected device." The external interface is also written as "external I / F."

[0047] In response to the user's input operation, the computer accepts the answer "Yes" to Question 1-1 and also accepts an answer to Question 1-2. When answering Question 1-2, the user selects one answer from multiple options for each item. The items include "External I / F Used," "External Device Connected to," "Protocol," "Device Authentication Method," "Network Defense Function," and "Validity Verification Method." The user selects an answer for each of these items. For example, the user selects "In-Vehicle CAN" for the item "External I / F Used," "Control ECU / Device Inside GW" for the item "Device Authentication Method," and "CAN-FD" for the item "Protocol." Furthermore, the user selects "None" for the item "Device Authentication Method," "IDS / IPS" for the item "Network Defense Function," and "None" for the item "Validity Verification Method." As a result, one combination including "in-vehicle CAN," "control ECU / device inside GW," "CAN-FD," "none," "IDS / IPS," and "none" is accepted as an answer to question 1-2. In other words, the answer indicated by answer number "1-2-2" is accepted.

[0048] The computer generates design information d1 based on the answers received in this way.

[0049] FIG. 3 is a diagram for explaining an example of the processing of the category specifying unit 11 and the pertinence determining unit 13. In FIG.

[0050] The classification identification unit 11 acquires the above-mentioned design information d1. For example, as shown in (a) of FIG. 3, the design information d1 indicates a "CAN protocol" and a "password authentication function" as assets. CAN stands for Controller Area Network. The "CAN protocol" and the "password authentication function" are examples of assets based on the answers indicated by the answer numbers "1-2-2" and "1-2-4" shown in FIG. 2, respectively.

[0051] The classification identification unit 11 searches for the asset "CAN protocol" from the first classification information 12ad in the first classification storage unit 12a and the second classification information 12bd in the second classification storage unit 12b. In this case, the asset "CAN protocol" is shown in the first classification information 12ad. Therefore, as shown in FIG. 3B, the classification identification unit 11 identifies a type associated with the asset "CAN protocol" in the first classification information 12ad. The type is a type related to on-board security or a type specific to on-board security. The type may include, for example, a first type and a second type. The second type may be a type obtained by further classifying the first type. Alternatively, the second type may be a type independent of the first type. In the example of FIG. 3, the classification identification unit 11 identifies "CAN" as the first type and "-" as the second type associated with the asset "CAN protocol." Note that "-" indicates that there is no second type and is also represented as "(none)."

[0052] Similarly, the category identification unit 11 searches for the asset "password authentication" from the first category information 12ad in the first category storage unit 12a and the second category information 12bd in the second category storage unit 12b. In this case, the asset "password" is shown in the second category information 12bd. Therefore, the category identification unit 11 identifies the type associated with the asset "password authentication" in the second category information 12bd, as shown in (b) of FIG. 3. This type is a type related to security that is not limited to in-vehicle security, i.e., general security. In the example of FIG. 3, the category identification unit 11 identifies "authentication" as the first type and "password" as the second type associated with the asset "password authentication."

[0053] As a result, as shown in (c) of Figure 3, for the asset "CAN protocol", the combination of the first type "CAN" and the second type "(none)" is obtained as the identification result. Furthermore, for the asset "password authentication", the combination of the first type "authentication" and the second type "password" is obtained as the identification result.

[0054] Then, as shown in FIG. 3(d), the pertinence determination unit 13 searches for one or more first vulnerabilities associated with the identified combination of the first type and the second type by referring to the vulnerability management information 14d in the vulnerability management storage unit 14. That is, the pertinence determination unit searches for one or more CWE-IDs. Specifically, in the vulnerability management information 14d, CWE-IDs "300" and "419" are associated with the combination of the first type "CAN" and the second type "-". Furthermore, in the vulnerability management information 14d, CWE-IDs "258" and "259" are associated with the combination of the first type "authentication" and the second type "password". Therefore, the pertinence determination unit 13 searches for CWE-IDs "300" and "419" with the combination of the first type "CAN" and the second type "-". Furthermore, the pertinence determination unit 13 searches for CWE-IDs such as "258" and "259" for the combination of the first type "authentication" and the second type "password."

[0055] In the vulnerability management information 14d, one or more CWE-IDs may be associated with each of the first and second types. In this case, the vulnerability determination unit 13 refers to the vulnerability management information 14d to search for one or more CWE-IDs associated with the first type, and further search for one or more CWE-IDs associated with the second type.

[0056] FIG. 4 is a diagram for explaining an example of the process of the pertinence determination unit 13. In FIG.

[0057] After searching for one or more CWE-IDs as shown in (a) of FIG. 4, the pertinence determination unit 13 determines whether each of the one or more CWE-IDs corresponds to an item to be analyzed, as shown in (b) of FIG. 4. For example, the pertinence determination unit 13 may make this determination by referring to a predetermined table, or may make this determination in response to an input operation by a user. The pertinence determination unit 13 then generates and outputs determination result information d3 indicating the determination result for each of the one or more CWE-IDs. Note that the determination result information d3 may also indicate the title of the CWE-ID for each CWE-ID.

[0058] As described above, in this embodiment, the multiple types indicated by the classification information consisting of the first classification information 12ad and the second classification information 12bd include types related to in-vehicle security. Therefore, a type specific to in-vehicle security may be identified as the asset type. In such a case, it is determined whether a first vulnerability specific to in-vehicle security corresponds to the item to be analyzed. Therefore, the first vulnerability can be determined from a perspective specific to in-vehicle security. This can improve the accuracy of vulnerability analysis.

[0059] In addition, in this embodiment, since the classification information is made up of the first classification information 12ad and the second classification information 12bd, the first vulnerability can be determined based on a viewpoint specific to in-vehicle security and a viewpoint of general security, thereby more effectively improving the accuracy of vulnerability analysis.

[0060] FIG. 5 is a diagram showing an example of the configuration of the priority derivation unit 16. As shown in FIG.

[0061] The priority derivation unit 16 in this embodiment includes a first priority derivation unit 21, a second priority derivation unit 22, a third priority derivation unit 23, a CWE performance record storage unit 24, a performance man-hours storage unit 25, and an architecture storage unit .

[0062] The CWE performance information storage unit 24 is a recording medium that stores CWE performance information. The CWE performance information indicates, for each CWE-ID, the performance number, which is the number of CVE-IDs that belong to that CWE-ID that have been assigned as automotive CVEs in the past year. Note that vulnerabilities identified by CVE-IDs are also called secondary vulnerabilities.

[0063] The actual effort storage unit 25 is a recording medium that stores actual effort information. The actual effort information indicates, for each CWE-ID, the actual effort required to address the vulnerability identified by that CWE-ID (i.e., the first vulnerability).

[0064] The architecture storage unit 26 is a recording medium that stores architecture information. The architecture information indicates, for each type of architecture, the magnitude of the influence on that type of architecture as the degree of influence.

[0065] The recording media for the CWE performance record storage unit 24, performance record man-hour storage unit 25, architecture storage unit 26, etc. may be, for example, a hard disk drive, RAM, ROM, or semiconductor memory. Such recording media may be volatile or non-volatile.

[0066] The first priority derivation unit 21 acquires determination result information d3 indicating the determination result by the pertinence determination unit 13. For example, as shown in FIG. 4(b), the determination result information d3 indicates one or more CWE-IDs and the determination result of whether each CWE-ID is pertinent or not. Note that a CWE-ID determined to be pertinent will hereinafter be referred to as a pertinent CWE-ID, and a vulnerability identified by the pertinent CWE-ID (i.e., a first vulnerability) will hereinafter be referred to as a pertinent vulnerability.

[0067] Then, for each relevant CWE-ID, i.e., for each relevant vulnerability identified by the relevant CWE-ID, first priority derivation unit 21 derives the priority of a countermeasure for that vulnerability as a first priority. At this time, first priority derivation unit 21 derives the first priority for each relevant CWE-ID based on the CWE performance information in CWE performance storage unit 24 and the actual effort information in actual effort storage unit 25. In addition, first priority derivation unit 21 outputs first priority information indicating the first priority derived for each relevant CWE-ID to second priority derivation unit 22.

[0068] The second priority derivation unit 22 derives a second priority, which is a priority of a countermeasure for each relevant CWE-ID, i.e., for each relevant vulnerability identified by the relevant CWE-ID. For example, after obtaining first priority information from the first priority derivation unit 21, the second priority derivation unit 22 identifies the first priority of each relevant CWE-ID indicated in the first priority information. Furthermore, the second priority derivation unit 22 derives a second priority for each relevant CWE-ID using each relevant CWE-ID, the first priority of each relevant CWE-ID, and the architecture information in the architecture storage unit 26. The second priority derivation unit 22 then outputs second priority information indicating the second priority derived for each relevant CWE-ID to the third priority derivation unit 23.

[0069] For each relevant CWE-ID, i.e., for each relevant vulnerability identified by the relevant CWE-ID, the third priority derivation unit 23 derives a countermeasure priority for that vulnerability as a third priority. For example, upon receiving second priority information from the second priority derivation unit 22, the third priority derivation unit 23 identifies the second priority of each relevant CWE-ID indicated in the second priority information. Furthermore, the third priority derivation unit 23 derives a third priority for each relevant CWE-ID using the asset's risk value, the second priority of each relevant CWE-ID, and the number of attack paths to the asset. The third priority derivation unit 23 then outputs priority information d4 indicating the derived third priority for each relevant CWE-ID as a countermeasure priority.

[0070] FIG. 6 is a diagram for explaining the processing of the first priority derivation unit 21. As shown in FIG.

[0071] For example, as shown in Figure 6, the item to be analyzed is a remote parking function for a vehicle. The item to be analyzed includes a Bluetooth (registered trademark) communication function, a first function, a second function, and a CAN communication function as assets. Of these assets, the asset "CAN communication function" has a first vulnerability (specifically, a vulnerability type) identified by the CWE-ID "CWE-b." Note that "CWE-b" is the relevant CWE-ID, and the above-mentioned first vulnerability is the relevant vulnerability.

[0072] The first priority derivation unit 21 receives the impact of the vulnerability identified by the CWE-ID on the vehicle, for example, in response to an input operation by a user. The impact is expressed, for example, by a safety (S) level, a property (F) level, an operability (O) level, and a privacy (P) level. In other words, the impact is expressed by SFOP. The levels are expressed in four stages. For example, the levels, in descending order of severity, include "Severe," "Major," "Moderate," and "Negligible."

[0073] For example, as shown in (a) of FIG. 6, the first priority derivation unit 21 accepts "Severe" as the level of safety (S) and "Moderate" as the level of property (F). Furthermore, the first priority derivation unit 21 accepts "Major" as the level of operation performance (O) and "Negligible" as the level of privacy (F). The "Severe" level of safety (S) is a level at which a life-threatening injury or fatal injury occurs. The "Moderate" level of property (F) is a level at which minor losses less than the price of the vehicle occur. The "Major" level of operation performance (O) is a level at which important vehicle functions are lost. The "Negligible" level of privacy (P) is a level at which there is no impact on the functions or performance of the vehicle.

[0074] In the above example, the first priority derivation unit 21 receives the SFOP for the CWE-ID in response to a user input operation, but it may also receive the SFOP by referencing a predetermined table, in which an SFOP is defined for each CWE-ID.

[0075] When the first priority derivation unit 21 receives such an SFOP, it derives a first coefficient for the vulnerability identified by the CWE-ID "CWE-b" in the SFOP based on the impact that the vulnerability has on the safety and driving of the vehicle. The impact on vehicle safety is expressed by a safety (S) level. The impact on vehicle driving is the impact on the vehicle's running, turning, and stopping functions, and is expressed by an operation performance (O) level. Therefore, the first priority derivation unit 21 derives a first coefficient of "3.5" from the safety (S) level "Severe" and the operation performance (O) level "Major." Note that combinations of the safety (S) level and the operation performance (O) level may be associated with the first coefficient in advance. That is, the first priority derivation unit 21 searches for a first coefficient corresponding to the combination of the received safety (S) level and the operation performance (O) level from a table showing each of a plurality of combinations and the first coefficients associated with that combination. This derives the first coefficient.

[0076] In the above example, the first priority derivation unit 21 derives the first coefficient based on a combination of the safety (S) level and the operational performance (O) level. However, the first priority derivation unit 21 may derive the first coefficient based on only one of the safety (S) level and the operational performance (O) level. For example, the first priority derivation unit 21 may derive the first coefficient based on only the safety (S) level. Alternatively, the first priority derivation unit 21 may derive the first coefficient using all levels of SFOP.

[0077] Next, as shown in FIG. 6B, the first priority derivation unit 21 refers to the CWE performance information 24d stored in the CWE performance storage unit 24. As described above, the CWE performance information 24d indicates, for each CWE-ID, the performance count, which is the number of times that a CVE-ID belonging to the CWE-ID has been assigned as an automotive CVE over the past year. In other words, the CWE performance information 24d indicates the number of vulnerabilities (i.e., second vulnerabilities) identified by each of multiple automotive CVEs belonging to the CWE-ID that have been found in the automotive industry or the vehicle industry over the most recent past year. If the vulnerability is a first vulnerability identified by the CWE-ID "CWE-b," the first priority derivation unit 21 searches for the CWE-ID "CWE-b" in the CWE performance information 24d. Then, the first priority derivation unit 21 identifies the performance count "200" associated with the CWE-ID "CWE-b" in the CWE performance information 24d. Furthermore, the first priority derivation unit 21 derives a larger second coefficient as the number of achievements increases. For example, the first priority derivation unit 21 derives a second coefficient of "4" from the number of achievements "200." The relationship between the number of achievements and the second coefficient may be expressed by a function or in a table format.

[0078] Next, as shown in FIG. 6C, the first priority derivation unit 21 references the actual effort information 25d stored in the actual effort storage unit 25. As described above, the actual effort information 25d indicates, for each CWE-ID, the actual effort required to address the first vulnerability identified by the CWE-ID. If the vulnerability is the first vulnerability identified by the CWE-ID "CWE-b," the first priority derivation unit 21 searches for the CWE-ID "CWE-b" in the actual effort information 25d. Then, the first priority derivation unit 21 identifies the actual effort "1" associated with the CWE-ID "CWE-b" in the actual effort information 25d. Furthermore, the first priority derivation unit 21 derives a larger third coefficient as the actual effort increases. For example, the first priority derivation unit 21 derives a third coefficient "2" from the actual effort "1." The relationship between the actual man-hours and the third coefficient may be expressed by a function or in a table format.

[0079] Then, the first priority derivation unit 21 derives the first priority based on the first coefficient, the second coefficient, and the third coefficient. For example, the first priority derivation unit 21 derives the first priority by multiplying the first coefficient, the second coefficient, and the third coefficient. In the above example, the first priority derivation unit 21 derives the first priority of "28" by multiplying the first coefficient "3.5", the second coefficient "4", and the third coefficient "2". Note that in the above example, multiplication is used to derive the first priority, but other operations or formulas other than multiplication, such as the average of the above three coefficients, may also be used.

[0080] As described above, the first priority derivation unit 21 in this embodiment derives the first priority of a countermeasure for the vulnerability based on the first coefficient, the second coefficient, and the third coefficient. Furthermore, the priority derivation unit 16 in this embodiment derives the countermeasure priority using the first priority. Therefore, the priority derivation unit 16 in this embodiment derives the countermeasure priority for the vulnerability based on (a) the impact of the vulnerability on the operation of a vehicle having the item being analyzed, (b) the number of times a second vulnerability belonging to the vulnerability has been found in multiple vehicles in the past, and (c) the actual man-hours required to take countermeasures for the vulnerability in the past. The impact of (a) is the safety (S) level and the operability (O) level described above, the number of times ...

[0081] As described above, in this embodiment, a countermeasure priority is derived for each of the multiple first vulnerabilities determined to correspond to the analysis target item, i.e., the multiple relevant vulnerabilities. The multiple relevant vulnerabilities may include a relevant vulnerability specific to in-vehicle security. In such a case, a higher countermeasure priority can be derived for the relevant vulnerability specific to in-vehicle security than for other relevant vulnerabilities. Alternatively, a countermeasure priority can be derived for the relevant vulnerability specific to in-vehicle security using a method specific to in-vehicle security. This makes it possible to derive appropriate countermeasure priorities for the multiple relevant vulnerabilities, thereby preventing insufficient or delayed countermeasures for the relevant vulnerabilities. Furthermore, even if there are a large number of relevant vulnerabilities, the countermeasure priorities can be appropriately derived, allowing the countermeasures for the relevant vulnerabilities to be implemented in an appropriate order.

[0082] In this embodiment, the countermeasure priority for the vulnerability is derived using the above (a), (b), and (c). Therefore, the countermeasure priority can be derived with high accuracy from the viewpoint of the impact of the vulnerability on vehicle operation, the actual number of second vulnerabilities, the actual man-hours required to take measures against the vulnerability, etc.

[0083] FIG. 7 is a diagram for explaining the processing of the second priority derivation unit 22. As shown in FIG.

[0084] As shown in FIG. 7, the second priority derivation unit 22 refers to the architecture information 26d stored in the architecture storage unit 26. As described above, the architecture information 26d indicates, for each architecture type, the magnitude of the impact of that type on the architecture as an impact level. For example, in the architecture information 26d, architecture types are classified into multiple higher-level classes, and each higher-level class is further classified into multiple lower-level classes. In other words, architecture types are made up of combinations of higher-level classes and lower-level classes. In other words, architecture types are made up of major classes and minor classes. Furthermore, in the architecture information 26d, each higher-level class is associated with a CWE-View.

[0085] If the vulnerability is a first vulnerability identified by CWE-ID "CWE-b," the second priority derivation unit 22 identifies the architecture type corresponding to the CWE-ID "CWE-b." The asset corresponding to CWE-ID "CWE-b" is a CAN communication function, which is related to system and software as architecture types. Therefore, the second priority derivation unit 22 identifies system and software as the architecture type corresponding to CWE-ID "CWE-b." Then, the second priority derivation unit 22 identifies, in the architecture information 26d, an impact level of "4" associated with the superordinate class "system" and impact levels of "3, 2, 1" associated with the superordinate class "software." Furthermore, the second priority derivation unit 22 selects the largest impact level of "4" from the identified impact levels.

[0086] Next, the second priority derivation unit 22 derives the second priority based on the first priority of the CWE-ID "CWE-b" indicated in the first priority information and the impact level of "4" identified and selected for the CWE-ID "CWE-b." For example, the second priority derivation unit 22 derives the second priority by multiplying the first priority by the impact level. In the above example, the second priority derivation unit 22 derives the second priority of "112" by multiplying the first priority of "28" by the impact level of "4." Note that, although multiplication is used to derive the second priority in the above example, an operation or formula other than multiplication may also be used.

[0087] In this way, the second priority derivation unit 22 in this embodiment derives the second priority of the countermeasure for the vulnerability based on the impact on the architecture. Furthermore, the priority derivation unit 16 in this embodiment derives the countermeasure priority using the second priority. Therefore, the priority derivation unit 16 in this embodiment derives the countermeasure priority for the vulnerability using the impact, which is the magnitude of the impact on the architecture of the asset owned by the item to be analyzed.

[0088] This makes it possible to derive the priority of countermeasures with high accuracy from the viewpoint of the magnitude of the impact on the architecture.

[0089] FIG. 8 is a diagram for explaining the processing of the third priority derivation unit 23. As shown in FIG.

[0090] As shown in FIG. 8 , when the vulnerability is a first vulnerability identified by the CWE-ID "CWE-b," the third priority derivation unit 23 determines the CWE-ID "CWE-b," i.e., the risk value of the asset corresponding to the CWE-ID "CWE-b." Furthermore, the third priority derivation unit 23 derives a fourth coefficient based on the risk value and the number of attack paths, which is the number of attack paths to the asset. The attack paths are also called attack routes. The third priority derivation unit 23 then derives a third priority as the countermeasure priority based on the fourth coefficient and the second priority derived by the second priority derivation unit 22.

[0091] Specifically, the third priority derivation unit 23 first derives a DFD (Data Flow Diagram) of the analysis target item based on the design information d1, etc. The third priority derivation unit 23 may derive the DFD using other information, may acquire the DFD from another system or device, or may derive the DFD based on an input operation by a user. The DFD is also a diagram showing the flow of data between external devices such as a smartphone, a GW (Gateway), and a sensor ECU and each component included in the remote parking function, which is the analysis target item.

[0092] Next, the third priority derivation unit 23 identifies attack paths to the asset corresponding to the CWE-ID "CWE-b" based on the DFD. In the example of FIG. 8, the asset is a CAN communication function. The attack paths to the CAN communication function include a first attack path, a second attack path, and a third attack path. As shown in FIG. 8, the first attack path is a path from a smartphone located outside the remote parking function to the CAN communication function. The second attack path is a path from a gateway connected to the vehicle control ECU located outside the remote parking function to the CAN communication function. The third attack path is a path from a sensor ECU located outside the remote parking function to the CAN communication function. Therefore, the number of attack paths from outside the remote parking function to the CAN communication function, i.e., the number of attack paths, is "3." Therefore, the third priority derivation unit 23 identifies "3" as the number of attack paths.

[0093] Next, the third priority derivation unit 23 determines a risk value for each attack path to the asset (the CAN communication function in the example of FIG. 8) corresponding to the CWE-ID "CWE-b." When determining the risk value of an asset, the third priority derivation unit 23 uses the level of impact on the analysis target item caused by an attack on the asset, the level of attack probability via the attack path to the asset, and a risk matrix table. The impact level, attack probability level, and risk matrix table are defined, for example, by ISO 21434. For example, if the impact level is "Severe" and the attack probability level is "Low," the third priority derivation unit 23 searches the risk matrix table for a risk value associated with the impact level "Severe" and the attack probability level "Low." Through this search, the third priority derivation unit 23 determines a risk value of "3." After determining the risk value for each attack path, the third priority derivation unit 23 selects the maximum risk value from these risk values. In the example of FIG. 8, "3" is selected as the maximum risk value.

[0094] Next, the third priority derivation unit 23 derives a fourth coefficient "9" by, for example, multiplying the maximum risk value "3" selected as described above by the identified number of attack paths "3." Furthermore, the third priority derivation unit 23 derives a third priority "1108" by, for example, multiplying the fourth coefficient "9" by the second priority "112." This third priority "1108" is treated as the countermeasure priority. Note that, although multiplication is used to derive the third priority in the above example, other operations or formulas other than multiplication may also be used.

[0095] In this manner, the third priority derivation unit 23 in this embodiment derives the third priority of countermeasures for the vulnerability in question based on the risk value and the number of attack paths. The risk value is determined based on the level of impact that the analysis target item will have due to an attack on the asset and the level of possibility of attacks on the asset. In this embodiment, the third priority is treated as the countermeasure priority. Therefore, the priority derivation unit 16 in this embodiment derives the countermeasure priority for the vulnerability in question based on the level of impact that the analysis target item will have due to an attack on the asset, the level of possibility of attacks on the asset, and the number of attack paths on the asset.

[0096] This allows for highly accurate calculation of countermeasure priorities from the perspective of the level of impact, the level of attack possibility, and the number of attack paths.

[0097] The determination of the risk value and the selection of the maximum risk value by the third priority derivation unit 23 may also be performed in the threat analysis system. For example, a threat analysis of an analysis target item is first performed by the threat analysis system, and then a vulnerability analysis is performed by the vulnerability analysis system 10. In the threat analysis by the threat analysis system, a risk value is determined and a maximum risk value is selected. In the vulnerability analysis by the vulnerability analysis system 10, the third priority derivation unit 23 also determines a risk value and selects a maximum risk value. In other words, the third priority derivation unit 23 in this embodiment determines a risk value and selects a maximum risk value by performing processing similar to that of the threat analysis system. Alternatively, if the determination of a risk value and the selection of a maximum risk value are performed in the threat analysis by the threat analysis system, the third priority derivation unit 23 may acquire the maximum risk value obtained as a processing result by the threat analysis system from the threat analysis system without determining a risk value and selecting a maximum risk value.

[0098] FIG. 9 is a diagram for explaining an example of how the threat analysis system determines a risk value.

[0099] As shown in FIG. 9A, the threat analysis system evaluates the risk values ​​of assets A, B, and C included in the analysis target item 80. Assets A, B, and C represent data or functions that must be protected in the analysis target item 80. The analysis target item 80 may be configured as an ECU mounted on a vehicle, communicating wirelessly or via wired connections with external devices such as a smartphone 91 and a diagnostic device 92. The smartphone 91 is a smartphone, and the diagnostic device 92 is a diagnostic device that diagnoses vehicle defects and malfunctions. The analysis target item 80 includes physical components: a Bluetooth interface 81, a USB interface 82, a CAN interface 83, a main microcontroller 84, and a CAN microcontroller 85. The Bluetooth interface 81, also referred to as a Bluetooth I / F, is an interface for Bluetooth. The USB interface 82, also referred to as a USB I / F, is an interface for USB (Universal Serial Bus). The CAN interface 83, also referred to as a CAN I / F, is an interface for CAN. The main microcomputer 84 is a microcomputer that controls the analysis target item 80. The main microcomputer 84 has the above-mentioned assets A, B, and C. The CAN microcomputer 85 is a microcomputer that controls the CAN of the analysis target item 80. Note that physical components are hardware components.

[0100] Here, there are physical paths between the Main microcomputer 84 and each of the BT interface 81, the USB interface 82, and the CAN microcomputer 85. There is also a physical path between the BT interface 81 and the smartphone 91. There is also a physical path between the CAN microcomputer 85 and the CAN interface 83, and there is also a physical path between the CAN interface 83 and the Diag 92. Note that the physical paths are physical connection paths.

[0101] Additionally, physical components may be assigned an attack probability level. For example, the BT interface 81 is assigned an attack probability level of "Medium," and the USB interface 82 is assigned an attack probability level of "Very Low."

[0102] Furthermore, an impact level that an attack on an asset will have on the analysis target item 80 is set for each asset. For example, the impact level for asset A is set to "Moderate," the impact level for asset B is set to "Severe," and the impact level for asset C is set to "Major." The impact level is also called the impact degree.

[0103] The threat analysis system determines, for each of Asset A, Asset B, and Asset C, one or more attack paths to the asset. In other words, for each of Asset A, Asset B, and Asset C, the threat analysis system determines one or more physical paths consisting of an arrangement of one or more physical components from an external device to the asset.

[0104] For example, if smartphone 91 launches an attack on assets A, B, and C, smartphone 91 may access main microcomputer 84 via BT interface 81, which is assigned an attack probability level of "Medium." Alternatively, smartphone 91 may access main microcomputer 84 via USB interface 82, which is assigned an attack probability level of "Very Low." In other words, the attack paths to assets A, B, and C include an attack path via BT interface 81 and an attack path via USB interface 82. Therefore, the threat analysis system determines two attack paths for each of assets A, B, and C.

[0105] The threat analysis system determines a risk value for each of the determined attack paths for assets A, B, and C, using the level of attack probability corresponding to the attack path and the level of impact on the asset, while referring to the risk matrix table shown in (b) of Figure 9. In other words, the threat analysis system determines a risk value for each of the two attack paths to asset A, a risk value for each of the two attack paths to asset B, and a risk value for each of the two attack paths to asset C.

[0106] As shown in Figure 9(b), the risk matrix table shows the risk value corresponding to each combination of attack probability level and impact level. Attack probability levels are categorized as "Very Low," "Low," "Medium," and "High." These levels are arranged in ascending order. Impact levels are categorized as "Severe," "Major," "Moderate," and "Negligible." These levels are arranged in ascending order.

[0107] In the above example, the impact level of asset A is "Moderate," the impact level of asset B is "Severe," and the impact level of asset C is "Major." In addition, the attack probability level corresponding to one of the two attack paths is "Medium," and the attack probability level corresponding to the other is "Very Low."

[0108] Therefore, by referring to the risk matrix table, the threat analysis system determines, as the risk value of asset A, a risk value of "2" corresponding to the combination of the attack probability level "Medium" and the impact level of asset A "Moderate." Furthermore, the threat analysis system determines, as the risk value of asset A, a risk value of "1" corresponding to the combination of the attack probability level "Very Low" and the impact level of asset A "Moderate." Then, from the risk values ​​"2" and "1," the threat analysis system selects the maximum risk value, "2."

[0109] Similarly, by referencing the risk matrix table, the threat analysis system determines, as the risk value for asset B, a risk value of "4" corresponding to the combination of the attack probability level "Medium" and the impact level "Severe" of asset B. Furthermore, the threat analysis system determines, as the risk value for asset B, a risk value of "2" corresponding to the combination of the attack probability level "Very Low" and the impact level "Severe" of asset B. Then, from the risk values ​​"4" and "2," the threat analysis system selects the maximum risk value of "4."

[0110] Similarly, by referencing the risk matrix table, the threat analysis system determines, as the risk value for asset C, a risk value of "3" corresponding to the combination of the attack probability level "Medium" and the impact level "Major" of asset C. Furthermore, the threat analysis system determines, as the risk value for asset C, a risk value of "1" corresponding to the combination of the attack probability level "Very Low" and the impact level "Major" of asset C. Then, from the risk values ​​"3" and "1," the threat analysis system selects the maximum risk value, "3."

[0111] FIG. 10 is a diagram showing an example of the analysis result report d2 output from the output unit 17. As shown in FIG.

[0112] The output unit 17 outputs an analysis result report d2 including the determination result information d3 acquired from the pertinence determination unit 13, the reason information d5 acquired from the reason derivation unit 15, and the priority information d4 acquired from the priority derivation unit 16. That is, as shown in FIG. 10 , the analysis result report d2 indicates, for each CWE-ID, the title of the first vulnerability identified by the CWE-ID and the determination result as to whether the first vulnerability applies to the analysis target item. The title and the determination result are indicated in the determination result information d3. In the example of FIG. 10 , the analysis result report d2 also indicates, for each CWE-ID, the deployment destination of the first vulnerability identified by the CWE-ID. The deployment destination is, for example, a function having the first vulnerability among the functions included in the analysis target item (e.g., a remote parking function). The deployment destination may also be indicated in the determination result information d3.

[0113] Furthermore, for each CWE-ID, if the first vulnerability identified by that CWE-ID is not a relevant vulnerability, the analysis result report d2 indicates, as a determination reason, why the first vulnerability does not qualify as an analysis target item. This determination reason is indicated in reason information d5. For example, upon receiving determination result information d3 from the pertinence determination unit 13, the reason derivation unit 15 identifies the characteristic "password" of the first vulnerability based on the content of the first vulnerability, such as its title, indicated in the determination result information d3. The reason derivation unit 15 then derives, as the determination reason, that the characteristic "password" is not used in the "CAN communication function" where the first vulnerability is deployed, and outputs reason information d5 indicating this determination reason. The determination reason indicated by such reason information d5 is included in the analysis result report d2. As a result, the reason why the first vulnerability does not qualify as an analysis target item, i.e., the reason for non-applicability, is derived as the determination reason, thereby ensuring the reliability of the determination result by the pertinence determination unit 13.

[0114] Furthermore, for each CWE-ID, if the primary vulnerability identified by that CWE-ID is the relevant vulnerability, the analysis result report d2 indicates the priority of the countermeasure for that primary vulnerability as the countermeasure priority. This countermeasure priority is indicated in the priority information d4.

[0115] FIG. 11 is a flowchart showing an example of a series of processing operations of the category specifying unit 11, the pertinence determining unit 13, and the reason deriving unit 15.

[0116] First, the category identification unit 11 identifies one or more assets indicated in the design information d1 of the analysis target item (step S1). Then, the category identification unit 11 selects one asset from the one or more assets (step S2).

[0117] Next, the category identification unit 11 identifies one or more categories to which the selected asset belongs by referring to the first category information 12ad and the second category information 12bd (step S3). Note that the one or more categories may be the first and second categories described above.

[0118] Next, the pertinence determination unit 13 selects one type from the one or more types identified in step S3 (step S4).The pertinence determination unit 13 then searches for all first vulnerabilities associated with the selected type by referring to the vulnerability management information 14d, and determines whether each of the first vulnerabilities corresponds to the analysis target item (step S5).Furthermore, the pertinence determination unit 13 outputs determination result information d3 indicating the determination result of step S5 (step S6).

[0119] Next, the pertinence determination unit 13 determines whether there are any other types that were not selected in step S4 among the one or more types identified in step S3 (step S7). If the pertinence determination unit 13 determines that there are other types (Yes in step S7), it repeats the process from step S4 for the other types. On the other hand, if the pertinence determination unit 13 determines that there are no other types (No in step S7), the reason deriving unit 15 outputs the reason for non-applicability for each non-applicable first vulnerability indicated in all of the determination result information d3 output in step S6 (step S8). That is, the reason deriving unit 15 outputs reason information d5.

[0120] After the processing of step S8 is performed, the category identification unit 11 determines whether or not there are any other assets that have not been selected in step S2 among the one or more assets indicated in the design information d1 of the analysis target item (step S9). If the category identification unit 11 determines that there are other assets (Yes in step S9), it repeats the processing from step S2 on the other assets. On the other hand, if the category identification unit 11 determines that there are no other assets (No in step S9), it ends the processing related to the assets.

[0121] FIG. 12 is a flowchart showing an example of the processing operation of the priority derivation unit 16.

[0122] First, the priority derivation unit 16 selects one asset from one or more assets indicated in the design information d1 (step S11). Then, the priority derivation unit 16 executes the loop process of step S12 for each of all the vulnerabilities corresponding to the asset selected in step S11.

[0123] Specifically, the first priority derivation unit 21 derives a first coefficient for the vulnerability based on the SFOP (step S13). Furthermore, the first priority derivation unit 21 derives a second coefficient for the vulnerability based on the actual number of in-vehicle CVEs assigned (step S14). Furthermore, the first priority derivation unit 21 derives a third coefficient for the vulnerability based on the actual man-hours of countermeasures for the vulnerability (step S15). Then, the first priority derivation unit 21 derives a first priority of countermeasures for the vulnerability based on the first coefficient, second coefficient, and third coefficient derived in steps S13 to S15 (step S16).

[0124] Next, the second priority derivation unit 22 derives a second priority of a measure against the vulnerability based on the first priority derived in step S16 and the degree of impact on the architecture (step S17).

[0125] Next, the third priority derivation unit 23 derives a DFD for the analysis target item based on, for example, the design information d1 (step S18). Then, the third priority derivation unit 23 identifies one or more attack paths to the asset selected in step S11 based on the DFD (step S19). Furthermore, the third priority derivation unit 23 determines a risk value for the asset for each attack path identified in step S19 (step S20). Thereafter, the third priority derivation unit 23 selects the largest risk value from the risk values ​​for each attack path determined in step S20 (step S21). Then, the third priority derivation unit 23 derives the third priority of the countermeasure for the vulnerability as a countermeasure priority using the risk value selected in step S21 and the number of attack paths, which is the number of attack paths identified in step S19 (step S22). Such countermeasure priorities are derived for all of the vulnerabilities corresponding to the assets selected in step S11.

[0126] After the loop processing of step S12 is performed, the priority derivation unit 16 determines whether there are any other assets that have not been selected in step S11 from the one or more assets indicated in the design information d1 (step S23). If the priority derivation unit 16 determines that there are other assets (Yes in step S23), it repeatedly executes the processing from step S11 onwards. In step S11, another asset is selected, and in the loop processing of step S12, the third priority of countermeasures for all relevant vulnerabilities corresponding to the other assets, i.e., countermeasure priorities, are derived. On the other hand, if the priority derivation unit 16 determines that there are no other assets (No in step S23), it ends the processing for deriving countermeasure priorities.

[0127] While the vulnerability analysis system 10 and the vulnerability analysis method according to one or more aspects of the present disclosure have been described above based on the embodiments, the present disclosure is not limited to these embodiments. As long as the modifications do not deviate from the spirit of the present disclosure, various modifications conceivable by those skilled in the art may also be included in the present disclosure.

[0128] For example, in the above embodiment, the vulnerability analysis system 10 may determine whether the first vulnerability corresponds to an item to be analyzed and derive a countermeasure priority for the vulnerability, depending on the granularity of the asset indicated in the design information d1. In other words, the granularity of the asset may be a software configuration unit, a detailed module unit included in the software, or a function unit.

[0129] Furthermore, in the above embodiment, the CWE performance information 24d indicates the number of vulnerabilities identified by CVE-ID as the number of second vulnerabilities found in the past. However, the second vulnerabilities may be vulnerabilities other than those identified by CVE-ID. Furthermore, the CWE performance information 24d stored in the CWE performance storage unit 24 may be periodically updated. For example, the first priority derivation unit 21 may update the CWE performance information 24d by communicating with a computer external to the vulnerability analysis system 10 via a communications network. Similarly, the first priority derivation unit 21 may update the actual effort information 25d stored in the actual effort storage unit 25 by communicating with the computer via a communications network.

[0130] Furthermore, in the above embodiment, the reason deriving unit 15 derives the reason why the first vulnerability does not fall under the analysis target item, i.e., the reason for non-applicability. However, the present invention is not limited to this, and other factors may be derived. For example, the reason deriving unit 15 may derive reasons such as that a countermeasure against the first vulnerability has already been implemented, that there are other requirements that take priority over a countermeasure against the first vulnerability, or that a countermeasure against the first vulnerability will be implemented in a later process, and may derive these reasons. Such derivation by the reason deriving unit 15 may be performed by referring to a predetermined database.

[0131] In the above embodiment, each component included in the vulnerability analysis system 10 may perform the processing corresponding to that component in response to a human input operation, or may perform the processing automatically without receiving the input operation. Furthermore, a machine learning model showing the correlation between input and output may be used for the automatic processing.

[0132] In the above embodiments, each component may be configured with 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 (Central Processing Unit) or a processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory. Here, the software that realizes the evaluation support system of the above embodiments is a computer program that causes a computer to execute each step of the flowchart shown in Figure 11 or 12.

[0133] The following cases are also included in this disclosure:

[0134] (1) The at least one system or device is specifically a computer system comprising a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is stored in the RAM or hard disk unit. The at least one device achieves its function when the microprocessor operates in accordance with the computer program. Here, the computer program is composed of a combination of multiple instruction codes that indicate instructions to the computer to achieve a predetermined function.

[0135] (2) Some or all of the components constituting at least one of the above systems or devices may be configured as a single system LSI (Large Scale Integration). A system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip, and specifically, is a computer system configured including a microprocessor, ROM, RAM, etc. A computer program is stored in the RAM. The system LSI achieves its functions when the microprocessor operates in accordance with the computer program.

[0136] (3) Some or all of the components constituting at least one of the above systems or devices may be configured as an IC card or a standalone module that can be attached to or detached from the device. The IC card or module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned ultra-multifunctional LSI. The IC card or module achieves its functions when the microprocessor operates in accordance with a computer program. This IC card or module may be tamper-resistant.

[0137] (4) The present disclosure may be embodied as the methods described above, a computer program for implementing these methods on a computer, or a digital signal comprising the computer program.

[0138] The present disclosure may also be a computer program or a digital signal recorded on a computer-readable recording medium, such as a flexible disk, a hard disk, a CD (Compact Disc)-ROM, a DVD, a DVD-ROM, a DVD-RAM, a BD (Blu-ray (registered trademark) Disc), a semiconductor memory, etc. Alternatively, the present disclosure may be a digital signal recorded on such a recording medium.

[0139] The present disclosure may also be applied to transmitting a computer program or digital signal via a telecommunications line, a wireless or wired communication line, a network such as the Internet, data broadcasting, or the like.

[0140] Furthermore, the program or digital signal may be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network or the like, so that the program or digital signal may be implemented by another independent computer system. [Industrial Applicability]

[0141] The vulnerability analysis system of the present disclosure can be applied to devices or systems that analyze vulnerabilities in programs, etc., that are installed in vehicles, etc. [Explanation of symbols]

[0142] 10 Vulnerability Analysis System 11 Classification Specification Section 12 Classification storage section 12a Class 1 Storage Unit 12ad 1st classification information 12b Second Classification Storage Unit 12bd 2nd classification information 13 Applicability determination section 14 Vulnerability Management Repository 14d Vulnerability management information 15 Reason derivation part 16 Priority derivation part 17 Output section 21 First priority derivation part 22 Second priority derivation part 23 Third priority derivation part 24 CWE Achievement Storage 24d CWE performance information 25 Actual man-hours storage section 25d Actual man-hour information 26 Architecture Storage 26d Architecture Information d1 Design information d2 Analysis Results Report d3 Judgment result information d4 Priority information d5 Reason information

Claims

1. a classification storage unit that stores classification information indicating the type of asset for each asset owned by the vehicle; a classification identification unit that acquires design information indicating assets held by the analysis target item, and identifies the type of asset indicated by the design information by referring to the classification information; a correlation determination unit that determines whether or not each of one or more first vulnerabilities that are pre-associated with the identified type corresponds to the analysis target item; an output unit that outputs an analysis result report indicating the determination result by the non-determination unit, The plurality of types indicated by the classification information includes a type related to in-vehicle security. Vulnerability analysis system.

2. The classification storage unit a first classification storage unit that stores first classification information that associates each of one or more types related to the in-vehicle security with one or more assets classified into the type; and a second classification storage unit that stores second classification information that indicates, in association with each of one or more types of security not limited to the in-vehicle security, one or more assets classified into the type. The vulnerability analysis system according to claim 1 .

3. The vulnerability analysis system further comprises: a priority derivation unit that derives, for each of the first vulnerabilities determined to correspond to the analysis target item, a priority of a countermeasure against the vulnerability as a countermeasure priority; The vulnerability analysis system according to claim 1 .

4. The priority derivation unit (a) the impact of the vulnerability on the operation of a vehicle having the item being analyzed; (b) the number of times that a second vulnerability belonging to the vulnerability has been found in multiple vehicles in the past; and (c) the actual number of man-hours required to take measures against the vulnerability in the past; deriving the countermeasure priority for the vulnerability using at least one of the following: The vulnerability analysis system according to claim 3 .

5. The priority derivation unit deriving the countermeasure priority of the vulnerability using an impact level, which is the magnitude of the impact on the architecture of the asset that the analysis target item has; The vulnerability analysis system according to claim 3 .

6. The priority derivation unit deriving the countermeasure priority for the vulnerability using the level of impact that the analysis target item will have due to an attack on the asset, the level of possibility of an attack on the asset, and the number of attack paths on the asset; The vulnerability analysis system according to claim 3 .

7. The vulnerability analysis system further comprises: a reason deriving unit configured to derive a reason why the first vulnerability determined not to correspond to the analysis target item is not the analysis target item, The vulnerability analysis system according to claim 1 .

8. 1. A computer-implemented vulnerability analysis method, comprising: Acquire design information indicating the assets possessed by the item to be analyzed; Identifying the type of asset indicated by the design information by referring to classification information indicating the type of asset for each asset owned by the vehicle; determining whether or not each of one or more first vulnerabilities previously associated with the identified type corresponds to the item to be analyzed; outputting an analysis result report indicating a determination result for each of the one or more first vulnerabilities; The plurality of types indicated by the classification information includes a type related to in-vehicle security. Vulnerability analysis methods.

9. Acquire design information indicating the assets possessed by the item to be analyzed; Identifying the type of asset indicated by the design information by referring to classification information indicating the type of asset for each asset owned by the vehicle; determining whether or not each of one or more first vulnerabilities previously associated with the identified type corresponds to the item to be analyzed; outputting an analysis result report indicating a determination result for each of the one or more first vulnerabilities; Let the computer run The plurality of types indicated by the classification information includes a type related to in-vehicle security. program.

Images