Countermeasure output method, countermeasure output device, and program

Abstract

This provides a method for outputting countermeasures that can produce more appropriate security measures. [Solution] The countermeasure output method is a countermeasure output method executed by a computer, which acquires the importance level of each of a plurality of partitions, including a first partition and a second partition, that classify a plurality of functional units installed in a vehicle (S20), determines security measures for communication from the first functional unit to the second functional unit based on the first importance level of the first partition to which the first functional unit of the communication source belongs and the second importance level of the second partition to which the second functional unit of the communication destination belongs (S70), and outputs information regarding the determined security measures (S80).

Description

Technical Field

[0001] This disclosure relates to a countermeasure output method, a countermeasure output device, and a program.

Background Art

[0002] Patent Document 1 discloses calculating a risk value using technical elements in a system including data handled by an analysis target system, extracting the importance of facilities related to a corresponding attack scenario for a threat that generates a risk value exceeding a reference value, and selecting a number of security countermeasures according to the importance of this facility.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] By the way, it is desired to output more appropriate security countermeasures for the target system.

[0005] Therefore, this disclosure provides a countermeasure output method and the like that can output more appropriate security countermeasures.

Means for Solving the Problems

[0006] A countermeasure output method according to one aspect of the present disclosure is a countermeasure output method executed by a computer, which acquires the importance level of each of a plurality of partitions, including a first partition and a second partition, that classify a plurality of functional units installed in a vehicle, determines security measures for communication from the first functional unit to the second functional unit based on the first importance level of the first partition to which the first functional unit of the communication source belongs, and the second importance level of the second partition to which the second functional unit of the communication destination belongs, and outputs information regarding the determined security measures.

[0007] A countermeasure output device according to one aspect of the present disclosure includes: an acquisition unit that acquires the importance level of each of a plurality of partitions, including a first partition and a second partition, which classify a plurality of functional units mounted on a vehicle; a determination unit that determines security measures for communication from the first functional unit to the second functional unit based on the first importance level of the first partition to which the first functional unit of the communication source belongs, and the second importance level of the second partition to which the second functional unit of the communication destination belongs; and an output unit that outputs information relating to the determined security measures.

[0008] A program relating to one aspect of this disclosure is a program that causes a computer to execute the above-described countermeasure output method. [Effects of the Invention]

[0009] According to one aspect of this disclosure, it is possible to realize a method for outputting countermeasures that can output more appropriate security measures. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 is a block diagram showing the functional configuration of the countermeasure output device according to the embodiment. [Figure 2] Figure 2 shows an example of asset information according to the embodiment. [Figure 3] Figure 3 shows an example of a countermeasure policy according to the embodiment. [Figure 4] Figure 4 shows an example of a control strategy database according to the embodiment. [Figure 5] Figure 5 is a flowchart showing the operations performed by the countermeasure output device according to the embodiment. [Figure 6] Figure 6 is a diagram showing an example of a table illustrating the correspondence between the total SFOP value and the importance level according to the embodiment. [Figure 7] Figure 7 is a diagram illustrating the calculation of risk values ​​considering the importance level according to the embodiment. [Figure 8] Figure 8 is a diagram illustrating the determination of security measures in the countermeasure output device related to this disclosure. [Modes for carrying out the invention]

[0011] (Background leading to this disclosure, etc.) Prior to explaining this disclosure, we will describe the circumstances leading to this disclosure and the features of this application.

[0012] In the future, it is predicted that the automotive architecture will undergo transformation, with integration progressing between GW (Gateway), domain, and HPC (High Performance Computing). Furthermore, it is predicted that there will be an increase in cases where vehicles, as SDVs (Software Defined Vehicles), dynamically update their software to provide new value. This is not limited to vehicles, but is also thought to be the same for other objects that can communicate with the outside world. The vehicle may be a manually driven vehicle or an autonomous vehicle. Also, the vehicle may be an electric vehicle (EV) or a gasoline-powered vehicle.

[0013] Traditional vehicle security architectures primarily rely on perimeter defense or multi-layered defense. In these cases, the main countermeasures are set at the item boundary, assuming that unauthorized intrusions will not occur. However, due to integration and the increasing number of attack interfaces, the boundaries that need to be defended are becoming blurred, and traditional vehicle security architectures are increasingly proving insufficient in terms of security measures.

[0014] Meanwhile, in the IT industry, ZTA (ZeroTrustArch) is being considered, but there are concerns regarding its implementation in objects requiring real-time performance, such as vehicles, in terms of real-time capabilities and cost.

[0015] Therefore, the inventors of this application diligently studied methods for outputting countermeasures that can output more appropriate security measures, and devised the following methods for outputting countermeasures. For example, the inventors of this application devised a method for outputting countermeasures that can output security measures assuming unauthorized intrusion.

[0016] Here, as an architecture separate from ZTA, a new in-vehicle architecture is being considered in which each function within an item boundary is divided into specific partition units (for example, being considered in MILS (Model In the Loop Simulation)). This new in-vehicle architecture is based on the idea of ​​trusting within partitions but not trusting outside partitions (between partitions). Therefore, there is a risk when crossing partitions (when communicating between partitions), and security measures such as functional isolation are required. Partitions will be discussed later. In addition, MILS may be introduced, for example, during the vehicle specification design stage.

[0017] In the countermeasure output method and the like of the present disclosure, for example, the importance level of each partition is set based on the SFOP impact of information assets handled within the partition, etc., and the optimal security countermeasure is determined using the importance level of each of the two partitions to which functional units such as ECUs that execute information exchanges belong (for example, the difference in importance levels). Thereby, in the countermeasure output method and the like, assuming unauthorized intrusion, security countermeasures corresponding to the importance level (for example, the difference in importance levels) are set between partitions, and the security countermeasures set as more appropriate security countermeasures can be output. The SFOP impact includes information indicating in what aspects the asset has an impact, and for example, includes the degree of impact (damage impact) when the asset is tampered with, etc. The importance level may be set to a higher value, for example, as the degree of impact of the SFOP is greater.

[0018] Here, the partitions and the importance levels in the countermeasure output method according to the present embodiment will be described while referring to FIG. 8. FIG. 8 is a diagram for explaining the determination of security countermeasures in the countermeasure output device according to the present disclosure. FIG. 8 shows an example in which the importance level is set for each partition by the countermeasure output device according to the present disclosure, and security countermeasures corresponding to the difference in importance levels between partitions are determined and implemented. The item boundary indicates the boundary between the inside and outside of the vehicle.

[0019] Each partition shown in FIG. 8 is preset by partition information acquired from an external device. Each partition includes an external Part outside the vehicle, and an entry point Part, an app Part, a privacy Part, a safety Part, and a security Part inside the vehicle. Note that each partition shown in FIG. 8 is an example and is not limited thereto.

