Security measure determination device, software management device, and trust infrastructure system

Abstract

A security measure determination device (100) comprises: a reception unit (101) that receives software and quality information assigned to the software from a software management device (200); a security measure determination unit (104) that determines, on the basis of the quality information, a security measure required when executing the software; and an output unit (104) that outputs a measure instruction indicating the security measure to a software execution device (300) that executes the software.

Description

Security Countermeasure Decision Device, Software Management Device, and Trusted Infrastructure System Cross - reference to Related Applications

[0001] This application is based on Japanese Patent Application No. 2024 - 162215 filed on September 19, 2024, the contents of which are incorporated herein by reference.

[0002] This application relates to a trusted infrastructure system configured such that when software is distributed from a software management device to a software execution device and the software is executed, a security countermeasure decision device takes appropriate security countermeasures.

[0003] In recent years, activities in the physical space are gradually being replaced by those in the cyber space. To achieve this, it is essential to build a reliable infrastructure for the circulation of data, etc., and the importance of trust services, which are mechanisms to prevent data tampering, spoofing of the source, etc., is increasing.

[0004] Also, in the field of automobiles, various electronic control devices connected by an in - vehicle network are installed in vehicles, and various software is executed on each electronic control device.

[0005] Patent Document 1 discloses receiving software and a security risk list from an application developer, conducting a review of the software, registering the software in association with the security risk list in a software distribution management server system, and distributing the software in association with the security risk list in response to a software distribution request from a user.

[0006] JP - A - 2019 - 56999

[0007] Here, the inventors have identified the following problems after detailed consideration. The software installed in a vehicle may include not only robust, high-quality software, but also third-party software or software developed through development operations (DevOps) to meet various user needs. Therefore, there is a possibility that software of different quality levels may coexist in the vehicle. In this case, cyber attackers may attempt to infiltrate by starting with low-quality software and then attempt to attack the high-quality software. According to the technology in Patent Document 1, security measures are based on developer declarations, so there is a possibility that security measures that take into account the quality of the software may not be implemented.

[0008] Therefore, this disclosure aims to realize a security measure determination device, a software management device, and a trust infrastructure system that can implement appropriate security measures according to the quality of the software.

[0009] A security measures determination device according to one aspect of the present disclosure includes a receiving unit that receives software and quality information assigned to the software from a software management device, a security measures determination unit that determines the security measures required for the execution of the software based on the quality information, and an output unit that outputs a security measures instruction indicating the security measures to a software execution device that executes the software.

[0010] The numbers in parentheses attached to the claims and the constituent elements of the invention described in this section indicate the correspondence between the present invention and the embodiments described later, and are not intended to limit the present invention.

[0011] With the above configuration, the software management device analyzes the quality of the software, assigns quality information to the software, and transmits it to the security measures decision device. The security measures decision device then determines security measures based on the quality information received, allowing for appropriate security measures to be taken according to the quality of the software. As a result, even in environments where software of different quality levels coexist, it is possible to prevent an overall decrease in security level.

[0012] The above-mentioned and other purposes, features, and benefits of this disclosure will be further clarified by the following detailed description with reference to the attached drawings. The drawings are as follows: Figure 1 is an explanatory diagram illustrating the arrangement of the security measures decision device, software management device, and software execution device; Figure 2 is an explanatory diagram illustrating the arrangement of the security measures decision device and software execution device in a vehicle; Figure 3 is a block diagram illustrating the configuration examples of the software management device in Embodiments 1 to 3; Figure 4 is an explanatory diagram illustrating the fields of the public key certificate that record quality information; Figure 5 is an explanatory diagram illustrating the extended fields of the public key certificate that record quality information; Figure 6 is an explanatory diagram illustrating the fields of the attribute certificate that record quality information; Figure 7 is a block diagram illustrating the configuration example of the security measures decision device in Embodiment 1; Figure 8 is a flowchart illustrating the operation of each device in Embodiment 1; Figure 9 is a block diagram illustrating the configuration example of the security measures decision device and software execution device in Embodiment 2; Figure 10 is a flowchart illustrating the operation of each device in Embodiment 2; Figure 11 is a block diagram illustrating the configuration example of the security measures decision device in Embodiment 3; and Figure 12 is a block diagram illustrating the configuration example of the security measures decision device and software execution device in Embodiment 3.

[0013] The embodiments of this disclosure will be described below with reference to the drawings.

[0014] The present invention as described below means the invention described in the claims and is not limited to the embodiments described below. Furthermore, at least double quotation marks mean the words described in the claims and are not limited to the embodiments described below.

[0015] The configurations and methods described in the dependent claims are optional configurations and methods in the invention described in the independent claims. The configurations and methods in embodiments corresponding to the configurations and methods described in the dependent claims, as well as configurations and methods described only in embodiments and not in the claims, are optional configurations and methods in the present invention. The configurations and methods described in embodiments when the claims are broader than the descriptions in embodiments are also optional configurations and methods in the present invention, in the sense that they are illustrative examples of the configurations and methods of the present invention. In any case, by being described in the independent claims, they become essential configurations and methods of the present invention.

[0016] The effects described in the embodiments are those that occur when the configuration is that of an exemplary embodiment of the present invention, and are not necessarily effects that the present invention possesses.

