Threat analysis method and threat analysis system

Abstract

To provide a threat analysis method capable of precisely performing analysis of security risks.SOLUTION: A threat analysis method includes: an acquisition step (step S11) of acquiring system configuration information representing hardware components of a system as a target to threat analysis, and function allocation information representing functions allocated to the hardware components, asset information representing the assets used for the functions, asset input / output information representing hardware components of the asset input / output source and input / output destination; an analysis step (steps S12 and S13) of deriving a physical data flow representing the flow of assets to hardware components and a logical data flow representing the flow of assets to functions on the basis of, the obtained information, and analyzing the possibility of attacks on assets and the impact of attacks on assets for each hardware component and each function on the basis of, the physical data flow and the logical data flow; and an output step (step S14) of outputting analysis results.SELECTED DRAWING: Figure 7

Description

Technical Field

[0001] The present disclosure relates to a threat analysis method and a threat analysis system for analyzing threats to a system to be analyzed for threats.

Background Art

[0002] With the progress of vehicle CASE (Connected, Autonomous, Shared & Services, Electric), a network inside the vehicle such as CAN (Controller Area Network) or Ethernet (registered trademark) is connected to a smartphone or an external server through a network outside the vehicle such as Wi-Fi (registered trademark), Bluetooth (registered trademark), Cellular, V2X (Vehicle to X), etc., and countermeasures against external threats to the vehicle are required. In particular, analysis of security risks by threat analysis is important in the initial stage of the vehicle development life cycle.

[0003] For example, Patent Document 1 discloses a technique for extracting an access source (threat originator) to a component of a system based on a component of a system to be analyzed for threats, a configuration list of a communication path, and an assumed threat.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, when assuming malicious attacks caused by downloading and executing unauthorized third-party applications, unlike conventional physical hardware components and their communication channels, intrusion can occur from a logical session established by software between an external connected device and a vehicle. Therefore, with the technology disclosed in Patent Document 1, there is a risk that security risks cannot be accurately analyzed.

[0006] Therefore, the present disclosure provides a threat analysis method and the like that can accurately analyze security risks.

Means for Solving the Problems

[0007] A threat analysis method according to an aspect of the present disclosure includes an acquisition step of acquiring system configuration information indicating hardware components of a system to be analyzed for threats, function allocation information indicating functions assigned to the hardware components, asset information indicating assets used for the functions, and asset input / output information indicating the hardware components of the input / output sources and destinations of the assets; a derivation step of deriving a physical data flow indicating the flow of the assets with respect to the hardware components and a logical data flow indicating the flow of the assets with respect to the functions based on the system configuration information, the function allocation information, the asset information, and the asset input / output information, and analyzing the possibility of an attack on the assets and the impact of an attack on the assets for each of the hardware components and each of the functions based on the physical data flow and the logical data flow; and an output step of outputting the result of the analysis.

[0008] A threat analysis system according to an aspect of the present disclosure includes an acquisition unit that acquires system configuration information indicating hardware components of a system to be subjected to threat analysis, function allocation information indicating functions assigned to the hardware components, asset information indicating assets used for the functions, and asset input / output information indicating the hardware components that are the sources and destinations of input / output of the assets; an analysis unit that derives a physical data flow indicating the flow of the assets with respect to the hardware components and a logical data flow indicating the flow of the assets with respect to the functions based on the system configuration information, the function allocation information, the asset information, and the asset input / output information, and analyzes the possibility of an attack on the assets and the impact of an attack on the assets for each of the hardware components and each of the functions based on the physical data flow and the logical data flow; and an output unit that outputs the result of the analysis.

[0009] Note that these general or specific aspects may be implemented in a system, a method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be implemented in any combination of a system, a method, an integrated circuit, a computer program, and a recording medium. The recording medium may be a non-transitory recording medium.

Advantages of the Invention

[0010] According to a threat analysis method or the like according to an aspect of the present disclosure, security risks can be analyzed accurately.

Brief Description of the Drawings

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6A

Figure 6B

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17A

Figure 17B

Figure 17C

Figure 17D

DETAILED DESCRIPTION OF THE INVENTION

[0012] A threat analysis method according to an aspect of the present disclosure includes: an acquisition step of acquiring system configuration information indicating hardware components of a system to be analyzed for threats, function assignment information indicating functions assigned to the hardware components, asset information indicating assets used for the functions, and asset input / output information indicating the hardware components of the input / output sources and destinations of the assets; a derivation step of deriving a physical data flow indicating the flow of the assets with respect to the hardware components and a logical data flow indicating the flow of the assets with respect to the functions based on the system configuration information, the function assignment information, the asset information, and the asset input / output information, and performing an analysis of the possibility of an attack on the assets and the impact of an attack on the assets for each of the hardware components and each of the functions based on the physical data flow and the logical data flow; and an output step of outputting the result of the analysis.

[0013] According to this, in addition to the physical data flow of assets with respect to hardware components, the logical data flow of assets with respect to functions assigned to the hardware components is also used to analyze attacks on assets, in other words, to analyze security risks. Therefore, even when assuming an attack caused by downloading an unauthorized 3rd party application, it is possible to grasp threats due to intrusion from the logical session, and to accurately analyze security risks. For example, it is possible to comprehensively extract threats at the function level of the product. Also, by specifying the movement path of assets for each function from the logical data flow, it is possible to reduce the analysis of unnecessary paths.