[0020] The external Part is a partition to which external devices of the vehicle belong, and includes, for example, various servers, user smartphones, charging and discharging devices, and diagnostic devices. Also, the importance level of the external Part is set to 1 by an importance level setting unit described later.

[0021] The entry point part is a partition to which functional units that communicate with external devices (e.g., wireless communication) belong, and includes, for example, functional units for external communication TLS (Transport Layer Security) and GW. Furthermore, the entry point part is set to a criticality level of 2 by the criticality level setting unit.

[0022] The App Part is a partition that contains functional sections related to applications different from those pre-installed on the vehicle (system applications), such as applications installed and modified by the user. For example, it includes a functional section for running third-party applications. The App Part is also set to an importance level of 3 by the importance level setting section.

[0023] The Privacy Part is a partition to which functions related to privacy belong, and for example, it includes functions for EV functions. Furthermore, the Privacy Part has its importance level set to 4 by the importance level setting unit.

[0024] The Safety Part is the partition to which the vehicle's safety-related functions belong. For example, it includes partitions containing functions for diagnostics (self-diagnostic functions), OTA (Over The Air), and ADAS (Advanced driver-assistance systems), and partitions containing functions for vehicle control and in-vehicle communication. The Privacy Part is set to a criticality level of 5 (for example, the maximum value) by the criticality level setting unit.

[0025] The Security Part is a partition to which the vehicle's security-related functional components belong, and for example, it includes functional components for secure protection. Furthermore, the Security Part is set to a criticality level of 5 by the criticality level setting unit.

[0026] Thus, in this disclosure, each partition is assigned a criticality level.

[0027] Then, the countermeasure search processing unit, which will be described later, determines the security measures to be taken when functional units communicate with each other, using the two severity levels set for the partition to which each functional unit belongs (in this case, the difference between those two severity levels).

[0028] The embodiments will be described in detail below with reference to the drawings. Specifically, a method for outputting countermeasures that can determine security measures when functional units communicate with each other using differences in importance levels as shown in Figure 8 will be described with reference to the drawings.

[0029] The embodiments described below are all comprehensive or specific examples. The numerical values, shapes, components, arrangement and connection configurations of components, steps, and the order of steps shown in the following embodiments are examples only and are not intended to limit this disclosure. Furthermore, any components in the following embodiments that are not described in an independent claim will be described as optional components.

[0030] Furthermore, in each figure, substantially identical components are denoted by the same reference numerals, and redundant explanations are omitted or simplified.

[0031] Furthermore, in this specification, terms indicating relationships between elements such as "same," as well as numerical values ​​and numerical ranges, are not expressions that represent only strict meanings, but also expressions that include substantially equivalent ranges, for example, differences of a few percent (or about 10%).

[0032] Furthermore, in this specification, ordinal numbers such as "first," "second," etc., do not mean the number or order of components unless otherwise specified, but are used to avoid confusion and to distinguish similar components.

[0033] (Embodiment) The countermeasure output method and other related aspects of this embodiment will be described below with reference to Figures 1 to 8.

[0034] [1. Configuration of the countermeasure output device] First, the configuration of the countermeasure output device that executes the countermeasure output method according to this embodiment will be described with reference to Figures 1 to 4. Figure 1 is a block diagram showing the functional configuration of the countermeasure output device 1 according to this embodiment. Note that Figure 1 shows an exemplary functional configuration of the countermeasure output device 1, and the functional configuration of the countermeasure output device 1 is not limited to Figure 1.

[0035] As shown in Figure 1, the countermeasure output device 1 comprises an acquisition unit 10, a criticality level setting unit 20, a risk analysis processing unit 30, a risk value calculation unit 40, a countermeasure search processing unit 50, an output unit 60, a first storage unit 70, a second storage unit 80, and a third storage unit 90. The countermeasure output device 1 also includes a processor and memory as part of its hardware configuration. The memory is ROM (Read Only Memory) and RAM (Random Access Memory), and can store programs executed by the processor. Each function of the countermeasure output device 1 is realized by the processor and other components that execute the programs stored in the memory. The countermeasure output device 1 may be implemented by a stationary PC (Personal Computer), a mobile terminal such as a smartphone or tablet, a server device, or a combination of two or more of these.

[0036] The acquisition unit 10 is a communication interface that acquires various information for outputting security measures in a vehicle. The acquisition unit 10 acquires partition information and design information via communication. The acquisition unit 10 may be configured to include, for example, a communication circuit (or a communication module). The acquisition unit 10 acquires various information via wireless communication, but it may also acquire various information via wired communication.

[0037] Partition information includes information about multiple ECUs (Electronic Control Units) installed in a vehicle, or information about multiple partitions, including a first partition and a second partition, which classify the functions of the ECUs. Partition information includes information that identifies multiple partitions, information that identifies the ECUs belonging to each partition, etc. An ECU is an example of a functional unit.

[0038] Here, ECU refers to an on-board ECU installed in a vehicle, which controls the vehicle's devices (equipment). An ECU is a device that includes, for example, a processor (microprocessor), digital circuits such as memory, analog circuits, and communication circuits. The memory is ROM, RAM, etc., and can store control programs (computer programs) executed by the processor. For example, the ECU realizes various functions by operating according to the control program (computer program) as shown in Figure 8. This control program includes third-party applications, etc.

[0039] Furthermore, the ECU may be an ECU that controls vehicle devices (a so-called zone ECU), or it may be a central ECU that integrates multiple ECUs (a so-called integrated ECU). An integrated ECU is an ECU that integrates functions that were previously installed in multiple ECUs, in order to solve the problem of increasing development time or cost due to the increasing complexity of in-vehicle systems (an example of a target system), and it is an ECU that utilizes virtualization technology to run multiple virtual computers (virtual machines: VMs) in a single ECU. In this way, one ECU may have multiple functions. In this case, each of the multiple functions realized by one ECU is an example of a functional unit.

[0040] A partition is a trusted boundary for data or processes that constitute the functionality of an ECU, and is set, for example, by the designer.

[0041] Here, the function of an ECU can also be said to be the assets that the ECU holds, that is, the "assets" of the ECU. In the field of security, the assets to be protected are sometimes classified from four perspectives: SFOP, namely Safety, Finance, Operational, and Privacy. Assets related to Safety include, for example, the vehicle's driving function and power supply function, and these assets correspond to the functions of the ECU related to the safety of the vehicle and, by extension, the occupants. Assets related to Finance include, for example, the vehicle itself and its cargo. These assets are protected by the locks on the vehicle's windows and doors, etc. Therefore, assets related to Finance correspond to the functions of the ECU related to such locks, etc. Assets related to Operational are, for example, the applications installed on the ECU, and correspond to the functions of the ECU that install such applications. Privacy includes, for example, the vehicle's driving records, video or audio captured by in-vehicle cameras, etc., and corresponds to the functions of the ECU that record data such as driving records.