[0017] When there are multiple embodiments (including examples and modifications; the same applies hereinafter in this paragraph), the disclosed configuration in each embodiment is not confined to that embodiment alone, but can be combined across embodiments. For example, the disclosed configuration may be combined in one embodiment with another. Alternatively, the disclosed configuration may be collected and combined in each of multiple embodiments.

[0018] The problems described in this disclosure are not publicly known problems, but rather things that the inventors have discovered independently, and these facts, along with the structure and method of this disclosure, affirm the inventive step of the invention.

[0019] 1. Premise of Each Embodiment (1) Layout Diagram 1 of the Security Measures Decision Device 100, Software Management Device 200, and Software Execution Device 300 is a diagram illustrating the arrangement of the Security Measures Decision Device 100, the Software Management Device 200, and the Software Execution Device 300. First, the overview and connection method of each device will be explained using Figure 1(a). The Software Management Device 200 is a device that manages software and distributes software to the Security Measures Decision Device 100. The Security Measures Decision Device 100 is a device that receives software from the Software Management Device 200 and transmits the software and countermeasure instructions indicating security measures to the Software Execution Device 300. The Software Execution Device 300 is a device that receives software and countermeasure instructions from the Security Measures Decision Device 100, executes the software, and executes the security measures instructed in the countermeasure instructions. The Security Measures Decision Device 100, the Software Management Device 200, and the Software Execution Device 300 together are referred to as the Trust Infrastructure System 1. As will be described later, the security measures determination device 100 and the software execution device 300 may be the same device.

[0020] The placement locations of the security measure determination device 100, the software management device 200, and the software execution device 300 are arbitrary. In other words, the placement locations of these devices and the distances between them are arbitrary.

[0021] Each device is connected via either wired or wireless communication. Examples of wired communication include the Internet, fixed telephone lines, and Ethernet®. When using an in-vehicle network, CAN (Controller Area Network) or LIN (Local Interconnect Network) can be used. Examples of wireless communication include IEEE 802.11 (Wi-Fi®), IEEE 802.16 (WiMAX®), W-CDMA (Wideband Code Division Multiple Access), HSPA (High Speed ​​Packet Access), LTE (Long Term Evolution), LTE-A (Long Term Evolution Advanced), 4G, and 5G. Other options include DSRC (Dedicated Short Range Communication), BLE (Bluetooth Low Energy), or Bluetooth®. The most suitable communication method should be selected based on the location and distance of each device.

[0022] The following examples illustrate the installation locations and communication methods used for each device, using Figures 1(b) and 1(c). For example, as shown in Figure 1(b), the security decision device 100 and the software execution device 300 may be mounted on a vehicle, which is a "mobile device," while the software management device 200 is located outside the vehicle. For example, the security decision device 100 and the software execution device 300 may be an "electronic control unit" (ECU) mounted on the vehicle, and the software management device 200 may be a server device located outside the vehicle. In this case, the software management device 200 and the security decision device 100 are connected, for example, by Wi-Fi or 5G. The security decision device 100 and the software execution device 300 are connected, for example, by Ethernet or CAN. If the security decision device 100 and the software execution device 300 are implemented in the same device, they are connected by an internal bus or a software process. Here, “moving object” refers to a movable object, regardless of its speed. This also includes cases where the moving object is stationary. Examples include, but are not limited to, automobiles, motorcycles, bicycles, pedestrians, ships, aircraft, and items carried on them. “Carried on” means not only when directly fixed to the moving object, but also when not fixed to the moving object but moves with it. Examples include when an item is carried by a person riding in the moving object, or when an item is carried on cargo placed on the moving object. “Electronic control device” may refer to a physically independent electronic control device, or a virtualized electronic control device implemented using virtualization technology.

[0023] Alternatively, as shown in Figure 1(c), the software execution device 300 may be mounted on the vehicle, and the security measures decision device 100 and software management device 200 may be located outside the vehicle. For example, the software execution device 300 may be an ECU mounted on the vehicle, and the security measures decision device 100 and software management device 200 may be server devices installed outside the vehicle. In this case, the software management device 200 and the security measures decision device 100 are connected, for example, via the Internet. If the software management device 200 and the security measures decision device 100 are implemented in the same device, they are connected via an internal bus or a software process. The security measures decision device 100 and the software execution device 300 are connected, for example, via Wi-Fi or 5G.

[0024] In addition, the security measures determination device 100, the software management device 200, and the software execution device 300 may be installed in the vehicle, or they may be installed outside the vehicle regardless of whether they are in the vehicle or not.

[0025] In the embodiments described later, the arrangement shown in Figure 1(b) will be assumed.

[0026] (2) Diagram 2 of the arrangement of the security measures determination device 100 and the software execution device 300 in the vehicle is a diagram illustrating an example of the arrangement of the electronic control system S mounted on the vehicle, and the security measures determination device 100 and the software execution device 300 in the electronic control system S.

[0027] The electronic control system S consists of multiple ECUs 50 and an in-vehicle network connecting them. Figure 2 shows eight ECUs (ECUs 50a to 50h) as an example, but naturally, the electronic control system S can be composed of any number of ECUs. In the following explanation, when describing the entire electronic control unit, one or more units are referred to as ECU 50 or each ECU 50, and when describing individual electronic control units, they are referred to as ECU 50a, ECU 50b, ECU 50c, etc.