[0014] For example, in the analysis step, the analysis may be further performed based on an attack possibility evaluation criterion defined for each of the hardware components and each of the functions to evaluate the possibility of an attack on the asset. By using the attack possibility evaluation criterion for evaluating the possibility of an attack on the asset, the analysis of the possibility of an attack on the asset can be performed more accurately.

[0015] For example, the attack possibility evaluation criterion may be determined based on design countermeasure information indicating countermeasures applied to each of the hardware components and each of the functions.

[0016] For example, it can be analyzed that the possibility of an attack is low for the hardware components and functions to which countermeasures against attacks are applied, and it can be analyzed that the possibility of an attack is high for the hardware components and functions for which the countermeasures against attacks are not sufficient.

[0017] For example, in the analysis step, the analysis may be further performed based on an impact evaluation criterion defined for each of the hardware components and each of the functions to evaluate the impact of an attack on the asset.

[0018] By using the impact evaluation criterion for evaluating the impact of an attack on the asset, the analysis of the impact of an attack on the asset can be performed more accurately.

[0019] For example, in the analysis step, a damage scenario or a threat scenario is further generated for each of the hardware components and each of the functions based on a predetermined database and the characteristics of the asset, and the result of the analysis may include the damage scenario or the threat scenario for each of the hardware components and each of the functions.

[0020] For example, by collating, as characteristics of the assets, the CIA classification or DFD classification of the assets, etc. with a predetermined database such as the STRIDE threat analysis model, damage scenarios or threat scenarios for security, property, operational performance, privacy, etc. can be generated.

[0021] For example, in the analysis step, based on the physical data flow and the logical data flow, an attack path to the asset in the physical data flow and the logical data flow may be identified, and the analysis may be performed based on the attack path.

[0022] By identifying the attack path, the security risk analysis can be performed more accurately. For example, a threat case can be materialized.

[0023] For example, the result of the analysis may include a risk value indicating the risk of an attack on the asset.

[0024] In this way, the result of the analysis may be represented by a risk value (numerical value), which makes it easier to judge the security risk from the risk value.

[0025] A threat analysis system according to an aspect of the present disclosure includes an acquisition unit that acquires system configuration information indicating hardware components of a system to be subjected to threat analysis, function allocation information indicating functions assigned to the hardware components, asset information indicating assets used for the functions, and asset input / output information indicating the hardware components of the input / output sources and destinations of the assets, a derivation unit that derives a physical data flow indicating the flow of the assets with respect to the hardware components and a logical data flow indicating the flow of the assets with respect to the functions based on the system configuration information, the function allocation information, the asset information, and the asset input / output information, and an analysis unit that analyzes the possibility of an attack on the assets and the influence of an attack on the assets for each of the hardware components and each of the functions based on the physical data flow and the logical data flow, and an output unit that outputs the result of the analysis.

[0026] According to this, it is possible to provide a threat analysis system that can accurately analyze security risks.

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

[0028] Note that all of the embodiments described below show comprehensive or specific examples. The numerical values, shapes, materials, 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.

[0029] (Embodiment) The threat analysis method and threat analysis system according to the embodiment will be described with reference to FIGS. 1 to 17D.

[0030] FIG. 1 is a block diagram showing an example of the configuration of a threat analysis system 10 according to the embodiment.

[0031] The threat analysis system 10 is a system for analyzing threats to a system to be analyzed for threats. The system to be analyzed for threats is, for example, a system related to an in-vehicle network or the like, and is a system including an ECU (Electronic Control Unit) and devices connected to the ECU.

[0032] The threat analysis system 10 includes an acquisition unit 11, an analysis unit 12, and an output unit 13. Also, an attack possibility evaluation criterion 26 and an impact evaluation criterion 27 are stored in the memory of the threat analysis system 10. The threat analysis system 10 is a computer including a processor (CPU: Central Processing Unit) and a memory, etc. The memory is a ROM (Read Only Memory), a RAM (Random Access Memory), etc., and can store programs executed by the processor. The acquisition unit 11, the analysis unit 12, and the output unit 13 are realized by a processor or the like that executes a program stored in the memory. Note that the memory storing the program and the memory storing the attack possibility evaluation criterion 26 and the impact evaluation criterion 27 may be different memories. The components constituting the threat analysis system 10 may be arranged in one housing, and the threat analysis system 10 may be a device. Also, the components constituting the threat analysis system 10 may be distributed and arranged in a plurality of housings (devices). For example, the threat analysis system 10 may be a server.

[0033] The acquisition unit 11 acquires system configuration information 21, function allocation information 22, asset information 23, asset input / output information 24, and design countermeasure information 25. For example, the threat analysis system 10 may have an input I / F (interface), and the acquisition unit 11 may acquire these pieces of information when the system configuration information 21, the function allocation information 22, the asset information 23, the asset input / output information 24, and the design countermeasure information 25 are input via the input I / F. Also, the threat analysis system 10 may have a communication I / F, and the acquisition unit 11 may acquire the system configuration information 21, the function allocation information 22, the asset information 23, the asset input / output information 24, and the design countermeasure information 25 via the communication I / F. Also, the system configuration information 21, the function allocation information 22, the asset information 23, the asset input / output information 24, and the design countermeasure information 25 may be stored in the memory of the threat analysis system 10, and the acquisition unit 11 may acquire the system configuration information 21, the function allocation information 22, the asset information 23, the asset input / output information 24, and the design countermeasure information 25 from the memory.