[0042] "Retained assets" refers not only to tangible assets retained by the functions of functional units such as ECUs (hereinafter also simply referred to as ECUs), but may also include the functions or data possessed by the ECU, and the software installed in the ECU itself.

[0043] The partition information may include asset information indicating the assets held by each ECU. Asset information will be explained with reference to Figure 2.

[0044] Figure 2 shows an example of asset information according to this embodiment.

[0045] As shown in Figure 2, asset information includes the asset name, classification, and information indicating the direct impact in the event of a security breach.

[0046] Asset names are names used to identify assets, and examples include OEM (Original Equipment Manufacturing) reproduction confidential information and program update history.

[0047] The classification indicates the category of assets, with examples including copyrighted works and update history.

[0048] Information showing the direct impact of a security breach includes the SFOP impact of the asset, that is, the degree of impact (e.g., SFOP value) if the asset is misused, and includes the degree of impact on security, property, operational performance, and privacy. In the example in Figure 2, an example is shown that is represented by four impact levels: Severe (3), Major (2), Moderate (1), and Negligible (0), but the number of impact levels is not particularly limited as long as it is two or more.

[0049] The total represents the sum of the impact levels for each of the following categories: safety, property, operational performance, and privacy.

[0050] Furthermore, design information, also referred to as vehicle design information, includes design information regarding the in-vehicle system installed in the vehicle. Design information includes, for example, identification information for each ECU, information indicating the connection relationships of each ECU, and software information such as software versions. Design information is used when generating attack scenarios, which will be described later. Information indicating connection relationships may include, for example, placement information for each ECU within the in-vehicle system, or information indicating the communication paths of each ECU. Note that communication paths may include physical connections or paths integrated (considered as one) by a logical session.

[0051] The importance level setting unit 20 sets the importance level of each of the multiple partitions based on the contents of the assets (i.e., SFOPs) held by one or more functional units within that partition. The importance level only needs to include two or more levels and may be a numerical value such as 1 to 5, or a stage such as high, medium, low. The importance level setting unit 20 stores importance level information (for example, the importance level information 71 shown in Figure 1, which will be described later) indicating the importance level of each partition in the first storage unit 70. In this embodiment, the importance level of each partition is obtained by the importance level setting unit 20 setting the importance level. The importance level setting unit 20 is an example of an acquisition unit that acquires the importance level.

[0052] The importance level setting unit 20 may also set the importance level of the external part as shown in Figure 8. The importance level setting unit 20 may set the importance level of the external part based on the connection characteristics when the entry ECU and the external device communicate (for example, long-range wireless, short-range wireless, etc.). The importance level setting unit 20 may set a higher importance level when long-range wireless is used compared to when short-range wireless is used.

[0053] Long-range wireless communication refers to wireless communication that can cover distances ranging from several hundred meters to several kilometers or more, with examples including communication compliant with "IEEE 802.11ah". Near-field wireless communication refers to wireless communication with a communication distance of up to several tens of meters, with examples including ZigBee®, Bluetooth®, and Wi-Fi (Local Area Network).

[0054] The risk analysis processing unit 30 generates attack scenarios for each asset based on the design information. The attack scenario indicates which assets will be attacked and how, and includes the attack path and the target asset. The attack path includes the intrusion path (communication path) from the ECU that serves as the entry point (external intrusion point) to the ECU that serves as the target point of the attack (target ECU) in order to realize the threat scenario. The threat scenario indicates the purpose of the attack, and may be, for example, unauthorized access to predetermined information, tampering with ADAS control, or other scenarios that may threaten the safety, confidentiality, etc. of the vehicle. The attack path makes it possible to determine which ECUs (which partitions in this embodiment) are traversed in order to reach the target ECU from the entry ECU. The target asset indicates an asset that may be targeted in order to realize the threat scenario, and may be predetermined information, predetermined software, etc.

[0055] Furthermore, the risk analysis processing unit 30 may analyze vulnerabilities in each attack scenario. Vulnerabilities can be analyzed, for example, by determining whether the software of the ECUs included in the attack path has vulnerabilities, the number of ECUs included in the attack path (e.g., the number of stages), and defects in the security policy. Whether or not the software has vulnerabilities can be obtained from the software version and information indicating vulnerabilities found in the software. Defects in the security policy can also be obtained using the security policy version.

[0056] The risk value calculation unit 40 calculates a risk value, which is an indicator of the likelihood of being attacked, for each attack scenario. In other words, the risk value calculation unit 40 calculates one risk value for each attack scenario. The risk value calculation unit 40 calculates the risk value for the attack scenario based on at least one of the following: the number of stages from the entry ECU to the target ECU, the status of security measures already implemented, the connection characteristics when the entry ECU communicates with an external device, and whether or not the ECUs on the attack path have vulnerabilities. The risk value calculated based on this at least one is a risk value calculated in the usual way and is also referred to as the Feasibility value.

[0057] For example, a high risk value is calculated if the number of ECUs involved is small (e.g., less than a predetermined number), the communication method is remote wireless, or the ECUs along the attack path have vulnerabilities. The method for calculating the risk value is not particularly limited, and any known method may be used. Furthermore, the risk value is not limited to a numerical value, but may be expressed as a graded degree such as high, medium, or low. The risk value is just one example of a risk level.

[0058] The calculated risk value is used to determine whether or not the countermeasure search processing unit 50 will execute the process to determine security measures.

[0059] As will be described in more detail later, the risk value calculation unit 40 may also calculate the risk value using the importance level. For example, the risk value calculation unit 40 may calculate the risk value of the attack scenario using the importance level of at least one partition among the one or more partitions to which each of the one or more ECUs included in the attack scenario belongs.

[0060] The countermeasure search processing unit 50 determines the security measures to be implemented when ECUs belonging to different partitions communicate with each other. The countermeasure search processing unit 50 determines the security measures using the importance levels of the two partitions to which the communicating ECUs belong. In this embodiment, the countermeasure search processing unit 50 determines the security measures using the difference in importance levels of the two partitions. In other words, the countermeasure search processing unit 50 uses the difference in importance levels of the two partitions as a basis for determining the security measures. The countermeasure search processing unit 50 may also use the countermeasure policy 81 and the management countermeasure DB (database) 91, which will be described later, to determine the security measures. The countermeasure search processing unit 50 is an example of a decision-making unit for determining security measures.

[0061] By using differences in importance levels when deciding on security measures, it becomes possible to understand which communications between ECUs should receive priority security measures. For example, the larger the difference, the more important the security measures for that communication are. A larger difference leads to the determination of higher-strength security measures, allowing for a more differentiated approach to security measures and thus enabling more efficient implementation. Furthermore, compared to a system where uniform security measures are applied to all systems, it is possible to reduce the processing load on the information processing device required to implement security measures.