[0028] In the case of Figure 2, each ECU 50 is connected via an in-vehicle communication network such as CAN (Controller Area Network) or LIN (Local Interconnect Network). Alternatively, they may be connected using any communication method, whether wired or wireless, such as Ethernet®, Wi-Fi®, or Bluetooth®. Note that connection refers to a state in which data can be exchanged, and includes not only cases where different hardware is connected via a wired or wireless communication network, but also cases where virtual ECUs (also called virtual machines) implemented on the same hardware are virtually connected to each other.

[0029] The electronic control system S shown in Figure 2 includes an integrated ECU 50a, an external communication ECU 50b, zone ECUs (50c, 50d), and individual ECUs (50e to 50h).

[0030] The integrated ECU 50a is an ECU that has the function of controlling the entire electronic control system S, as well as a gateway function that mediates communication between each ECU 50. The integrated ECU 50a is sometimes called a gateway ECU (G-ECU) or a mobility computer (MC). Alternatively, the integrated ECU 50a may be a relay device or a gateway device.

[0031] The external communication ECU 50b is an ECU having a communication unit that communicates with an external device 60 located outside the vehicle. The communication method used by the external communication ECU 50b is the wireless communication method or wired communication method described in the explanation of Figure 1. In order to realize multiple communication methods, multiple external communication ECUs 50b may be provided. Alternatively, instead of providing an external communication ECU 50b, the integrated ECU 50a may incorporate the functions of the external communication ECU 50b.

[0032] Zone ECUs (50c, 50d) are ECUs equipped with gateway functions that are appropriately positioned according to the location and function of the individual ECUs (50e to 50h). For example, Zone ECU 50c is an ECU that has a gateway function to mediate communication between individual ECUs 50e and 50f located at the front of the vehicle and other ECUs 50, and Zone ECU 50d is an ECU that has a gateway function to mediate communication between individual ECUs 50g and 50h located at the rear of the vehicle and other ECUs 50.

[0033] Individual ECUs (50e to 50h) can be composed of ECUs having any function. Examples include drivetrain electronic control units that control the engine, steering wheel, brakes, etc., vehicle system electronic control units that control meters, power windows, etc., information system electronic control units such as navigation systems, or safety control system electronic control units that perform control to prevent collisions with obstacles or pedestrians. In addition, the ECUs 50 may not be in parallel, but may be classified as master and slave units.

[0034] Each ECU 50 stores software corresponding to its respective function, which is read from memory and executed as needed. Therefore, each ECU 50 can function as a software execution device 300.

[0035] In the following embodiment, we will describe an example where the external device 60 is a software management device 200 and the integrated ECU 50a is a security measure decision device 100, as shown in the arrangement in Figure 1(b). Of course, any other ECU 50 may be used as the security measure decision device 100.

[0036] Furthermore, the first embodiment will describe the case where the integrated ECU 50a is the software execution device 300, and the second embodiment will describe the case where the individual ECU 50f is the software execution device 300. In other words, the first embodiment is an example where the security countermeasure decision device 100 and the software execution device 300 are implemented with the same ECU 50, while the second embodiment is an example where the security countermeasure decision device 100 and the software execution device 300 are implemented with different ECUs 50.

[0037] 2. Embodiment 1 (1) A configuration example of the software management device 200 of this embodiment will be described using the configuration diagram 3 of the software management device 200. The software management device 200 has a storage unit 201, a quality analysis unit 202, a quality information assignment unit 203, and a transmission unit 204.

[0038] The software management device 200 can consist of a general-purpose CPU (Central Processing Unit), volatile memory such as RAM, non-volatile memory such as ROM, flash memory, or hard disk, various interfaces, and an internal bus connecting them. By executing software on this hardware, the device can be configured to perform the functions of each functional block shown in Figure 3. The same applies to the security measure determination device 100 and the software execution device 300 described later.

[0039] The storage unit 201 stores the software to be distributed and information related to the software. It is desirable that the software to be stored meets the review criteria of the distributor operating the software management device 200. The software may consist of program code and data, or it may consist of program code alone. The storage unit 201 may be either an external storage device (hard disk, USB memory, CD / BD, etc.) or an internal storage device (RAM, etc.). It may also be volatile or non-volatile.

[0040] The quality analysis unit 202 reads the software stored in the storage unit 201 and analyzes the "quality" of the software. Based on the quality analysis results, the quality analysis unit 202 generates "quality information." Here, "quality" of the software refers to an indicator that directly or indirectly shows the extent to which anticipated security risks have been anticipated and how well the software has been built to address those anticipated risks. "Quality information" includes not only information that indicates the quality of the software itself, but also information that indicates the attributes or characteristics of the software that affect or may affect the quality of the software.