[0034] The system configuration information 21 is information indicating the hardware components of the system to be threat-analyzed. The system configuration information 21 will be described with reference to FIG. 2.

[0035] FIG. 2 is a block diagram showing an example of the hardware components indicated by the system configuration information 21.

[0036] For example, FIG. 2 shows the system configuration information 21 related to the ECU 100. For example, the system configuration information 21 includes, as hardware components, the ECU 100, an OEM (Original Equipment Manufacturer) server 200 communicably connected to the ECU 100, a smartphone 300 (for example, the smartphone of the user of a vehicle equipped with the ECU 100), a debug PC / diagnostic device 400, a vehicle control ECU 500, and a sensor ECU 600, and a communication ECU 700 for communicating between the ECU 100 and the OEM server 200, and a GW (GateWay) 800 for communicating between the ECU 100 and the sensor ECU 600. Further, the ECU 100 includes, as hardware components, an Ethernet I / F 101, a Bluetooth I / F 102, a USB (Universal Serial Bus) I / F 103, a CAN I / F 104, a Main CPU 105, a Sub CPU 106, an eMMC (embedded Multi Media Card) 107, a NOR Flash 108, and a JTAG (Joint Test Action Group) 109.

[0037] In addition, the system configuration information 21 includes information indicating the connection relationships between hardware components. In the ECU 100, the Main CPU 105 is connected to the I / Fs 101, 102, and 103, the Sub CPU 106, the eMMC 107, and the JTAG 109. The Sub CPU 106 is connected to the I / F 104, the Main CPU 105, the eMMC 107, the NOR Flash 108, and the JTAG 109. The I / F 101 is remotely wirelessly connected to the OEM server 200 etc. via the communication ECU 700, and is further remotely wirelessly connected to the smartphone 300 etc. via the OEM server 200. The I / F 102 is proximally wirelessly connected to the smartphone 300 etc. The I / F 103 is directly connected to the smartphone 300 and the debug PC / diagnostic device 400 etc. The I / F 104 is connected to the debug PC / diagnostic device 400 and the vehicle control ECU 500 etc. via the GW 800, and is also connected to the sensor ECU 600.

[0038] Based on the system configuration information 21, the intrusion path of an attack can be identified. For example, the intrusion paths via the OEM server 200, the communication ECU 700, and the I / F 101, the intrusion path via the GW 800 and the I / F 104, the intrusion path via the sensor ECU 600 and the I / F 104, and further, the intrusion path that directly enters the ECU 100 via the I / F 102 or 103 etc. can be identified.

[0039] The function allocation information 22 is information indicating the functions (application functions) allocated to the hardware components. The function allocation information 22 will be described with reference to FIG. 3.

[0040] FIG. 3 is a diagram showing an example of the function allocation information 22.

[0041] For example, the MainCPU 105 constitutes VMs (Virtual Machines) 105a and 105b. For example, the function assigned to VM 105a of the MainCPU 105 is the remote parking function, the functions assigned to VM 105b of the MainCPU 105 are the app addition function and the repro function, and the function assigned to the SubCPU 106 is the vehicle control function and the diag function, as shown in the function assignment information 22. Further, the function assignment information 22 may include information indicating logical function division by the CPU such as TrustZone, HyperVisior, or docker for execution environment separation within the same CPU, virtualization, and container technology. For example, the attack possibility evaluation criterion 26 described later may be determined based on information indicating such logical function division.

[0042] The asset information 23 is information indicating assets used for functions assigned to hardware components. The asset information 23 will be described with reference to FIG. 4.

[0043] FIG. 4 is a diagram showing an example of the asset information 23. Note that FIG. 4 also shows the impact evaluation criterion 27, which will be described later.

[0044] For example, FIG. 4 shows the parking position and authentication information as assets used for the remote parking function. Although not shown, destination information, driving trajectory, control messages, driving information, sensor information, etc. are also assets used for the remote parking function. Here, the asset information 23 indicating the assets used for the remote parking function is shown, but there is also asset information 23 for other functions (such as the app addition function, the repro function, the vehicle control function, and the diag function).

[0045] The asset input / output information 24 is information indicating the hardware components of the input source and output destination of the asset. The asset input / output information 24 will be described with reference to FIG. 5. Note that the input source means the input source and the output source, and the output destination means the input destination and the output destination.

[0046] FIG. 5 is a diagram showing an example of the asset input / output information 24. FIG. 5 shows, as an example of assets, a parking position, authentication information, and a control message.

[0047] For example, the hardware component that is the input source of the parking position is the smartphone 300, the hardware component that is the input destination is the eMMC 107, and the parking position is input from the smartphone 300 to the eMMC 107. For example, the hardware component that is the output source of the authentication information is the eMMC 107, the hardware component that is the output destination is the Main CPU 105, and the authentication information is output from the eMMC 107 to the Main CPU 105. For example, the hardware component that is the output source of the control message is the Main CPU 105, the hardware component that is the output destination is the vehicle control ECU 500, and the control message is output from the Main CPU 105 to the vehicle control ECU 500. Thus, the asset input / output information 24 includes information indicating the input-source hardware component and the input-destination hardware component for each asset, or the output-source hardware component and the output-destination hardware component.