[0062] Furthermore, the countermeasure search processing unit 50 does not determine security measures for communication between functional units within the same partition. For example, in Figure 8, no security measures are provided for communication between vehicle control and in-vehicle communication, and between diagnostics and ADAS. In addition, security measures may or may not be determined for communication between functional units belonging to the same partition with the same criticality level. For example, in Figure 8, security measures may or may not be provided for communication between diagnostics, OTA and ADAS and secure protection, and between in-vehicle communication and secure protection.

[0063] The output unit 60 is a communication interface that outputs information regarding security measures determined by the countermeasure search processing unit 50 as recommended countermeasures. The output unit 60 may be configured to include, for example, a communication circuit (or a communication module). The information regarding security measures may include information indicating the content of the security measures.

[0064] The output unit 60 may transmit information regarding security measures to a terminal device, thereby presenting the security measures to the user. Alternatively, the output unit 60 may transmit information regarding security measures to a device on an in-vehicle network installed in the vehicle, thereby causing the device to implement the security measures. The output unit 60 outputs security measures via wireless communication, but it may also output security measures via wired communication.

[0065] The output unit 60 may also have a display device, which may display information including security measures to the user. The display device may be a display device including an LCD panel, a sound output device including a speaker, or any other device.

[0066] The first memory unit 70 is a memory device that stores important level information 71.

[0067] The second memory unit 80 is a memory device that stores the countermeasure policy 81. The countermeasure policy 81 specifies the rules for how to use the severity level to determine security measures. For example, the countermeasure policy 81 is used to determine security measures corresponding to differences in severity levels.

[0068] Figure 3 shows an example of the countermeasure policy 81 according to this embodiment. The security strength values ​​shown in Figure 3 indicate the relative relationship of security strength, with 0 being the lowest security strength and the security strength increasing as the value increases.

[0069] As shown in Figure 3, the countermeasure policy 81 shows the correspondence between the difference in importance level and the countermeasure content. Specifically, the countermeasure policy 81 shows the correspondence between the difference in importance level and the security strength of the countermeasure content. Security strength is an indicator that shows the degree of security (safety) in security measures, and the safer it is, the higher the security strength. In the example in Figure 3, when the difference in importance level is "0", a "countermeasure with security strength 0" is associated; when the difference in importance level is "1 and 2" (an example of the first value), a "countermeasure with security strength 1" is associated; and when the difference in importance level is "3 and 4" (an example of the second value), a "countermeasure with security strength 2" is associated. For example, the countermeasure policy 81 may include the case where, when the difference in importance level is a second value which is greater than the first value, the corresponding security strength is higher than the security strength corresponding to the first value.

[0070] Furthermore, in addition to the contents shown in Figure 3, the countermeasure policy 81 may include at least one of the following. For example, in data communication when there is a difference in severity level, the countermeasure policy 81 may include performing authentication between processes when communication is performed; in data communication from low severity level to high severity level, the receiving side may perform sanitization or filtering of input data; and in data communication from high severity level to low severity level, the transmitting side may encrypt or sign the data. Signing is done to confirm that the data has been transmitted without tampering (to ensure integrity). Furthermore, in access control when there is a difference in severity level, the countermeasure policy 81 may include, for example, performing data isolation in memory or performing mandatory access control (MAC) of resources when the communicating ECUs are implemented on the same CPU.

[0071] Furthermore, the countermeasure policy 81 may include, for example, recording all communication logs and implementing a resilience function in case of anomaly detection when the criticality level is Level 1 or higher (e.g., Level 4 or higher), or ensuring the Root of Trust (RoT) through secure boot by an HSM (Hardware Security Module) or dynamic tamper detection when the criticality level is Level 2 (e.g., Level 5 or higher). Also, the countermeasure policy 81 may include, for example, setting (resetting) the criticality level of each partition so that the criticality level or the difference in criticality levels of the start and goal partitions of the communication path is the same when the criticality level is Level 3 or higher (e.g., Level 4 or higher). For example, the first security measure executed when information is output from an entry point ECU to another ECU belonging to the first partition, or when information is output from an external device to the said ECU, and the second security measure executed when information is output from another ECU belonging to the second partition to the target point ECU, can be measures of the same security strength, that is, measures using the same algorithm. This allows, for example, if a signature is added as part of the first security measure, the second security measure can verify that signature, thereby effectively improving security performance.

[0072] Referring again to Figure 1, the third storage unit 90 is a storage device that stores the control measures DB 91. The control measures DB 91 includes candidates for security measures. An example of the control measures DB 91 will be described with reference to Figure 4. Figure 4 is a diagram showing an example of the control measures DB 91 according to this embodiment.

[0073] As shown in Figure 4, the control measures DB91 is a table that shows the correspondence between security strength, countermeasures against impersonation, and countermeasures against tampering.

[0074] The countermeasures against impersonation refer to security measures designed to prevent malicious third parties from impersonating the ECU (Electronic Control Unit) of an in-vehicle system and performing unauthorized actions such as outputting fraudulent information. The countermeasures against impersonation vary depending on the security level. For security level 1, password authentication is an example of the countermeasures, while for security level 2, multi-factor authentication, two-step authentication, or facial recognition are examples of countermeasures, but are not limited to these. It should be noted that a higher security level in authentication may mean that a greater amount of processing is required for authentication.

[0075] The countermeasures against tampering describe the security measures taken to prevent malicious third parties from tampering with the assets (e.g., information) held by each ECU. The security measures to prevent tampering differ depending on the security strength. For security strength 1, examples of countermeasures include signatures using RSA encryption or elliptic curve cryptography, while for security strength 2, examples of countermeasures include signatures using PQC (Post Quantum Cryptography) such as XMSS (eXtended Merkle Signature Scheme), but these are not limited to these. Note that security strength in relation to tampering refers to how difficult it is to decipher the ciphertext, and a higher security strength may mean a larger number of bits (length) in the encryption key. As security strength increases, security measures that increase the amount of information processing and cost in implementing the security measures may be determined.

[0076] Thus, the control DB91 includes different countermeasures for each security strength level. In other words, it includes different countermeasures depending on the difference in severity level. Furthermore, even when the security strength is 0, i.e., when the difference in severity level is 0, countermeasures may be set. Different countermeasures for each security strength level means, for example, that the quality of security measures differs for at least each security strength level.

[0077] Furthermore, based on Figure 4, one security measure may be determined for each difference in severity level, or multiple security measures may be determined. Also, based on Figure 4, it is sufficient that at least one of the countermeasures against impersonation and the countermeasures against tampering be determined for each difference in severity level.

[0078] Furthermore, the control measures DB91 may be a table that shows the correspondence between the difference in importance level (an example of a value based on the difference in importance level) and the countermeasures, rather than the correspondence between security strength (an example of a value based on the difference in importance level) and the countermeasures. In addition, the control measures DB91 may include countermeasures against cyberattacks other than impersonation and tampering.