[0041] As an example, the quality analysis unit 202 analyzes whether the software development process conforms to a predetermined standard, such as ISO / SAE 21434, an international standard that defines cybersecurity measures for automobiles. For example, it analyzes whether there is evidence that the software conforms to ISO / SAE 21434. An example of evidence is a file that shows that all or part of Chapters 10, 11 (product development phase), 12, 13, and 14 (post-product phase) of ISO / SAE 21434 are met. If the software conforms to ISO / SAE 21434, it generates quality information of Lv1; if it does not conform to ISO / SAE 21434, it generates quality information of Lv2. In this embodiment, the quality information is given in two levels, but there may be more levels. In addition, the quality information may also include whether or not the requirements of each chapter and section of ISO / SAE 21434 are met. In this case, the quality information can be in the form of a list that indicates whether or not each requirement is met, or in the form of data in which each bit is assigned to indicate whether or not each requirement is met.

[0042] Other examples of software development processes include UN-R155 / 156, an international regulation on vehicle-related cybersecurity, and ISO 26262, a functional safety standard for applications in automotive electrical and electronic systems.

[0043] Also, as another example, the quality analysis unit 202 analyzes to which classification the software developer belongs. For example, the developer is classified into an OEM which is an automobile manufacturer, a layer of suppliers (Tier N (N is an integer of 1 or more)) that supply parts to the automobile manufacturer, and a third party which is other persons, and analyzes by which person belonging to which classification the target software was created. Specifically, information recorded in the field of the certificate transmitted from the software developer during electronic authentication (TLS: Transport Layer Security) performed at the time of software registration is read to obtain information on the software developer. Examples of the certificate, field, and information include the owner information included in the subject field of the public key certificate of FIG. 4 described later.

[0044] The quality information adding unit 203 "adds" the quality information generated by the quality analysis unit 202 to the software analyzed by the quality analysis unit 202. Here, "add" includes not only the case where the quality information is recorded in a file or the like separate from the software linked to the software, but also the case where the quality information is recorded in the software itself.

[0045] In the present embodiment, quality information is added to the software by recording the quality information in a certificate that proves the integrity of the software. FIG. 4 shows the format of a public key certificate (code signing certificate) for recording quality information. The format of the public key certificate is defined in the X.509 format (RFC5280). In the serialNumber field of the public key certificate, the serial number of the certificate issued by the issuer is recorded. Therefore, for example, if the end of the serial number is 01, it is defined as Lv1, and if the end is 02, it is defined as Lv2t, and the quality information is recorded in the public key certificate of the software by generating the serial number according to this rule. By recording the quality information in the public key certificate in this way, the integrity including the content of the quality information can be ensured. Note that the quality information may be recorded in other fields of the public key certificate.

[0046] Figure 5 shows the format of the extension field of the public key certificate. The extension field is a field for adding additional information. A field for recording quality information may be defined independently in the extension field, and the quality information may be recorded in this field.

[0047] Figure 6 shows the format of the attribute certificate for recording quality information. The format of the attribute certificate is defined in RFC5755. The attributes field of the attribute certificate can be defined independently. Therefore, a field for recording quality information may be defined independently in the attributes field, and the quality information may be recorded in this field.

[0048] The above examples are examples of recording quality information in the certificate, but quality information may be given to the software by writing the quality information directly into the software itself. For example, a label provided in the header of the software or quality information may be written in the data area of the software.

[0049] The certificate in which the quality information is recorded by the quality information providing unit 203 is stored in the storage unit 201 in association with the software.

[0050] The transmission unit 204 transmits the software and the quality information to the security countermeasure decision device 100. In the case of this embodiment, the software and the certificate in which the quality information is recorded are read from the storage unit 201 and transmitted to the security countermeasure decision device 100. The timing of transmission may be when there is a request from the security countermeasure decision device 100, or it may be automatically transmitted based on an instruction from another device.

[0051] (2) Configuration of Security Measures Determination Device 100 The security measures determination device 100 in this embodiment is an example where the software is executed on the same ECU 50. This embodiment is compatible with computers that can process large amounts of data at high speed, such as high-performance computers (HPCs) for general use and in-vehicle integrated ECUs 50a. That is, on these computers with various software installed, the software can be executed after selecting appropriate security measures using quality information received from the software management device 200.

[0052] An example of the configuration of the security measures determination device 100 of this embodiment will be explained using Figure 7. The security measures determination device 100 includes a receiving unit 101, a storage unit 102, a quality information acquisition unit 103, a security measures determination unit 104, and an execution unit 105.

[0053] The receiving unit 101 receives software and "quality information" "assigned" to the software from the software management device 200. In this embodiment, the receiving unit 101 receives the software and a certificate that records the quality information. It is desirable that the receiving unit 101 verify the integrity of the information in the certificate based on the received certificate, in accordance with a general certificate verification process (RFC 5280). Here, "assigned" includes cases where the quality information is recorded in a file other than the software itself that is linked to the software, as well as cases where the quality information is recorded in the software itself. "Quality information" includes cases where it is information that indicates the quality of the software itself, as well as cases where it is information that indicates the attributes or characteristics of the software that affect or may affect the quality of the software.

[0054] The storage unit 102 stores the software and certificates received by the receiving unit 101. The storage unit 101 may be either an external storage device (hard disk, USB memory, CD / BD, etc.) or an internal storage device (RAM, etc.). It may also be volatile or non-volatile.