[0048] The design countermeasure information 25 is information indicating countermeasures applied for each hardware component and each function. For example, for the hardware component, countermeasures such as an application Firewall, sandbox, mandatory access control, HIDS (Host-based Intrusion Detection System), or NIDS (Network-based Intrusion Detection System) may be applied. Also, for example, for the function, countermeasures such as encryption of assets, validity verification using a hash value, or memory access control may be applied. For example, the attack possibility evaluation criteria 26 described later may be determined based on the design countermeasure information 25.

[0049] Returning to the description of FIG. 1, the analysis unit 12 derives a physical data flow indicating the flow of assets to the hardware components and a logical data flow indicating the flow of assets to the functions based on the system configuration information 21, the function allocation information 22, the asset information 23, and the asset input / output information 24. Then, based on the derived physical data flow and logical data flow, the analysis unit 12 analyzes the possibility of an attack on the assets and the impact of an attack on the assets for each hardware component and each function. For example, the analysis unit 12 may further perform the above analysis based on the attack possibility evaluation criteria 26, the impact evaluation criteria 27, or the threat DB 28. Details of the operation of the analysis unit 12 will be described later.

[0050] The output unit 13 outputs the result of the analysis by the analysis unit 12. An example of the output analysis result (analysis result 30) will be described later.

[0051] The attack possibility evaluation criteria 26 are criteria for evaluating the possibility of an attack on the assets defined for each hardware component and each function. The attack possibility evaluation criteria 26 will be described with reference to FIGS. 6A and 6B.

[0052] FIGS. 6A and 6B are diagrams showing an example of the attack possibility evaluation criteria 26. FIG. 6A shows the attack possibility evaluation criteria 26 defined for each function, and FIG. 6B shows the attack possibility evaluation criteria 26 defined for each hardware component. An attack possibility evaluation in four predefined levels (High, Medium, Low, Very low) is performed.

[0053] Figure 6A shows the possibility of attacks on assets in the remote parking function, app addition function, replay function, vehicle control function, and diag function. For example, since the app addition function has a logical connection with the outside (session establishment), the possibility of an attack on the asset is High. For example, since the replay function has an intrusion detection function, the possibility of an attack on the asset is Medium. For example, since the remote parking function and the diag function have intrusion prevention functions, the possibility of an attack on the asset is Low. For example, since the vehicle control function has no logical connection with the outside, the possibility of an attack on the asset is Very low.

[0054] Figure 6B shows the possibility of attacks on assets in the hardware components with remote wireless entry points (such as I / F101), the hardware components with proximity wireless entry points (such as I / F102), the hardware components with direct connection entry points (such as I / F103 and 104), and the hardware components with physical connection entry points (such as MainCPU105 and SubCPU106). For example, since an attack on the hardware components with remote wireless entry points can be easily realized, the possibility of an attack on the asset is High. For example, since excessive effort is required to realize an attack on the hardware components with proximity wireless entry points, the possibility of an attack on the asset is Medium. For example, since a great deal of effort is required to realize an attack on the hardware components with direct connection entry points, the possibility of an attack on the asset is Low. For example, since an attack on the hardware components with physical connection entry points is almost impossible, the possibility of an attack on the asset is Very low.

[0055] Note that the attack possibility evaluation criteria 26 may be determined based on the design countermeasure information 25. For example, for functions or hardware components to which countermeasures against attacks are applied, criteria may be determined such that the possibility of an attack is reduced, and for functions or hardware components to which countermeasures against attacks are not applied, criteria may be determined such that the possibility of an attack is increased.

[0056] Also, the attack possibility evaluation criteria 26 determined for each function may be determined based on information indicating the logical function division included in the function allocation information 22. For example, for functions for which logical function division is performed, criteria may be determined such that the possibility of an attack is reduced, and for functions for which logical function division is not performed, criteria may be determined such that the possibility of an attack is increased.

[0057] The impact evaluation criteria 27 are criteria for evaluating the impact of an attack on an asset, determined for each hardware component and each function. The impact evaluation criteria 27 will be described with reference to FIG. 4.

[0058] The impact evaluation criteria 27 in FIG. 4 show the direct impact in the event of a security breach due to an attack on these assets, defined for the remote parking function that uses the parking position and authentication information. Specifically, in the remote parking function, when the parking position is attacked, a predefined four-level (Severe, Major, Moderate, Negligible) impact evaluation is performed from four perspectives: safety, property, operational performance, and privacy. For example, in the remote parking function, when the parking position is attacked, the impact from the safety perspective is Negligible and does not affect the vehicle's functions and performance; the impact from the property perspective is Major, resulting in a loss equivalent to the vehicle price; the impact from the operational performance perspective is Negligible and does not affect the vehicle's functions and performance; and the impact from the privacy perspective is Severe, as the parking position can be evaluated as information that can identify an individual.