[0079] The first to third storage units 70 to 90 are implemented by, for example, non-volatile storage devices (SSD (Solid State Drive) or HDD (Hard Disk Drive)), but are not limited to these. Furthermore, the first to third storage units 70 to 90 may be implemented by a single storage device, or each may be implemented by separate storage devices.

[0080] [2. Operation of the Countermeasure Output Device] Next, the operation of the countermeasure output device 1 configured as described above will be explained with reference to Figures 5 to 8. Figure 5 is a flowchart showing the operation (countermeasure output method) performed by the countermeasure output device 1 according to this embodiment. In other words, the countermeasure output method shown in Figure 5 is executed by a computer.

[0081] As shown in Figure 5, first, the acquisition unit 10 acquires partition information and design information (S10). The timing at which the acquisition unit 10 acquires the partition information and design information is not particularly limited. The acquisition unit 10 may store the partition information and design information in a storage unit (not shown) provided by the countermeasure output device 1.

[0082] Next, the importance level setting unit 20 sets the importance level for each partition (S20). The importance level setting unit 20 sets the importance level for each partition defined in the partition information based on the contents of the assets included in the partition information (see, for example, Figure 2).

[0083] Here, the process of setting the importance level in the importance level setting unit 20 will be explained with reference to Figure 6 in addition to Figure 2. Figure 6 is a diagram showing an example of a table that shows the correspondence between the total SFOP value (sum value) and the importance level according to this embodiment. This table may be obtained, for example, by being included in the partition information, or it may be stored in advance in the storage unit of the countermeasure output device 1. Figure 2 shows the assets held within the partition "Safety Part", and below, the method by which the importance level setting unit 20 sets the importance level of "Safety Part" will be explained as an example.

[0084] The importance level setting unit 20 calculates a single SFOP value corresponding to a partition based on the SFOP values ​​of each asset held within that partition. In the example in Figure 2, the importance level setting unit 20 may calculate a single SFOP value corresponding to the "Safety Part" based on the sum of the SFOP values ​​of the OEM Reproduction Confidential Information and Program Update History, which are assets held within the "Safety Part". For example, the importance level setting unit 20 may set the SFOP value corresponding to the "Safety Part" to the maximum sum of the sums of the OEM Reproduction Confidential Information and Program Update History. In the example in Figure 2, the importance level setting unit 20 sets the SFOP value corresponding to the "Safety Part" to 9, which is the sum of the OEM Reproduction Confidential Information. The importance level setting unit 20 may also set the SFOP value of the partition using other statistical values ​​such as the median, mode, or mean of the sum of the sums of the individual SFOP values, or it may set the SFOP value of the partition to the sum of the maximum values ​​of each SFOP.

[0085] The importance level setting unit 20 then sets the importance level of the partition based on the SFOP value of the partition and the table shown in Figure 6. Since the SFOP value corresponding to "Safety Part" is 9, the importance level setting unit 20 sets the importance level of "Safety Part" to 5, which corresponds to an importance level of 9 based on Figure 6. In the examples in Figures 2 and 6, the importance level of "Safety Part" is 5.

[0086] The importance level setting unit 20 sets the importance level for each partition in the same manner as described above.

[0087] Note that while Figure 6 shows an example where the maximum importance level (highest importance level) is 5, the maximum value is not limited to 5; any value of 2 or higher is acceptable.

[0088] The criticality level setting unit 20 may set the criticality level based on the placement information of each ECU in the in-vehicle system (for example, the number of steps from the entry point) instead of, or in conjunction with, the SFOP value. Furthermore, if there is no criticality level determination routine, the criticality level setting unit 20 may set the criticality level based on the implementation status of security measures within the partition.

[0089] A single criticality level may be set across multiple physical partitions, ECUs, LSIs, and logical software.

[0090] Referring again to Figure 5, the risk analysis processing unit 30 then performs risk analysis processing based on the design information (S30). Specifically, the risk analysis processing unit 30 generates attack scenarios for each asset based on the design information. The attack scenarios are generated independently of each partition.

[0091] Next, the risk value calculation unit 40 calculates the risk value for each attack scenario (S40). As described above, the risk value calculation unit 40 may calculate the risk value for the attack scenario based on at least one of the following: the number of ECUs that pass through from the entry ECU to the target ECU, the communication method used when the entry ECU communicates with an external device, and whether or not the ECUs on the attack path have vulnerabilities. Furthermore, the risk value calculation unit 40 may also calculate the risk value using the importance level set by the importance level setting unit 20. The calculation of the risk value using the importance level will be explained with reference to Figure 7. Figure 7 is a diagram for explaining the calculation of the risk value considering the importance level according to this embodiment. Figure 7 shows an example in which the weight of the Feasibility value, which is the risk value calculated using the number of ECUs etc. as described above, is 80%, and the weight of the importance level to the risk value is 20%.

[0092] The risk value calculation unit 40 may, for example, calculate a risk value that takes the importance level into account based on the following formula 1.

[0093] Feasibility value weight × Feasibility value + Importance level weight × Worst-case risk value × (Safety Part Importance Level) / (Maximum Importance Level) ··(Equation 1)

[0094] For example, if the Feasibility value (value indicating the possibility of attack) for an attack path (intrusion path) of various servers → external communication TLS → OTA is 8, and as shown in Figure 7, the Feasibility value: severity level = 80:20, and the worst-case (upper limit) risk value is 10, then the risk value calculation unit 40 calculates the risk value by substituting these values ​​into Equation 1. Note that the severity level of the safety part is 5, which was determined in step S20, and the maximum severity level is 5, as shown in Figure 6.

[0095] 0.8×8+0.2×10×5 / 5=8.4 (Formula 2)

[0096] Thus, the risk value considering the importance level is 8.4. 8.4 is a value that also takes into account the degree of impact of the infringement.

[0097] Furthermore, the risk value calculation unit 40 may adjust the risk value based on predetermined rules (for example, strengthening the risk when receiving S (security information) or transmitting P (privacy information)) based on the magnitude of the difference in importance levels (for example, absolute value) and SFOP attributes. In other words, the risk value calculation unit 40 may correct the calculated risk value based on predetermined rules. For example, the risk value calculation unit 40 may correct the calculated risk value to be higher when receiving S (security information) or transmitting P (privacy information).

[0098] Referring again to Figure 5, the risk value calculation unit 40 then determines whether security measures are necessary based on the risk value calculated in step S40 (S50). The risk value calculation unit 40 compares the risk value with a preset threshold and determines that security measures are necessary for attack scenarios where the risk value is greater than or equal to the threshold.

[0099] If the risk value calculation unit 40 determines that security measures are necessary (Yes in S50), the process proceeds to step S60. If the risk value calculation unit 40 determines that security measures are unnecessary (No in S50), the process terminates.