[0055] The quality information acquisition unit 103 reads the certificate from the storage unit 102 and acquires quality information from the certificate. Specifically, it acquires the quality information by reading it from the fields described in Figures 4, 5, and 6. If the quality information is written to the software, the unit reads the software from the storage unit 102 and acquires the quality information from the software.

[0056] The security measures determination unit 104 determines the security measures required for software execution based on the quality information received by the receiving unit 101 and, in this embodiment, the quality information acquisition unit 103. Specifically, it determines at least one of the following security measures: the scope of access rights, the commands to be filtered, and the targets of the intrusion detection function's monitoring.

[0057] In this embodiment, if the quality information is Lv1, an execution environment prepared for Lv1 is assigned, and access rights are determined so that the software operates in the assigned execution environment. Similarly, if the quality information is Lv2, an execution environment prepared for Lv2 is assigned, and access rights are determined so that the software operates in the assigned execution environment. For example, two virtual machines can be set up using a hypervisor, and each virtual machine can be assigned to a different execution environment. By separating the execution environments for Lv1 and Lv2 software in this way, even if the Lv2 software is subjected to a cyberattack, the operation of the Lv1 software can be prevented from being affected.

[0058] In this embodiment, the security measures determination unit 104 determines the scope of access rights, and more specifically, the allocation of the software execution environment, based on quality information. However, it may also determine which communications are subject to filtering. For example, even if Level 2 software is compromised, in order to prevent it from affecting vehicle control, for Level 1 software, request messages from that software to software or ECUs responsible for controlling [driving], [turning], and [stopping] are not blocked. However, for Level 2 software, request messages from that software are blocked if they flow over the in-vehicle LAN. As an example of a specific means, this can be done by updating the firewall filtering rules to make it subject to filtering. The security measures determination unit 104 may also determine which communications are subject to monitoring by the intrusion detection function. For example, for Level 2 software, it monitors whether it is attempting to access a memory area that is not an accessible memory area permitted for that software, thereby causing an access error. As an example of a specific means, this can be done by updating the monitoring target rules to make it subject to monitoring.

[0059] The security measures determination unit 104 (corresponding to the "output unit") then outputs a countermeasure instruction indicating the determined security measures to the execution unit 105, which will be described later.

[0060] The execution unit 105 (corresponding to the “software execution device”) reads and executes the software stored in the storage unit 102, and also receives the countermeasure instructions output by the security countermeasure determination unit 104 and executes the security countermeasures indicated by the instructions. In this embodiment, the software is executed in an execution environment prepared for the level of quality information indicated by the countermeasure instructions.

[0061] (3) The operation of the software management device 200 and the security measures determination device 100 of this embodiment will be explained using the operation diagram 8 of each device. Note that Figure 8 shows not only the methods executed by the software management device 200 and the security measures determination device 100, but also the processing procedures of programs that can be executed by the software management device 200 and the security measures determination device 100. Furthermore, the processing shown is not limited to the order shown in Figure 8. That is, the order may be changed unless there is a constraint such as a relationship where a step utilizes the result of a preceding step. The same applies to the flowcharts of Embodiment 2 and later.

[0062] The quality analysis unit 202 of the software management device 200 reads the software stored in the storage unit 201 and analyzes the "quality" of the software (S201). Then, the quality analysis unit 202 generates "quality information" based on the quality analysis result in S201 (S202). The quality information assignment unit 203 "assigns" the quality information generated in S202 to the software analyzed in S201. The transmission unit 204 transmits the software and the quality information generated in S202 to the security countermeasure determination device 100.

[0063] The receiving unit 101 of the security measures determination device 100 receives software and "quality information" "assigned" to the software from the software management device 200 (S101). The security measures determination unit 104 determines the security measures required for the execution of the software based on the quality information received in S101 (S102). The security measures determination unit 104 (corresponding to the "output unit") outputs a countermeasure instruction indicating the security measures determined in S102 to the execution unit 105 (S103). The execution unit 105 (corresponding to the "software execution device") reads and executes the software stored in the storage unit 102, and also receives the countermeasure instruction output in S103 and executes the security measures indicated in the countermeasure instruction (S104).

[0064] (4) Summary In summary, according to the software management device 200 of this embodiment, the quality of the software is analyzed and the quality information is transmitted to the security measures determination device 100. This allows the security measures determination device 100 to take appropriate security measures according to the quality of the software, and prevents an overall decrease in security level even in an environment where software of different quality levels are mixed. Furthermore, according to the software management device 200 of this embodiment, the quality information is recorded in the software certificate, so the integrity of the quality information, including its content, can be guaranteed.