[0059] The threat DB28 is a predetermined database used in threat analysis. For example, the threat DB28 is a threat analysis model of STRIDE proposed by Microsoft (registered trademark). Although details will be described later, the analysis unit 12 generates damage scenarios or threat scenarios for each hardware component and each function based on the threat DB28 and the characteristics of the assets.

[0060] Next, the operation of the threat analysis system 10 will be described with reference to FIG. 7.

[0061] FIG. 7 is a flowchart showing an example of the threat analysis method according to the embodiment. Since the threat analysis method is executed by the threat analysis system 10, FIG. 7 is also a flowchart showing an example of the operation of the threat analysis system 10 according to the embodiment.

[0062] First, the acquisition unit 11 acquires system configuration information 21 indicating the hardware components of the system to be analyzed for threat, function allocation information 22 indicating the functions assigned to the hardware components, asset information 23 indicating the assets used for the functions, and asset input / output information 24 indicating the hardware components of the input / output sources and destinations of the assets (step S11: acquisition step).

[0063] Next, the analysis unit 12 derives a physical data flow indicating the flow of assets with respect to the hardware components and a logical data flow indicating the flow of assets with respect to the functions based on the system configuration information 21, the function allocation information 22, the asset information 23, and the asset input / output information 24 (step S12: analysis step). An example of the physical data flow is shown in FIG. 8, and an example of the logical data flow is shown in FIG. 9.

[0064] FIG. 8 is a diagram showing an example of the physical data flow.

[0065] FIG. 9 is a diagram showing an example of the logical data flow.

[0066] In FIG. 8, as an example of the physical data flow, the flow of the parking position, authentication information, and control message with respect to the hardware components shown in FIG. 2 is shown. For example, the parking position flows from the smartphone 300 to the eMMC 107 via the I / F 102 and the MainCPU 105. For example, the authentication information flows from the eMMC 107 to the MainCPU 105. For example, the control message flows from the MainCPU 105 to the vehicle control ECU 500 via the SubCPU 106, the I / F 104, and the GW 800.

[0067] In FIG. 9, as an example of the logical data flow, the flow of the parking position, authentication information, and control message with respect to the functions shown in FIG. 3 is shown. For example, the parking position flows from the smartphone 300 to the eMMC 107 via the remote parking function. For example, the authentication information flows from the eMMC 107 to the remote parking function. For example, the control message flows from the remote parking function to the vehicle control ECU 500 via the vehicle control function. Although not shown, the flows from the app addition function to the remote parking function, from the reprogramming function to the remote parking function, from the eMMC 107 to the vehicle control function, from the diagnostic function to the vehicle control function, and from the sensor ECU 600 to the vehicle control function, etc., indicate the flows of other assets. From this logical data flow, it can be seen that the remote parking function may be separately controlled via VM - to - VM communication from app addition functions or reprogramming functions connected to the OEM server 200, etc., and it is necessary to analyze the combined impact in the case of intrusion from the logical sessions established by the app addition functions or reprogramming functions.

[0068] Since the information on the hardware components, functions, assets, input / output sources of assets, and input / output destinations of assets in each data flow is included in the system configuration information 21, function allocation information 22, asset information 23, and asset input / output information 24, the analysis unit 12 can derive the physical data flow and the logical data flow based on these information.

[0069] For example, the physical data flow may be the flow of data below the transport layer in the TCP / IP protocol suite, and the logical data flow may be the flow of data in the application layer (above the session layer in the OSI reference model) in the TCP / IP protocol suite.

[0070] Next, based on the derived physical data flow and logical data flow, the analysis unit 12 analyzes the possibility of an attack on the asset and the impact of the attack on the asset for each hardware component and function (step S13: analysis step).

[0071] For example, the analysis unit 12 may perform the analysis based on the attack possibility evaluation criteria 26. For example, it can be analyzed that the possibility of an attack on a hardware component or function with a High rating in the attack possibility evaluation criteria 26 is high, and the possibility of an attack on a hardware component or function with a Very low or Low rating in the attack possibility evaluation criteria 26 is low.

[0072] Note that the analysis unit 12 may not need to analyze the hardware components or functions with a Very low rating in the attack possibility evaluation criteria 26.

[0073] For example, the analysis unit 12 may perform the analysis based on the impact evaluation criteria 27. It can be analyzed that the impact of an attack on a hardware component or function with a Major or Severe rating in the impact evaluation criteria 27 is large, and the impact of an attack on a hardware component or function with a Negligible rating in the impact evaluation criteria 27 is small. At this time, as shown in FIG. 4, the analysis unit 12 may perform an impact analysis from each perspective of security, property, operation performance, and privacy.

[0074] Further, for example, the analysis unit 12 may generate damage scenarios or threat scenarios for each hardware component and function based on a predetermined database (e.g., threat DB 28) and the characteristics of the assets. This will be described with reference to FIGS. 10 to 12.

[0075] FIG. 10 is a diagram showing an example of a damage scenario generated based on the CIA classification.