[0100] The countermeasure search processing unit 50 calculates the difference in severity levels between partitions within each of the one or more attack scenarios whose risk value is above a threshold (S60), and determines security measures for each partition based on the difference in severity levels between partitions (S70). In this way, security measures are determined for each of the one or more attack scenarios based on the risk value of that attack scenario. Note that the processing in steps S60 and S70 is performed for each of the one or more attack scenarios for which security measures are determined to be necessary.

[0101] The calculation of the difference in severity levels by the countermeasure search processing unit 50 and the determination of security measures will be explained with reference to Figure 8. Below, we will explain the cases when a user's smartphone communicates with the EV function and when a diagnostic device communicates with the diagnostic system.

[0102] When a user's smartphone communicates with the EV function, the communication path is in the order of user's smartphone, external communication TLS, and then the EV function. In this case, there is a risk of an attack where "the external communication TLS is spoofed, and the EV function receives false data from the spoofed external communication TLS."

[0103] Therefore, the countermeasure search processing unit 50 calculates the difference (here, 1) between the importance level set in the external Part (an example of the first functional unit of the communication source) (an example of the first important level, here 1) and the importance level set in the entry point Part (an example of the second partition) (an example of the second important level, here 2), and, based on the countermeasure policy 81 and the management measures DB 91, determines password authentication (first password authentication), which is a countermeasure against impersonation, as the security measure. Furthermore, in communication from an external communication TLS (an example of a first functional unit of the communication source) to an EV function (an example of a second functional unit of the communication destination), the countermeasure search processing unit 50 calculates the difference (here, 2) between the importance level set for the entry point Part (an example of a first partition) (an example of a first importance level, here, 2) and the importance level set for the EV function (an example of a second partition) (an example of a second importance level, here, 4), and determines password authentication (second password authentication), which is a countermeasure against impersonation, as the security measure based on the countermeasure policy 81 and the management measure DB 91. Note that different passwords may be used for the first password authentication and the second password authentication. For example, the password used for the second password authentication, which is a security measure between partitions closer to the target point, may be a password that is more difficult to crack than the password used for the first password authentication. A password that is difficult to crack may be, for example, a password with many characters, or a password that has strong conditions for the use of different types of characters such as letters, numbers, symbols, uppercase or lowercase letters.

[0104] Furthermore, when a diagnostic device communicates with a diagnostic system, the communication path is in the order of diagnostic device, gateway (GW), and then the diagnostic system. In this case, there is a risk of an attack where the gateway is impersonated, and the diagnostic system receives false data from the impersonated gateway.

[0105] Therefore, the countermeasure search processing unit 50 calculates the difference (here, 1) between the severity level set in the external part (an example of the first functional unit of the communication source) (an example of the first severity level, here, 1) and the severity level set in the entry point part (an example of the second partition) (an example of the second severity level, here, 2) for communication from the diagnostic device (an example of the first functional unit of the communication source) to the GW (an example of the second functional unit of the communication source), and determines password authentication, which is the countermeasure against impersonation, as the security measure based on the countermeasure policy 81 and the management measure DB 91. Furthermore, in communication from the GW (an example of the first functional unit of the communication source) to the Diag (an example of the second functional unit of the communication source), the countermeasure search processing unit 50 calculates the difference (here, 3) between the severity level set in the entry point Part (an example of the first partition) (an example of the first severity level, which is 2 here) and the severity level set in the Diag (an example of the second partition) (an example of the second severity level, which is 5 here), and, based on the countermeasure policy 81 and the management measures DB 91, determines at least one of the countermeasures against impersonation, namely multi-factor authentication, two-step authentication, and facial recognition, as the security measure. Based on the combination of the functional unit of the communication source and the functional unit of the communication destination, it may be predetermined which of the authentication methods to adopt from multi-factor authentication, two-step authentication, and facial recognition. For example, the countermeasure search processing unit 50 may determine multi-factor authentication as the security measure.

[0106] Thus, the decision on security measures is made by extracting security measures corresponding to the difference in criticality levels from the control DB91, which contains multiple security measures corresponding to the difference in criticality levels (e.g., security strength) based on the difference in criticality levels between partitions.

[0107] Furthermore, the countermeasure search processing unit 50 may adjust the strength of the security measures it determines based on the magnitude of the difference in importance levels (e.g., absolute value) and predetermined rules based on SFOP attributes (e.g., strengthening the reception of S (security information) and the transmission of P (privacy information)). In other words, the countermeasure search processing unit 50 may change the security measures it has determined based on predetermined rules. For example, the countermeasure search processing unit 50 may change the determined security measures to security measures with a security strength one level higher or one level lower based on predetermined rules.

[0108] The countermeasure search processing unit 50 may determine one or more (e.g., multiple) security measures based on at least one of the dynamic vehicle state and the anomaly detection state. The countermeasure search processing unit 50 may determine a larger number of security measures than when there is no (or low) abnormality or danger in driving based on at least one of the vehicle state and the anomaly detection state, for example, when the vehicle is traveling at a speed above a predetermined level, when there is an obstacle on the driving path, or when an abnormality is detected in the vehicle. The countermeasure search processing unit 50 may, for example, extract at least two of the following as security measures against impersonation with security strength 2: multi-factor authentication, two-step authentication, and facial recognition, when there is an abnormality or danger in driving based on at least one of the vehicle state and the anomaly detection state. The vehicle state may include the vehicle's driving state (driving, stopped, etc.), sensor values ​​(speed, steering angle, etc.), and the surrounding environment (e.g., obstacles or oncoming vehicles, etc.). The abnormality detection status indicates whether or not the Intrusion Detection System (IDS) has detected an abnormality in the vehicle.

[0109] Furthermore, the information from each device in the external part includes information indicating which functional unit (e.g., which ECU) it is communicating with.

[0110] Next, the output unit 60 outputs the security measures determined by the countermeasure search processing unit 50 (S80). The output unit 60 may output (or implement) multiple security measures based on at least one of the dynamic vehicle state and the anomaly detection state.

[0111] (Other embodiments) The above describes one or more embodiments of countermeasure output methods, etc., based on embodiments, but this disclosure is not limited to these embodiments. Without departing from the spirit of this disclosure, various modifications to these embodiments that a person skilled in the art could conceive, or forms constructed by combining components from different embodiments, may also be included in this disclosure.

[0112] For example, the above embodiment describes an example of determining security measures using the difference in importance levels between partitions, but is not limited to this, and security measures may be determined based on the importance levels of each of the two partitions performing communication. For example, security measures may be determined based on the relative importance levels (an example of the result of comparing importance levels). Specifically, different security measures may be determined depending on whether information is output from a partition with a relatively high importance level to a partition with a relatively low importance level, or from a partition with a relatively low importance level to a partition with a relatively high importance level. In this case, a table is prepared in advance that associates the relative importance levels with security measures. Alternatively, for example, security measures may be determined based on a single importance level determined based on the importance levels of each of the two partitions (for example, the higher importance level, or the importance level of the partition to which the communication source or transmission source functional unit belongs). In this case, a table is prepared in advance that associates the importance levels with security measures.