[0065] As described above, the security measure determination device 100 of this embodiment determines security measures based on quality information assigned to the software, so appropriate security measures can be implemented according to the quality of the software, and an overall decrease in security level can be prevented even in an environment where software of different quality levels are mixed. Furthermore, the security measure determination device 100 of this embodiment acquires quality information recorded in the software certificate, so quality information with guaranteed integrity can be used. Furthermore, the security measure determination device 100 of this embodiment uses information indicating the software development process as quality information, so security measures can be determined based on the degree of assumptions made regarding anticipated security risks and the level of implementation to address those assumptions, so that security measures are neither excessive nor insufficient. Furthermore, the security measure determination device 100 of this embodiment uses information indicating the developer as quality information, so security measures can be implemented according to the technical level of the developer. Furthermore, the security measure determination device 100 of this embodiment determines the scope of access rights as a security measure, so the scope of access rights can be appropriately set according to the quality of the software. Furthermore, the security measure determination device 100 of this embodiment determines the commands to be filtered as a security measure, so the filtering targets can be appropriately set according to the quality of the software. Furthermore, according to the security measure determination device 100 of this embodiment, the target of the intrusion detection function is determined as a security measure, so the functions and operations of the software to be monitored can be appropriately set according to the quality of the software. In addition, according to the security measure determination device 100 of this embodiment, the software execution device 300, which is implemented with the same hardware as the security measure determination device 100, instructs the security measures to be executed, so the execution of the software and the determination and execution of security measures can be completed within the hardware with sufficient resources.

[0066] 3. Embodiment 2 Embodiment 1 described a case in which the security measures determination device 100 and the software execution device 300 are implemented using the same ECU 50. This embodiment describes a case in which the security measures determination device 100 and the software execution device 300 are implemented using different ECUs 50. Hereinafter, configurations and operations common to Embodiment 1 will be given the same numbers as in Embodiment 1 and the description of Embodiment 1 will be referenced, and the description will focus on configurations and operations that differ from Embodiment 1.

[0067] (1) Configuration of the software management device 200 The software management device 200 of this embodiment has the same configuration and operation as the software management device 200 of Embodiment 1, so the description and drawings used in the specification of Embodiment 1 will be referenced.

[0068] (2) Configuration of Security Measures Decision Device 100 and Software Execution Device 300 The security measures decision device 100 in this embodiment is an example of a case where software is executed on different ECUs 50. This embodiment is suitable for cases where software is executed on a computer with limited resources or when multiple computers are running different software. In other words, the security measures decision device 100 makes the decision on behalf of all computers, and each software execution device 300 executes the security measures instructed by the countermeasures instruction, thereby distributing the load.

[0069] An example configuration of the security measures determination device 100 and the software execution device 300 of this embodiment will be explained using Figure 9. The security measures determination device 100 has a receiving unit 101, a storage unit 102, a quality information acquisition unit 103, a security measures determination unit 104, and an interface (I / F) unit 106. The security execution device 300 has an I / F unit 301 and an execution unit 302.

[0070] The I / F unit 106 (corresponding to the “output unit”) outputs to the software execution device 300 a security measure instruction indicating the security measures determined by the security measure determination unit 104, and the software read from the storage unit 102.

[0071] The I / F unit 301 receives software and countermeasure instructions transmitted from the security countermeasure determination device 100.

[0072] The execution unit 302 executes the software received by the I / F unit 301 and also executes the security measures indicated in the countermeasures instruction.

[0073] (3) The operation of the software management device 200, the security measures determination device 100, and the software execution device 300 of this embodiment will be explained using the operation diagrams 10 of each device. The same processes as in Figure 8 will be given the same step numbers, and the explanation in Figure 8 will be referenced.

[0074] The I / F unit 106 (corresponding to the "output unit") of the security countermeasure determination device 100 outputs a countermeasure instruction indicating the security countermeasure determined in S102, and the software, to the software execution device 300 (S105). The I / F unit 301 of the software execution device 300 receives the countermeasure instruction and software from the security countermeasure determination device 100 (S301). The execution unit 302 executes the software received in S301 and also executes the security countermeasure indicated by the countermeasure instruction received in S301 (S302).

[0075] (4) Summary In summary, the security measures determination device 100 of this embodiment provides the same technical effects as the security measures determination device 100 of Embodiment 1. Furthermore, the security measures determination device 100 of this embodiment instructs the software execution device 300, which is implemented with hardware different from the security measures determination device 100, to execute security measures. Therefore, even if the software execution device 300 does not have sufficient resources, the security measures determination device 100 can determine and instruct security measures, thereby distributing the load across the entire system. In addition, even if multiple software execution devices 300 are provided, the determination of security measures for each software execution device 300 can be executed collectively.

[0076] 4. Embodiment 3 This embodiment is an example of a case where, after the software and security measures in Embodiments 1 and 2 have been implemented, the software attempts to operate abnormally due to a cyberattack or the like. The configuration of this embodiment corresponding to Embodiment 1 will be explained using Figure 11, and the configuration of this embodiment corresponding to Embodiment 2 will be explained using Figure 12.

[0077] Figure 11 shows one example of the security measure determination device 100 of this embodiment. The execution unit 105 outputs an abnormality notification to the security measure determination unit 104 when the software attempts to perform an action that deviates from the defined permissions. Based on the abnormality notification, the security measure determination unit 104 determines further security measures and outputs countermeasure instructions to the execution unit 105. The execution unit 105 executes the further security measures indicated in the countermeasure instructions.

[0078] Figure 12 shows another example of the security measures determination device 100 of this embodiment. The execution unit 302 of the software execution device 300 outputs an abnormality notification to the I / F unit 301 if the software attempts to perform an action that deviates from the defined authority. The I / F unit 301 outputs the abnormality notification to the security measures determination device 100. The I / F unit 106 of the security measures determination device 100 receives the abnormality notification output from the software execution device 300 and outputs it to the security measures determination unit 104. Based on the abnormality notification, the security measures determination unit 104 determines further security measures and outputs a countermeasure instruction to the I / F unit 106, which then outputs the countermeasure instruction to the software execution device 300. The I / F unit 301 of the software execution device 300 receives the countermeasure instruction output from the security measures determination device 100 and outputs it to the execution unit 302. The execution unit 302 executes the further security measures indicated in the countermeasure instruction.