[0076] The characteristics of the assets can be classified into confidentiality, integrity, or availability, for example, based on the CIA classification. FIG. 10 shows a threat DB 28 in which the CIA classification of the assets (assets used for the remote parking function) is associated with the damage scenario. By collating the characteristics (CIA classification) of the assets with the threat DB 28, damage scenarios can be generated. For example, since the destination information has an impact on I (integrity) and C (confidentiality) as the CIA classification, after splitting it into multiple lines for each CIA classification, based on the impact evaluation value (Impact) for each SFOP (safety, property, operational performance, privacy), for integrity, a damage scenario of "the integrity of the destination information is violated, and a major (loss equivalent to the vehicle price) impact occurs on the property" can be generated, and for the confidentiality of the destination information, a damage scenario of "the confidentiality of the destination information is violated, and a severe (able to identify an individual) impact occurs on privacy" can be generated.

[0077] FIG. 11 is a diagram showing an example of the DFD classification.

[0078] The characteristics of the assets can be classified into data flows based on the DFD classification. Note that functions can be classified into processes based on the DFD classification, and memories can be classified into data stores based on the DFD classification. As shown in FIG. 11, it can be seen that the assets, namely destination information, authentication ID (authentication information), driving trajectory, map data, control data, and driving information, are classified into data flows.

[0079] FIG. 12 is a diagram showing an example of a threat scenario generated based on the CIA classification and the DFD classification.

[0080] FIG. 12 shows a threat DB 28 in which combinations of the CIA classification and the DFD classification are associated with threat scenarios. In the threat scenario, the function name is described in [Process], the asset name is described in [Data Flow], and the memory name is described in [Data Store]. For example, regarding the integrity of the destination information, by referring to the row where the CIA characteristic in FIG. 12 is "I" and the DFD classification is "Data Flow", threat scenarios such as "the destination information is tampered with" and "false destination information is transmitted and received by impersonation" can be generated.

[0081] Also, for example, in step S13, the analysis unit 12 may identify an attack path to an asset in the physical data flow and the logical data flow based on the physical data flow and the logical data flow, and perform analysis based on the identified attack path. This will be described with reference to FIGS. 13 to 15.

[0082] FIG. 13 is a diagram showing an example of an intrusion path to a hardware component or function in the physical data flow and the logical data flow. FIG. 13 shows an intrusion path in the physical data flow and the logical data flow focusing on the remote parking function. Here, a number of other external communication functions including an app addition function and a reprogramming function that can affect the remote parking function of the MainCPU 105 are grouped together and described as other external communication to simplify the data flow.

[0083] For example, the attacker's intrusion paths include an intrusion path to the I / F 102 using Bluetooth communication, an intrusion path to the I / F 104 using CAN communication, an intrusion path to the I / F 101 using other external communication, an intrusion path from the I / F 101 to the MainCPU 105 and the SubCPU 106, and an intrusion path to the eMMC 107.

[0084] FIG. 14 is a diagram showing an example of an attack path to destination information in a physical data flow and a logical data flow.

[0085] For example, when focusing on destination information among each asset, it is assumed that an attacker will perform an attack through the intrusion path (attack path) shown in Step 1, the attack path shown in Step 2, and the attack path shown in Step 3. Here, for each of the attack paths from Step 1 to Step 3, threat scenarios can be concretized using the characteristics of the asset and the threat database 28.

[0086] FIG. 15 is a diagram showing an example of a threat scenario concretized from an attack path.

[0087] FIG. 15 shows a threat database 28 in which the types of the source and destination of the attack path are associated with threat scenarios. Here, the description is limited to threat scenarios of spoofing, tampering, and information leakage in the STRIDE classification, but descriptions regarding other service denial, repudiation, and privilege escalation may also be described as threat scenarios.

[0088] For example, for the attack path shown in Step 1, threat scenarios can be concretized by the part surrounded by the frame of Step 1 in FIG. 15. Note that [Process] describes Bluetooth communication, and [Data Flow] describes destination information. The type of the source of the attack path shown in Step 1 is the attacker, and the type of the destination is the process (Bluetooth communication). For the attack path shown in Step 1, when the threat scenario generated from FIG. 12 is tampering of I (integrity) from the CIA classification, threat scenarios such as "the attacker tampers with the code / data inside Bluetooth communication" can be concretized, and in the case of information leakage of C (confidentiality), threat scenarios such as "the attacker eavesdrops on the confidential information inside Bluetooth communication" and "the attacker eavesdrops on the destination information in Bluetooth communication" can be concretized.

[0089] For example, regarding the attack path shown in Step 2, the threat case can be specified by the part enclosed by the frame of Step 2 in FIG. 15. Note that Bluetooth communication is described in [Process A], the remote parking function is described in [Process B], and destination information is described in [Data Flow]. The original type of the attack path shown in Step 2 is a process (Bluetooth communication), and the subsequent type is also a process (remote parking function). Regarding the attack path shown in Step 2, with respect to tampering, a threat case such as "the tampered destination information is transmitted from Bluetooth communication to the remote parking function" can be specified.

[0090] For example, regarding the attack path shown in Step 3, the threat case can be specified by the part enclosed by the frame of Step 3 in FIG. 15. Note that the remote parking function is described in [Process], eMMC is described in [Data Store], and destination information is described in [Data Flow]. The original type of the attack path shown in Step 3 is a process (remote parking function), and the subsequent type is a data store (eMMC). Regarding the attack path shown in Step 3, with respect to tampering, a threat case such as "the tampered destination information is transmitted from the remote parking function to eMMC" can be specified.