[0113] Furthermore, although the above embodiment describes an example in which the importance level setting unit 20 sets the importance level, the system is not limited to this, and the importance level may be obtained from an external device. For example, the partition information may include information indicating the importance level of each partition. Thus, the importance level of each partition may be obtained from an external device.

[0114] Furthermore, the countermeasure output device 1 according to the above embodiment may be used to determine security measures during the design phase of the in-vehicle system, or it may be used to update security measures after the in-vehicle system has been installed in a vehicle (for example, after the vehicle has been sold). For example, software vulnerabilities can change due to the discovery of new vulnerabilities, software updates via OTA, etc. Therefore, the countermeasure output device 1 may determine (update) security measures for the in-vehicle system after the vehicle has been sold. In this case, the countermeasure output device 1 may be installed in a device that can communicate with the vehicle (for example, a server device), or it may be installed in the vehicle.

[0115] Furthermore, the table shown in Figure 6 according to the above embodiment may be a table common to each partition, or it may be a different table for each partition.

[0116] Furthermore, the target object on which the countermeasure output device 1 according to the above embodiment is mounted or used is not limited to a vehicle. The target object may be, for example, an aircraft such as a drone, an electronic device such as a smartphone, or a home appliance.

[0117] Furthermore, the number of partitions included in the multiple partitions in the above embodiment is not particularly limited and may be two or more. Also, the number of functional units (e.g., ECUs) included in each partition is not particularly limited and may be one or more.

[0118] Furthermore, in the above embodiment, each component may be implemented by being composed of dedicated hardware or by executing a software program suitable for each component. Each component may also be implemented by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.

[0119] Furthermore, the order in which each step in the flowchart is performed is illustrative for the purpose of specifically illustrating this disclosure, and may be in a different order. Also, some of the above steps may be performed simultaneously (in parallel) with other steps, and some of the above steps may not be performed.

[0120] Furthermore, the division of functional blocks in the block diagram is just one example; multiple functional blocks can be implemented as a single functional block, a single functional block can be divided into multiple parts, or some functions can be moved to other functional blocks. In addition, the functions of multiple functional blocks with similar functions can be processed in parallel or time-sharing by a single piece of hardware or software.

[0121] Furthermore, the countermeasure output device 1 according to the above embodiment may be implemented as a single device or as a plurality of devices. When the countermeasure output device 1 is implemented as a plurality of devices, the individual components of the countermeasure output device 1 may be distributed among the plurality of devices in any manner. When the countermeasure output device 1 is implemented as a plurality of devices, the method of communication between the plurality of devices is not particularly limited and may be wireless communication or wired communication. In addition, wireless communication and wired communication may be combined between the devices.

[0122] Furthermore, each component described in the above embodiment may be implemented as software, or typically as an integrated circuit (LSI). These may be individually integrated onto a single chip, or some or all of them may be integrated onto a single chip. Here, we refer to them as LSIs, but depending on the degree of integration, they may also be called ICs, system LSIs, super LSIs, or ultra LSIs. Moreover, the method of integrated circuit implementation is not limited to LSIs; it may also be implemented using dedicated circuits (general-purpose circuits that execute dedicated programs) or general-purpose processors. After LSI manufacturing, a programmable FPGA (Field Programmable Gate Array) or a reconfigurable processor that allows for the reconfiguration of the connections or settings of circuit cells inside the LSI may be used. Furthermore, if an integrated circuit implementation technology that replaces LSIs emerges due to advances in semiconductor technology or other derived technologies, it is naturally possible to integrate the components using that technology.

[0123] A system LSI is a highly functional LSI manufactured by integrating multiple processing units onto a single chip. Specifically, it is a computer system composed of components such as a microprocessor, ROM, and RAM. The ROM stores the computer program. The system LSI achieves its function by operating according to the computer program, with the microprocessor working accordingly.

[0124] Furthermore, one aspect of this disclosure may be a computer program that causes a computer to execute each of the characteristic steps included in the countermeasure output method shown in Figure 5.

[0125] Furthermore, for example, the program may be a program to be executed by a computer. Also, in one aspect of this disclosure, such a program may be recorded on a computer-readable non-temporary recording medium. For example, such a program may be recorded on a recording medium and distributed or made available. For example, by installing the distributed program on a device having another processor and having that processor execute the program, it becomes possible to have that device perform the above-mentioned processes.

[0126] (Note) Based on the above description of embodiments, the following technologies are disclosed.

[0127] (Technology 1) A computer-based method for outputting countermeasures, comprising: obtaining the importance level of each of a plurality of partitions, including a first partition and a second partition, which classify a plurality of functional units installed in a vehicle; determining security measures for communication from the first functional unit to the second functional unit based on the first importance level of the first partition to which the first functional unit of the communication source belongs, and the second importance level of the second partition to which the second functional unit of the communication destination belongs; and outputting information regarding the determined security measures.

[0128] This allows security measures to be determined using the criticality levels of two partitions, the source and the destination, enabling more appropriate security measures to be determined for that communication compared to determining security measures using only one criticality level. Furthermore, by using the criticality levels between partitions, it is possible to determine security measures assuming unauthorized intrusion. Therefore, it is possible to determine more appropriate security measures in the event of unauthorized intrusion.

[0129] (Technology 2) The determination of the security measures is performed using the difference between the first and second criticality levels, which is the countermeasure output method of Technology 1.

[0130] This allows for the determination of more appropriate security measures based on differences in criticality levels.

[0131] (Technology 3) The determination of the aforementioned security measures is performed by extracting security measures corresponding to the difference between the first and second critical levels from a management measures database that includes multiple values ​​based on the difference in criticality levels between partitions and security measures corresponding to those values, which is the countermeasure output method of Technology 2.

[0132] This allows for the determination of more appropriate security measures for the management database, corresponding to differences in criticality levels.

[0133] (Technology 4) The value based on the difference in importance levels is the security strength, and the method for outputting countermeasures according to Technology 3 is performed using a countermeasure policy that shows the correspondence between the security strength and the difference in importance levels in the determination of the security countermeasures.

[0134] This allows for the determination of more appropriate security measures from the perspective of security strength.

[0135] (Technology 5) The aforementioned countermeasure policy is a countermeasure output method of Technology 4, which includes the condition that if the difference is a second value greater than the first value, the corresponding security strength becomes higher than the security strength corresponding to the first value.

[0136] This allows for the determination of stronger security measures when communicating with partitions that hold assets with a relatively high degree of impact from breaches, thereby effectively improving the security of the in-vehicle system.

[0137] (Technology 6) The aforementioned countermeasure policy is a countermeasure output method of Technology 5, which includes associating password authentication with the security strength corresponding to the first value, and associating at least one of multi-factor authentication, two-step authentication, and facial recognition with the security strength corresponding to the second value.