[0079] Actions that deviate from established permissions include, for example, actions that attempt to access files or memory areas for which access is not permitted. Even if such actions are blocked by security measures already in place, it is still considered an "attempt at action." Cyberattacks are one possible cause of such actions, but this embodiment is not limited to cyberattacks.

[0080] If the execution unit 105 of the security measures determination device 100 (which is also the software execution device 300) or the execution unit 302 of the software execution device 300 attempts to perform an action that deviates from the defined privileges, the execution unit 105 or execution unit 302 generates a log indicating that an action deviating from the privileges has been attempted.

[0081] The following are examples of further security measures that the security measure decision unit 104 may decide upon upon receiving an anomaly notification: (1) Example 1: Make the software that attempted to perform an action that exceeds its privileges a target of the security monitoring function. For example, it may be made a target of monitoring by updating the monitoring target rule. (2) Example 2: Isolate the software that attempted to perform an action that exceeds its privileges from the execution environment of other software. For example, if software A and software B are running on the same virtual machine environment, and an anomaly notification is received indicating that software A is abnormal, an additional container environment for running software A and a container environment for running software B may be created on the virtual machine environment, further separating the execution environments of software A and software B. This prevents software B, which shares the virtual machine environment, from being affected even if software A is compromised. (3) Example 3: Temporarily revoke the operating privileges of the software that attempted to perform an action that exceeds its privileges. However, this may be done when an anomaly notification is received a "predetermined number of times" (for example, 3 times). For example, the operating privileges may be temporarily revoked by updating the access control rule. Here, “a predetermined number of times” includes not only the case of a fixed value that is always the same, but also the case of a variable value that changes based on conditions. (4) Example 4 The software operation privileges that attempt to perform an action that exceeds the authority are revoked, and the user using the software is notified of a suggestion to delete the software. However, this may be when an abnormality notification is received “a predetermined number of times” (for example, 5 times). For example, similar to Example 3, the operation privileges are revoked by updating the access control rule, and a message is displayed on the navigation system's display recommending that the software that updates the relevant rule be deleted.

[0082] As described above, the security measure determination device 100 of this embodiment receives an abnormality notification when the software attempts to perform an action that deviates from the defined permissions, and instructs further security measures based on the abnormality notification. Therefore, security measures can be modified or changed while monitoring the execution status of the software, and countermeasures against cyberattacks can be taken in real time.

[0083] 5. Conclusion The features of the apparatus, systems, methods, and programs in each embodiment of this disclosure have been described above.

[0084] The terms used in each embodiment are illustrative and may be replaced with synonymous terms or terms that include synonymous functions.

[0085] The block diagram used in describing the embodiment classifies and organizes the device configuration by function. Each block representing a function can be realized by any combination of hardware or software. Furthermore, since it represents a function, such a block diagram can also be understood as a disclosure of a method invention and a program invention that realizes said method.

[0086] The functional blocks that can be understood as processes, flows, and methods described in each embodiment may be reordered, unless there are constraints such as a relationship where one step utilizes the results of other preceding steps.

[0087] The terms first, second, through N (where N is an integer) used in each embodiment and claim are used to distinguish between two or more configurations or methods of the same kind, and do not imply any order or hierarchy.

[0088] Furthermore, examples of the forms of the devices disclosed herein include the following: Examples of components include semiconductor elements, electronic circuits, modules, and microcomputers. Examples of semi-finished products include electronic control units (ECUs) and system boards. Examples of finished products include mobile phones, smartphones, tablets, personal computers (PCs), workstations, and servers. Other devices with communication functions include, for example, video cameras, still cameras, and car navigation systems.

[0089] Furthermore, each device may be equipped with necessary functions such as an antenna or a communication interface.

[0090] The device described herein is intended to be used, particularly on the server side, for the purpose of providing various services. In connection with the provision of such services, the device described herein will be used, the method described herein will be used, and / or the program described herein will be executed.

[0091] In addition, this disclosure can be implemented not only with dedicated hardware having the configuration and functions described in each embodiment, but also as a combination of a program for implementing this disclosure recorded on a recording medium such as memory or a hard disk, and general-purpose hardware having a dedicated or general-purpose CPU and memory capable of executing this program.

[0092] Programs stored on non-transitional physical recording media of dedicated or general-purpose hardware (e.g., external storage devices (hard disks, USB memory, CDs / BDs, etc.), or internal storage devices (RAM, ROMs, etc.)) can also be provided to the dedicated or general-purpose hardware via the recording media, or via a communication line from a server without using the recording media. This allows for the provision of the latest functionality through program upgrades.

[0093] This disclosure primarily describes a case where an in-vehicle electronic control unit installed in an automobile is used as a security measure decision-making device, but it can be applied to all types of moving objects, including motorcycles, ships, trains, and aircraft. Furthermore, it is not limited to moving objects, but can be applied to all products that include microcomputers.