[0091] Returning to the description in FIG. 7, the output unit 13 outputs the result of the analysis by the analysis unit 12 (analysis result 30) (step S14). The analysis result 30 will be described with reference to FIG. 16.

[0092] FIG. 16 is a diagram showing an example of the analysis result 30. In FIG. 16, an example of the analysis result 30 regarding the parking position used for the remote parking function is shown, but such analysis results 30 are output for each hardware component and each function.

[0093] For example, the analysis result 30 may include damage scenarios or threat scenarios for each hardware component and each function. For example, the analysis result 30 shown in FIG. 16 includes damage scenarios such as "the integrity of the parking position is violated, and a Major (loss equivalent to the vehicle price) impact occurs on the property" and threat scenarios such as "the integrity of the parking position is violated due to the tampering of the parking position, and a Major (loss equivalent to the vehicle price) impact occurs on the property".

[0094] Also, for example, the analysis result 30 may include a risk value indicating the risk of an attack on an asset. For example, it can be seen that the analysis result 30 shown in FIG. 16 includes a risk value of "3". The risk value can be calculated from, for example, an impact assessment criterion and an attack possibility assessment criterion.

[0095] FIGS. 17A to 17D are diagrams for explaining a method of calculating a risk value. FIG. 17A is a risk matrix from the perspective of property, FIG. 17B is a risk matrix from the perspective of safety, FIG. 17C is a risk matrix from the perspective of operation performance, and FIG. 17D is a risk matrix from the perspective of privacy.

[0096] For example, four separate matrices for calculating risk values based on the evaluation values of impact and attack possibility for each of safety, property, operation performance, or privacy may be defined, or they may be unified into one. For example, for the parking position used in the remote parking function shown in FIG. 16, if the possibility of an attack on the parking position is Medium and the impact from the perspective of property of an attack on the parking position is Major, the risk value can be calculated as "3" from the risk matrix shown in FIG. 17A. For example, when it is determined that the calculated risk value is at an unacceptable level as a product, after selecting "mitigation" as the risk mitigation method, cyber security goals are specified as countermeasures for the corresponding threat scenario. Note that when risk mitigation is not performed (risk acceptance, sharing, transfer, etc.), after stating the reasons, the validity is continuously managed according to changes in the risk situation.

[0097] Furthermore, in order to break down cyber security goals into specific product requirements, for each of the multiple attack paths calculated based on FIG. 15, product requirements may be specified as cyber security requirements as management measures or countermeasures called cyber security controls.

[0098] For example, by checking the analysis result 30, at the initial stage of the vehicle development life cycle, it is possible to recognize for each hardware component and function how likely it is to be attacked, what kind of impact there will be if it is attacked, and what kind of damage scenarios and threat scenarios are assumed, and take countermeasures in advance.

[0099] As described above, in addition to the physical data flow of assets with respect to hardware components, an analysis of attacks (security risks) on assets is performed based on the logical data flow of assets with respect to the functions assigned to the hardware components. Therefore, even when assuming an attack caused by the download of an unauthorized 3rd party application, it is possible to take measures against intrusion from the logical session, and the analysis of security risks can be performed accurately. For example, it is possible to comprehensively extract threats at the function level of the product. Also, by identifying the movement path of assets for each function from the logical data flow, the analysis of unnecessary paths can be reduced.

[0100] (Other Embodiments) As described above, the threat analysis method and the threat analysis system 10 according to the embodiments of the present disclosure have been described, but the present disclosure is not limited to the above embodiments.

[0101] For example, in the above embodiments, examples in which the physical data flow and the logical data flow are derived have been described, but further hierarchical data flows may be derived according to the progress of the design and the status of risk analysis in development.

[0102] For example, in the above embodiments, examples in which the analysis is performed based on the attack possibility evaluation criterion 26 have been described, but the attack possibility evaluation criterion 26 may not be used for the analysis. In this case, the attack possibility evaluation criterion 26 may not be stored in the memory of the threat analysis system 10.

[0103] For example, in the above embodiments, examples in which the analysis is performed based on the impact evaluation criterion 27 have been described, but the impact evaluation criterion 27 may not be used for the analysis. In this case, the impact evaluation criterion 27 may not be stored in the memory of the threat analysis system 10.

[0104] For example, in the above embodiment, an example in which the design countermeasure information 25 is acquired has been described, but the design countermeasure information 25 may not be acquired. In this case, the attack possibility evaluation criteria 26 may not be determined based on the design countermeasure information 25.

[0105] For example, in the above embodiment, an example in which a damage scenario or a threat scenario is generated has been described, but the damage scenario or the threat scenario may not be generated. In this case, the analysis result 30 may not include the damage scenario or the threat scenario.

[0106] For example, in the above embodiment, an example in which an attack path to an asset in a physical data flow and a logical data flow is identified has been described, but the attack path may not be identified.

[0107] For example, in the above embodiment, an example in which the analysis result 30 includes a risk value has been described, but the analysis result 30 may not include the risk value.

[0108] For example, in the above embodiment, an example in which the attack possibility evaluation criteria 26 and the impact evaluation criteria 27 are stored in the memory of the threat analysis system 10 has been described, but they may be stored in a device external to the threat analysis system 10, and the threat analysis system 10 may acquire the attack possibility evaluation criteria 26 and the impact evaluation criteria 27 from the external device.