[0138] This allows for the determination of more appropriate security measures against impersonation.

[0139] (Technology 7) The aforementioned countermeasure policy is a countermeasure output method of Technology 5, which includes associating the use of a signature using RSA encryption or elliptic curve cryptography with the security strength corresponding to the first value, and associating the use of a signature using PQC (Post Quantum Cryptography) with the security strength corresponding to the second value.

[0140] This allows for the determination of more appropriate security measures against tampering.

[0141] (Technology 8) The acquisition of the aforementioned importance level is performed by setting the aforementioned importance level for each of the multiple partitions based on the content of the assets held by one or more functional units belonging to that partition, and is one of the countermeasure output methods from technologies 1 to 7.

[0142] This allows the importance level to be set automatically.

[0143] (Technology 9) Technology 8 is a method for outputting countermeasures, which involves acquiring design information including the connection relationships of the multiple functional units, generating multiple attack scenarios based on the design information, calculating the risk value for each of the multiple attack scenarios, and determining the security countermeasures for each of the multiple attack scenarios based on the risk value for that attack scenario.

[0144] This allows for the use of risk values ​​for each of multiple attack scenarios, enabling the determination of more appropriate security measures that take risk values ​​into account.

[0145] (Technology 10) The countermeasure output method of Technology 9 further uses the severity level of at least one of the one or more partitions to which each of the one or more functional units in the attack scenario belongs when calculating the risk value for each of the multiple attack scenarios.

[0146] This allows for the calculation of a risk value that considers not only the likelihood of an attack but also the degree of impact of a breach if one does occur. In other words, it allows for the calculation of a more appropriate risk value from the perspective of the degree of impact of a breach. By using such a risk value, more appropriate security measures can be determined.

[0147] (Technology 11) The decision on the security measures is a countermeasure output method of technology 9 or 10, which is performed for each of the multiple attack scenarios in which the calculated risk value is equal to or greater than a threshold.

[0148] This means that security measures are decided only for attack scenarios with high risk values, thus reducing the amount of information processing required to make security decisions.

[0149] (Technology 12) This is a security measure output device comprising: an acquisition unit that acquires the importance level of each of a plurality of partitions, including a first partition and a second partition, which classify a plurality of functional units installed in a vehicle; a determination unit that determines security measures for communication from the first functional unit to the second functional unit based on the first importance level of the first partition to which the first functional unit of the communication source belongs, and the second importance level of the second partition to which the second functional unit of the communication destination belongs; and an output unit that outputs information related to the determined security measures.

[0150] This will produce the same effect as the countermeasure output method described above.

[0151] (Technology 13) This is a program that causes a computer to execute one of the countermeasure output methods from technology 1 to 11.

[0152] This will produce the same effect as the countermeasure output method described above.

[0153] These general or specific embodiments may be implemented using a system, method, integrated circuit, computer program, or a non-temporary recording medium such as a computer-readable CD-ROM, or any combination of a system, method, integrated circuit, computer program, or recording medium. The program may be pre-stored on the recording medium or supplied to the recording medium via a wide-area communication network, including the Internet. [Industrial applicability]

[0154] This disclosure is useful for information processing devices, etc., that output security measures for a target. [Explanation of Symbols]

[0155] 1 Countermeasure output device 10 Acquisition Department 20. Importance Level Setting Unit (Acquisition Unit) 30 Risk Analysis Processing Unit 40. Risk Value Calculation Unit 50 Countermeasure Search Processing Unit (Decision Unit) 60 Output section 70 1st memory section 71. Importance Level Information 80 2nd memory section 81 Countermeasures Policy 90 Third memory section 91 Control DB

Claims

1. A method for outputting countermeasures performed by a computer, The importance level of each of the multiple partitions, including the first and second partitions, which classify the various functional parts installed in the vehicle, is obtained. Based on the first criticality level of the first partition to which the first functional unit of the communication source belongs, and the second criticality level of the second partition to which the second functional unit of the communication destination belongs, security measures for communication from the first functional unit to the second functional unit are determined. Output information regarding the determined security measures. Method for outputting countermeasures.

2. The decision on the security measures is made using the difference between the first and second criticality levels. The method for outputting countermeasures according to claim 1.

3. The determination of the security measures is performed by extracting the security measures corresponding to the difference between the first and second critical levels from a management measures database that includes multiple values ​​based on the difference in criticality levels between partitions and the security measures corresponding to those values. The countermeasure output method according to claim 2.

4. The value based on the difference in the aforementioned importance level represents security strength. The decision on the aforementioned security measures is made using a countermeasure policy that shows the correspondence between the security strength and the difference in the criticality level. The method for outputting countermeasures according to claim 3.

5. The aforementioned countermeasure policy includes the condition that if the difference is greater than a second value, the corresponding security strength is greater than the security strength corresponding to the first value. The countermeasure output method according to claim 4.

6. The aforementioned countermeasure policy includes the fact that password authentication is associated with the security strength corresponding to the first value, and at least one of multi-factor authentication, two-step authentication, and facial recognition is associated with the security strength corresponding to the second value. The countermeasure output method according to claim 5.

7. The aforementioned countermeasure policy includes associating the use of signatures using RSA encryption or elliptic curve cryptography with the security strength corresponding to the first value, and associating the use of signatures using PQC (Post Quantum Cryptography) with the security strength corresponding to the second value. The countermeasure output method according to claim 5.

8. The acquisition of the aforementioned importance level is performed by setting the importance level for each of the plurality of partitions based on the content of the assets held by one or more functional units belonging to that partition. The method for outputting countermeasures according to any one of claims 1 to 7.

9. The design information, including the connection relationships of the multiple functional parts, is acquired. Based on the aforementioned design information, multiple attack scenarios are generated, The risk value for each of the aforementioned multiple attack scenarios is calculated, The decision on the security measures is made in each of the multiple attack scenarios based on the risk value of that attack scenario. The countermeasure output method according to claim 8.

10. In calculating the risk value for each of the aforementioned multiple attack scenarios, the importance level of at least one of the one or more partitions to which each of the one or more functional units in the attack scenario belongs is further used. The countermeasure output method according to claim 9.

11. The security measures described above are determined for each of the multiple attack scenarios in which the calculated risk value is equal to or greater than the threshold. The countermeasure output method according to claim 9.

12. An acquisition unit that acquires the importance level of each of multiple partitions, including a first partition and a second partition, which classify the multiple functional parts installed in the vehicle, A determination unit that determines security measures for communication from the first functional unit to the second functional unit based on the first criticality level of the first partition to which the first functional unit of the communication source belongs, and the second criticality level of the second partition to which the second functional unit of the communication destination belongs, It comprises an output unit that outputs information regarding the determined security measures. Countermeasure output device.

13. A program for causing a computer to execute the countermeasure output method described in any one of claims 1 to 7.

Images