Claims

1. A security measure determination device (100) comprising: a receiving unit (101) that receives software and quality information assigned to the software from a software management device (200); a security measure determination unit (104) that determines the security measures required when executing the software based on the quality information; and output units (104, 106) that output security measure instructions indicating the security measures to a software execution device (300) that executes the software.

2. The receiving unit has a quality information acquisition unit (103) that receives the software and the certificate of the software, and further acquires the quality information from the certificate, thereby providing a security measure determination device.

3. The security measure determination device according to claim 1, wherein the quality information is information indicating the software development process.

4. The security measure determination device according to claim 3, wherein the development process is information indicating whether or not it conforms to ISO / SAE 21434.

5. The security measure determination device according to claim 1, wherein the quality information is information indicating the developer of the software.

6. The security measures determination device according to claim 1, wherein the security measures determination unit determines the scope of access rights as the security measures based on the quality information.

7. The security measure determination device according to claim 6, wherein the security measure determination unit assigns the software execution environment as the security measure based on the quality information.

8. The security measure determination device according to claim 1, wherein the security measure determination unit determines, based on the quality information, the communications to be filtered as a security measure.

9. The security measure determination device according to claim 1, wherein the security measure determination unit determines the target of monitoring for the intrusion detection function as the security measure based on the quality information.

10. The security measure determination device according to claim 1, wherein the output unit (106) outputs the countermeasure instruction and the software to the software execution device, and the software execution device executes the security measures indicated by the software and the countermeasure instruction.

11. The security measure determination device according to claim 1, wherein, in the software execution device, if the software attempts to perform an action that deviates from the defined privileges, the software execution device generates a log indicating that an action deviating from the privileges has been attempted.

12. The security measure determination device according to claim 1, wherein, upon receiving an abnormality notification from the software execution device indicating that the software has attempted to perform an action that deviates from the defined permissions, the security measure determination unit determines, based on the abnormality notification, that the software should be subject to monitoring by the security monitoring function as a security measure.

13. The security measure determination device according to claim 1, wherein, upon receiving an abnormality notification from the software execution device indicating that the software has attempted to perform an action that deviates from the defined permissions, the security measure determination unit determines, based on the abnormality notification, to isolate the execution environment of the software from the execution environments of other software as a security measure.

14. The security measure determination device according to claim 1, wherein if the software execution device receives an abnormality notification a predetermined number of times indicating that the software has attempted to perform an action that deviates from the defined privileges, the security measure determination unit determines, based on the abnormality notification, to temporarily revoke the operating privileges of the software as a security measure.

15. The security measure determination device according to claim 1, wherein, if the security measure determination unit receives an abnormality notification from the software execution device a predetermined number of times indicating that the software has attempted to perform an action that deviates from the defined privileges, the security measure determination unit decides, based on the abnormality notification, to revoke the operating privileges of the software and to notify the user of the software of a suggestion to delete the software.

16. The security measure determination device according to any one of claims 1 to 15, wherein the security measure determination device is mounted on a mobile body.

17. A software management device (200) comprising: a quality analysis unit (202) that analyzes the quality of software and generates quality information based on the quality; a quality information assignment unit (203) that assigns the quality information to the software; and a transmission unit (204) that transmits the software and the quality information to a security measures determination device (100).

18. The software management device according to claim 17, wherein the quality information assigning unit records the quality information in the software certificate, and the transmission unit transmits the software and the certificate.

19. A trust infrastructure system comprising a software management device (200) and a security measures determination device (100), wherein the software management device includes a quality analysis unit (202) that analyzes the quality of software and generates quality information based on the quality, a quality information assignment unit (203) that assigns the quality information to the software, and a transmission unit (204) that transmits the software and the quality information to the security measures determination device (100), and the security measures determination device includes a receiving unit (101) that receives the software and the quality information assigned to the software from the software management device, a security measures determination unit (104) that determines the security measures required when executing the software based on the quality information, and output units (104, 106) that output countermeasure instructions indicating the security measures to a software execution device (300) that executes the software, the trust infrastructure system (1).

20. A security measures determination method to be executed by a security measures determination device (100), comprising: receiving software and quality information assigned to the software from a software management device (200) (S101); determining the security measures required for the execution of the software based on the quality information (S102); and outputting a security measures instruction indicating the security measures to a software execution device (300) that executes the software (S103, S105).

21. A security measure determination program executable by a security measure determination device (100), which causes the security measure determination device to execute the following processes: receiving software and quality information assigned to the software from a software management device (200) (S101); determining the security measures required for the execution of the software based on the quality information (S102); and outputting a countermeasure instruction indicating the security measures to a software execution device (300) that executes the software (S103, S105).

22. A software management method to be executed by a software management device (200), comprising: analyzing the quality of software (S201); generating quality information based on the quality (S202); assigning the quality information to the software (S203); and transmitting the software and the quality information to a security measures determination device (100) (S204).

23. A software management program executable on a software management device (200), which causes the software management device to perform the following processes: analyze the quality of software (S201), generate quality information based on the quality (S202), assign the quality information to the software (S203), and transmit the software and the quality information to a security measures determination device (100) (S204).

Images