[0109] For example, the steps in the threat analysis method may be executed by a computer (computer system). And the present disclosure can be realized as a program for causing a computer to execute the steps included in the threat analysis method.

[0110] Furthermore, the present disclosure can be realized as a non-transitory computer-readable recording medium such as a CD-ROM on which the program is recorded.

[0111] For example, when the present disclosure is implemented by a program (software), each step is executed by using hardware resources such as a computer's CPU, memory, and input / output circuits. That is, each step is executed by the CPU acquiring data from the memory or input / output circuits or the like and performing calculations, or outputting the calculation result to the memory or input / output circuits or the like.

[0112] In addition, each component included in the threat analysis system 10 of the above embodiment may be realized as a dedicated or general-purpose circuit.

[0113] In addition, each component included in the threat analysis system 10 of the above embodiment may be realized as a large-scale integration (LSI) which is an integrated circuit (IC).

[0114] In addition, the integrated circuit is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. A programmable field-programmable gate array (FPGA), or a reconfigurable processor in which the connection and setting of circuit cells inside the LSI can be reconfigured may be used.

[0115] Furthermore, if a technology for integrating circuits that replaces LSI appears due to the progress of semiconductor technology or other derived technologies, naturally, each component included in the threat analysis system 10 may be integrated using that technology.

[0116] In addition, forms obtained by applying various modifications that those skilled in the art can come up with to the embodiments, and forms realized by arbitrarily combining the components and functions in each embodiment without departing from the gist of the present disclosure are also included in the present disclosure.

Industrial Applicability

[0117] The present disclosure can be applied to a system for analyzing security risks of vehicles and the like.

Explanation of Signs

[0118] 10 Threat Analysis System 11 Acquisition Unit 12 Analysis Unit 13 Output Unit 21 System Configuration Information 22 Function Allocation Information 23 Asset Information 24 Asset Input / Output Information 25 Design Countermeasure Information 26 Attack Possibility Evaluation Criteria 27 Impact Evaluation Criteria 28 Threat DB 30 Analysis Results 100 ECU 101, 102, 103, 104 I / F 105 MainCPU 105a, 105b VM 106 SubCPU 107 eMMC 108 NOR Flash 109 JTAG 200 OEM Server 300 Smartphone 400 Debug PC / Diagnostic Equipment 500 Vehicle Control ECU 600 Sensor ECU 700 Communication ECU 800 GW

Claims

1. An acquisition step of acquiring system configuration information indicating hardware components of a system to be analyzed for threats, function assignment information indicating functions assigned to the hardware components, asset information indicating assets used for the functions, and asset input / output information indicating the hardware components that are the sources and destinations of input / output of the assets; An analysis step of deriving a physical data flow indicating the flow of the assets with respect to the hardware components and a logical data flow indicating the flow of the assets with respect to the functions based on the system configuration information, the function assignment information, the asset information, and the asset input / output information, and performing an analysis of the possibility of an attack on the assets and the impact of an attack on the assets for each of the hardware components and each of the functions based on the physical data flow and the logical data flow; An output step of outputting the results of the analysis for each of the hardware components and each of the functions, A threat analysis method.

2. In the analysis step, the analysis is further performed based on attack possibility evaluation criteria defined for each of the hardware components and each of the functions for evaluating the possibility of an attack on the assets. The threat analysis method according to Claim 1.

3. The attack possibility evaluation criteria are determined based on design countermeasure information indicating countermeasures applied to each of the hardware components and each of the functions. The threat analysis method according to Claim 2.

4. In the analysis step, the analysis is further performed based on impact evaluation criteria defined for each of the hardware components and each of the functions for evaluating the impact of an attack on the assets. The threat analysis method according to any one of Claims 1 to 3.

5. In the analysis step, damage scenarios or threat scenarios are further generated for each of the hardware components and each of the functions based on a predetermined database and characteristics of the assets, The results of the analysis include the damage scenarios or the threat scenarios for each of the hardware components and each of the functions. The threat analysis method according to any one of Claims 1 to 4.

6. In the analysis step, based on the physical data flow and the logical data flow, attack paths to the assets in the physical data flow and the logical data flow are identified, and the analysis is performed based on the attack paths. The threat analysis method according to any one of claims 1 to 5.

7. The result of the analysis includes a risk value indicating the risk of an attack on the asset. The threat analysis method according to any one of claims 1 to 6.

8. An acquisition unit that acquires system configuration information indicating hardware components of a system to be subjected to threat analysis, function assignment information indicating functions assigned to the hardware components, asset information indicating assets used for the functions, and asset input / output information indicating the hardware components that are the input / output sources and destinations of the assets; Based on the system configuration information, the function assignment information, the asset information, and the asset input / output information, a physical data flow indicating the flow of the assets with respect to the hardware components and a logical data flow indicating the flow of the assets with respect to the functions are derived, and based on the physical data flow and the logical data flow, an analysis of the possibility of an attack on the assets and the impact of an attack on the assets is performed for each of the hardware components and each of the functions; An output unit that outputs the result of the analysis for each of the hardware components and each of the functions. A threat analysis system.

Images