Security measure determination device and security measure determination method

Abstract

To present a security measure that follows rules concerning security and satisfies constraints related to components included in a target system.SOLUTION: A security measure determination device is configured to: hold rule information indicating a requirement that is required, in a rule concerning security, of a component included in a target system, constraint condition information indicating a plurality of constraint conditions regarding specifications of the component, and measure plan information indicating measure plans that satisfy the requirement and constraint conditions required to be satisfied in order to implement the measure plans; select, based on the constraint conditions that are indicated by the measure plan information of the measure plans associated with the requirement, and the plurality of constraint conditions that are indicated by the constraint condition information, a measure plan from the measure plans associated with the requirement; and display the selected measure plan.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a security countermeasure decision device and a security countermeasure decision method. [Background technology]

[0002] With the increase in cyber attacks on critical infrastructure and other operational technology (OT) systems, the formulation of security legislation is underway. In Europe, the European Union (EU) Cyber ​​Resilience Bill was announced in September 2022, requiring security measures to be implemented for all Internet of Things (IoT) devices distributed within the EU, with the exception of digital products related to medical care, aviation, defense, and automobiles.

[0003] The EU Cyber ​​Resilience Act is expected to come into force in fiscal year 2025, and since penalties will be imposed on businesses that violate the EU Cyber ​​Resilience Act, it is urgent for companies that handle IoT devices to take security measures throughout the entire product lifecycle.

[0004] In addition, in Japan, due to the risk of cyber attacks targeting infrastructure companies, the Economic Security Promotion Act was enacted in May 2022. In order to ensure the stable provision of infrastructure services such as electricity, communications, and finance to infrastructure companies in Japan, a system will be introduced in February 2024 under which the government will conduct pre-screening when infrastructure companies introduce critical equipment, etc.

[0005] Given these trends in security laws both in Japan and overseas, infrastructure companies will be required to comply with rules, including security laws and regulations, for their own and / or their customers' OT systems and OT products.

[0006] As a background technique of this technical field, there is JP2017-107405A (Patent Document 1). This publication states that "the security countermeasure planning support device includes an input receiving unit that receives information input from a user, an output unit that displays security countermeasures, a threat-countermeasure DB that associates threats with countermeasures and stores them, a dependent countermeasure DB that stores dependent relationships between security countermeasures, a countermeasure planning unit that extracts multiple security countermeasures associated with threats from the threat-countermeasure DB and extracts dependent relationships between the extracted multiple security countermeasures from the dependent countermeasure DB, an alternative countermeasure DB that stores alternative relationships between security countermeasures, and a countermeasure inspection unit that combines multiple security countermeasures presented by the countermeasure planning unit based on the alternative relationships and constraint conditions of components input from the input unit, and outputs the combined combinations to the output unit" (see abstract).

[0007] Furthermore, as background technology in this technical field, there is JP2019-138542A (Patent Document 2). This publication states that "the threat analysis unit identifies threats that may occur in the target object based on the design information of the target object, and identifies measures to prevent the identified threats as first measures. The standard introduction unit identifies measures to satisfy the standards indicated by the standard information based on the design information and the standard information indicating the security standards applied to the target object. The combination unit combines the first and second measures to generate a secure design diagram" (see abstract). [Prior art documents] [Patent documents]

[0008] [Patent Document 1] JP 2017-107405 A [Patent Document 2] Special Publication No. 2019-138542 Summary of the Invention [Problem to be solved by the invention]

[0009] Ensuring the security of a system requires following the rules mentioned above while also taking into account the unique constraints of the components contained in the system, so implementing security measures is expected to take increased time and cost.

[0010] In the technology described in Patent Document 1, the device constraints (such as narrow network bandwidth or low CPU resources) used in designing security measures for the system are unique, and security measures that take into account multiple constraints on the device are not considered.

[0011] In the technology described in Patent Document 2, the constraints of the device are not taken into consideration when designing security measures for the device, and a countermeasures database is used for the design of security measures. Even if the technology described in Patent Document 2 can extract security measures that satisfy the requirements of the standard, there are problems with implementing security measures in components with many constraints.

[0012] Therefore, one aspect of the present invention proposes security measures that conform to security rules and satisfy constraints on components included in a target system. [Means for solving the problem]

[0013] In order to solve the above problems, one aspect of the present invention employs the following configuration: A security countermeasure decision device has a processor and a memory, the memory holds rule information indicating requirements required of components included in a target system in rules related to security, constraint condition information indicating a plurality of constraint conditions related to specifications of the components, and countermeasure plan information indicating countermeasure plans that satisfy the requirements and the constraint conditions required to realize the countermeasure plans, the processor associates the requirements indicated by the rule information with countermeasure plans indicated by the countermeasure plan information that satisfy the requirements, selects countermeasure plans from the countermeasure plans associated with the requirements based on the constraint conditions indicated by the countermeasure plan information for the countermeasure plans associated with the requirements and the plurality of constraint conditions indicated by the constraint condition information, and generates data for displaying the selected countermeasure plans. Effect of the Invention

[0014] According to one aspect of the present invention, security measures that comply with security rules and satisfy constraints on components included in a target system are presented.

[0015] Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0016] [Figure 1] 1 is a block diagram showing an example of a hardware configuration of a security countermeasure determination device according to a first embodiment. [Diagram 2] 1 is a block diagram showing an example of a functional configuration of a security countermeasure determination device according to a first embodiment. [Diagram 3] FIG. 11 is a diagram illustrating an example of a data configuration of component information according to the first embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of a data configuration of constraint condition information in the first embodiment. [Diagram 5] FIG. 2 is a diagram illustrating an example of a data configuration of a security regulation database according to the first embodiment. [Figure 6]11 is a flowchart showing an example of a design process of a countermeasures proposal database in the first embodiment. [Figure 7] FIG. 4 is a diagram illustrating an example of a data configuration of a countermeasure database according to the first embodiment. [Figure 8] 13 is a flowchart illustrating an example of a process performed by an improvement examining unit in the first embodiment. [Figure 9] FIG. 2 is an explanatory diagram illustrating an example of a screen configuration displayed on the display device in the first embodiment. [Figure 10] FIG. 11 is a block diagram showing an example of a functional configuration of a security countermeasure decision device according to a second embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of a data configuration of a security regulation database according to the second embodiment. [Figure 12] FIG. 11 is a diagram illustrating an example of a data configuration of a countermeasure database in the second embodiment. [Figure 13] 13 is a flowchart illustrating an example of a process performed by an improvement examining unit in the second embodiment. [Figure 14] FIG. 11 is an explanatory diagram showing an example of a screen configuration displayed on a display device in a second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Hereinafter, an embodiment of a security measure decision and device for OT will be described with reference to the drawings. However, the embodiment described below has technically preferable limitations for implementing the present disclosure, but does not limit the scope of the disclosure to the following. Note that in each drawing and each embodiment described in the specification, similar components are given the same reference numerals, and descriptions are omitted as appropriate.

[0018] In this embodiment, the security countermeasures decision device determines and presents security countermeasures and the reasons for selecting the security countermeasures for control devices (OT products), which are components of control systems (OT systems) including critical infrastructures. However, security countermeasures and the reasons for selecting the security countermeasures can also be determined and presented for any system (e.g., IT (Information Technology) system, etc.) other than OT systems, using a procedure similar to that described below. EXAMPLES

[0019] A security countermeasure decision device and a security countermeasure decision method for OT according to a first embodiment will be described with reference to FIG. 1 to FIG.

[0020] Fig. 1 is a block diagram showing an example of a hardware configuration of a security countermeasure decision device 1 for OT. The security countermeasure decision device 1 decides security countermeasures for components (devices) included in a control system (OT system), which is an example of a target system. In particular, the security countermeasure decision device 1 presents security countermeasures for components included in the control system to a user together with the reasons for selecting the security countermeasures. Using the output result from the security countermeasure decision device 1, the user can implement appropriate security countermeasures for the components included in the control system based on the reasons.

[0021] The security countermeasure determination device 1 is composed of, for example, a computer equipped with an arithmetic unit 11, a non-volatile memory 12, a volatile memory 13, an input / output interface 14, and other peripheral circuits. These pieces of hardware work together to operate software and realize multiple functions.

[0022] The arithmetic device 11 includes a processor, and is configured by, for example, a central processing unit (CPU), a micro processing unit (MPU), and / or a digital signal processor (DSP).

[0023] The non-volatile memory 12 includes, for example, a ROM (Read Only Memory) used as a main storage device, and a flash memory and a hard disk drive used as an auxiliary storage device. The volatile memory 13 includes, for example, a RAM (Random Access Memory) used as a main storage device.

[0024] The security countermeasure decision device 1 is a computer system configured on one physical computer, or on multiple logically or physically configured computers, and may operate in separate threads on the same computer, or may operate on a virtual computer constructed on multiple physical computer resources.

[0025] Furthermore, the arithmetic device 11 may be an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or the like.

[0026] For example, the non-volatile memory 12 such as a flash memory and a hard disk drive stores programs executable by the arithmetic device 11 and data used when the programs are executed. That is, the non-volatile memory 12 is a storage medium (storage device) capable of reading programs that realize the functions of the present embodiment. Also, for example, the non-volatile memory 12 such as a ROM stores unchanging programs (e.g., BIOS (Basic Input / Output System)).

[0027] For example, the volatile memory 13 such as a RAM is a storage medium (storage device) that temporarily stores the programs executed by the arithmetic device 11, data used when the programs are executed, and signals input from the input / output interface .

[0028] The arithmetic unit 11 loads a program stored in the non-volatile memory 12 into the volatile memory 13 and executes calculations. The arithmetic unit 11 performs a predetermined calculation process on data taken from the input / output interface 14, the non-volatile memory 12, and the volatile memory 13 in accordance with the program.

[0029] The input / output interface 14 is an interface device to which the input device 4 and the display device 5 are connected, for receiving input from an operator, and for outputting the results of program execution in a format that can be viewed by the operator. A keyboard and a mouse are examples of the input device 4. For example, a device having a display screen such as an LCD monitor, and a printer are examples of the display device 5. The input / output interface 14 may further have a function as a network interface device that controls communication with external devices according to a predetermined protocol.

[0030] Furthermore, the security countermeasure decision device 1 is connected to a security law database 2 and a countermeasure proposal database 3 via an input / output interface 14. The security law database 2 and the countermeasure proposal database 3 are databases in which predetermined data is stored. The data stored in the security law database 2 and the countermeasure proposal database 3 will be described in detail later. The security law database 2 and the countermeasure proposal database 3 may be stored in a non-volatile memory 12 and / or a volatile memory 13.

[0031] In this embodiment, the information used by the security countermeasure decision device 1 does not depend on the data structure and may be expressed in any data structure. For example, the information can be stored in a data structure appropriately selected from a table, a list, a database, or a queue.

[0032] The input / output interface 14 converts the data input signal from the input device 4 and the signals input from the security regulations database 2 and the countermeasures database 3 into data that can be calculated by the calculation device 11. The input / output interface 14 also generates an output signal according to the calculation result in the calculation device 11, and outputs the signal to the display device 5.

[0033] 2 is a block diagram showing an example of a functional configuration of the security countermeasure decision device 1. The security countermeasure decision device 1 includes, for example, a component information input receiving unit 20, a constraint condition management unit 21, an improvement examining unit 22, and an output unit 23, all of which are functions.

[0034] The component information input receiving unit 20 displays a user interface on the display device 5 to allow the designer to input component information 30 via the input device 4, and outputs the component information 30 input by the designer to the constraint condition management unit 21 and the improvement review unit 22. The component information 30 will be described later with reference to FIG.

[0035] The constraint condition management unit 21 generates constraint conditions related to the components (for example, constraint conditions related to the component specifications) from the component information 30 and / or input from the designer via the input device 4, stores the generated constraint condition information 40, and analyzes the generated constraint condition information 40. The constraint condition management unit 21 also outputs a combination of multiple constraint conditions determined by automatic input or direct input to the improvement review unit 22. The constraint condition information 40 will be described later with reference to FIG.

[0036] The improvement review unit 22 receives the component information 30, the constraint condition information 40, the security law database 2, and the countermeasure proposal database 3 as input, and determines the security measures required for the component along with the selection grounds. The security law database 2 will be described later using Fig. 5. The countermeasure proposal database 3 will be described later using Fig. 6. Details of the processing by the improvement review unit 22 will be described later using Fig. 7.

[0037] The output unit 23 notifies the user of the security measures and the reasons for selecting the measures determined by the improvement review unit 22 together with the laws and regulations to the display device 5. The display screen to be output by the output unit 23 to the display device 5 will be described later with reference to FIG.

[0038] For example, the calculation device 11 functions as a component information input receiving unit 20 by operating according to a component information input receiving program loaded in the volatile memory 13, and functions as a constraint condition management unit 21 by operating according to a constraint condition management program loaded in the volatile memory 13. The same relationship between the functional units and the programs applies to the other functional units included in the security countermeasure determination device 1.

[0039] 3 is a diagram showing an example of the data configuration of component information 30. The component information 30 is stored in, for example, the non-volatile memory 12 and / or the volatile memory 13. The component information 30 includes a component column 31 and an element column 32.

[0040] The components indicated in the component column 31 are control devices (eg, OT products) included in a control system (eg, an OT system), such as a PLC (Programmable Logic Controller) and an IoTGW (IoT Gateway).

[0041] The element column 32 indicates information about the elements that make up each component (the elements included in the component, and the specifications, type, and performance of each element, etc.). Specifically, for example, the element column 32 indicates the type of OS and CPU chip mounted on the PLC or IoTGW. For example, the type of OS may be a general-purpose OS or a real-time operating system (RTOS). The component information 30 may also include a hardware interface, a product ID, and a media access control (MAC) address, etc.

[0042] 4 is a diagram showing an example of the data configuration of constraint condition information 40. The constraint condition information 40 is stored in, for example, the non-volatile memory 12 and / or the volatile memory 13. The constraint condition information 40 of a component is determined by automatic extraction from the component information 30 or by direct input by a designer. The constraint condition information 40 includes, for example, a component column 41 indicating the component, and constraint condition columns 42 to 45 each indicating a specific constraint condition.

[0043] In the example of Figure 4, as specific constraint conditions for a component, constraint condition column 42 stores constraint condition A related to the OS (e.g., OS version and type), constraint condition column 43 stores constraint condition B related to the CPU (e.g., CPU chip type and performance), constraint condition column 44 stores constraint condition C related to memory (e.g., memory type and capacity), and constraint condition column 45 stores constraint D related to the control period of the component (an example of the operating status of the system and / or the component).

[0044] For example, when only constraint C in the example of Fig. 4 is considered, component A has the largest memory area, and component B has the smallest memory area. Also, when only constraint D in the example of Fig. 4 is considered, component A has the longest control period, and component C has the shortest control period. Examples of component constraints are not limited to the above, and may include the number of hardware interfaces, supported protocols, and manufacturing costs of components.

[0045] 5 is a diagram showing an example of the data configuration of the security regulation database 2. The security regulation database 2 includes, for example, a regulation name column 50, a category column 51, an ID column 52, and a requirement column 53.

[0046] The law name column 50 holds information indicating the name of a security law. Note that the security law in this embodiment may include any rule related to security for an OT product (an example of a component), such as a domestic law, an international law, a domestic regulation, an international regulation, an industry regulation, a company regulation, a domestic standard specification, an international standard specification, an industry standard, and a company standard, etc. In other words, the security law database 2 can be said to be an example of rule information.

[0047] The category column 51 holds information indicating a macro category in the security regulations. The ID column 52 holds an ID for identifying a requirement in the category. The requirement column 53 holds information indicating a requirement in the category.

[0048] The EU Cyber ​​Resilience Act and international standards for control system security such as IEC (International Electrotechnical Commission) 62443 are both examples of security legislation. IEC 62443-4-2 classifies security requirements for components into seven categories.

[0049] The category [System Integrity] shown in the example of Figure 5 is one of the seven categories, and is a category related to the integrity of the system. In [System Integrity], [ID:1] requires [Communication integrity], that is, that components have the function of verifying the integrity of information.

[0050] [Countermeasures database design processing] Fig. 6 is a flow chart showing an example of design processing of the countermeasures proposal database 3. In the processing of Fig. 6, the countermeasures proposal database 3 may be generated by the security countermeasures decision device 1, or may be generated by an external system.

[0051] In step S60, a security regulation database 2 is generated from information on security regulations input to the input device 4 or information on security regulations received from an external system.

[0052] In step S61, threats against each requirement in the security regulations database 2 are extracted, for example, using a known predetermined threat model for the component, or by direct input by a user.

[0053] For example, in the security regulations database 2 in Fig. 5, the Lucky Thirteen Attack is extracted as a threat to the requirement [System Integrity] [ID:1] [Communication integrity] in the category column 51. The Lucky Thirteen Attack is an attack that targets the process of decrypting a cipher block in a block cipher, and aims to extract information about data and keys by exploiting vulnerabilities in the block cipher.

[0054] In step S63, a security document held by an OT vendor (control device vendor) is acquired, and countermeasures against the threats are extracted from the security document. In the security document, for example, threats and countermeasures are described in advance in correspondence with each other. The countermeasures described in the security document include, for example, specific countermeasures against threats, countermeasure categories of the specific countermeasures, implementation forms for realizing the specific countermeasures, and constraints required for the implementation forms. In step S64, the countermeasures extracted in step S63 are compiled, and a countermeasure proposal database 3 is designed.

[0055] The information indicating the threats extracted in step S61 may be associated with each requirement and further stored in the security regulations database 2. Also, the information indicating the threats corresponding to the measures extracted in step S63 may be associated with each specific measure and further stored in the countermeasures proposal database 3.

[0056] 7 is a diagram showing an example of the data configuration of the countermeasures proposal database 3. The countermeasures proposal database 3 includes, for example, a countermeasures category column 61, an ID column 62, a specific countermeasure column 63, an implementation form column 64, and a constraint condition column 65.

[0057] The countermeasure category column 61 holds information indicating a category to which a specific measure for improving security belongs. The ID column 62 holds an ID for identifying the specific measure. The specific measure column 63 holds information indicating the specific measure. The implementation form column 64 holds information indicating an implementation form for realizing the specific measure.

[0058] The constraints field 65 holds information indicating constraints required for the implementation form (constraints required for the component to realize the specific measure). Note that the constraints corresponding to the specific measure with [Measures category: Protocol] and [ID: 1] in Fig. 7 do not include any constraints regarding the control period. However, the absence of such a description indicates that the implementation form can be realized with any control period.

[0059] In the example of Fig. 7, a protocol is defined in the countermeasure category column 61 of the component. One security measure when the component communicates data is encryption of the communication data. For example, the communication data is encrypted using the Transport Layer Security (TLS) protocol. "Use of encryption suites" defined in the specific countermeasure column 63 in the example of Fig. 7 indicates the use of a combination of multiple encryption algorithms as a protocol for TLS encrypted communication.

[0060] In the example of Fig. 7, the implementation form column 64 defines multiple types of encryption suites for the specific measure [ID:1]. In general, an encryption suite is expressed as TLS_[authentication (Au)]_WITH_[symmetric key encryption (Enc)]_[hash (Hash / Mac)]. For example, TLS_RSA_WITH_AES_128_CBC_SHA in the implementation form column 64 of Fig. 7 is an example of notation when authentication (digital signature) is RSA encryption, the symmetric key encryption is AES128 CBC mode, and the hash value is SHA1. As shown in the implementation form column 64 of Fig. 7, there are multiple types of encryption suites depending on the purpose, and different encryption algorithms are used.

[0061] In the example of Fig. 7, constraints related to the OS, CPU, and memory are stored in the constraints column 65. In the example of Fig. 7, it is shown that TLS_RSA_WITH_AES_128_CBC_SHA in the implementation form column 64 can be implemented with an OS of AX-X, BY-Y, or CZ-Z, a CPU with CZ or higher specifications, and a memory with bx or higher specifications.

[0062] [Internal processing of Improvement Review Department 22] 8 is a flowchart showing an example of processing by the improvement review unit 22. The improvement review unit 22 presents countermeasures and reasons for selecting the countermeasures based on the component information 30, the component constraint condition information 40, the security regulations database 2, and the countermeasures database 3. The processing by the improvement review unit 22 will be described below.

[0063] In step S100, the improvement review unit 22 selects a component for which security measures are to be reviewed from the component information 30, for example, in accordance with an input from a user via the input device 4. Hereinafter, it is assumed that component C is selected as a target component in step S100. Here, in the constraint information 40 of Fig. 4, the constraints of component C are constraint A: OS = CZ-Z, constraint B: CPU = CZ (C = 32 [bit], c = 1.0 [GHz]), constraint C: cx = 512 [MB], constraint D: Cz = 40 [ms].

[0064] In step S101, the improvement review unit 22 maps (specific measures in) the countermeasures database 3 to (each requirement in) the security regulations database 2. For example, when IEC 62443 is selected as the security regulation in the security regulations database 2, [System Integrity][ID:1][Communication integrity] in the category column 51 is associated with the specific measure [Protocol][ID:1][Use the strongest encryption option and cipher suite for TLS] in the countermeasures database 3.

[0065] The mapping in step S101 is determined, for example, according to the threats against each requirement in the security regulations database 2 extracted in step S61 and the threats corresponding to the countermeasures extracted in step S63. In step S61, it is assumed that the Lucky Thirteen Attack is extracted as a threat against the requirement [System Integrity] [ID:1] [Communication integrity] in the category column 51. In addition, it is assumed that in step S63, a countermeasure (specific countermeasure) against the threat is extracted from the security document, and the countermeasure is [Protocol] [ID:1] [Use the strongest encryption option and cipher suite for TLS] in the countermeasure proposal database 3. As a result, the above-mentioned correspondence is performed in the mapping.

[0066] In this way, in step S101, the improvement review unit 22 can derive general-purpose security measures for the requirements required by regulations by mapping the countermeasure proposal database 3 (specific measures) to the security regulations database 2 (each requirement).

[0067] In step S102, the improvement review unit 22 determines whether it is possible to select a combination of constraint conditions (a combination of constraint conditions is composed of one or more constraint conditions) indicated by the constraint condition information 40 of the target component C. Specifically, for example, the improvement review unit 22 acquires the combination of constraint conditions of the component C indicated by the constraint condition information 40 in accordance with an input to the input device 4.

[0068] For example, if the improvement review unit 22 has not determined in step S103 that there is no implementation form that satisfies any combination consisting of a portion of the constraint conditions included in the acquired combination, it determines that the acquired combination is selectable, and if it has determined in step S103 that there is no implementation form that satisfies at least one of the combinations consisting of the portion, it determines that the acquired combination is not selectable.

[0069] Specifically, for example, if a combination of constraint condition A, constraint condition B, and constraint condition C (constraint condition A ∧ constraint condition B ∧ constraint condition C) is selected in step S102, and if any of the combinations of constraint condition A ∧ constraint condition B, constraint condition A ∧ constraint condition C, constraint condition B ∧ constraint condition C, constraint condition A, constraint condition B, and constraint condition C are not subject to judgment in step S103 or are judged to have an implementation form in step S103, then constraint condition A ∧ constraint condition B ∧ constraint condition C is a selectable combination, and if it is judged in step S103 that at least one of these combinations does not have an implementation form, then constraint condition A ∧ constraint condition B ∧ constraint condition C is a non-selectable combination.

[0070] In step S103, the improvement review unit 22 determines whether there is an implementation form that satisfies the combination of constraint conditions selected in step S102 among the implementation forms included in the specific measures associated in the mapping in step S101. There are multiple methods for combining constraint conditions indicated by the constraint condition information 40, but below, an example will be described in which a combination of constraint condition A (OS type), constraint condition B (CPU type), and constraint condition C (memory) is selected in step S102.

[0071] First, for the constraint A: OS=CZ-Z, the improvement review unit 22 lists encryption suites executable on the OS (CZ-Z) of the component C indicated by the constraint information 40. Specifically, the implementation forms of the security measures corresponding to [System Integrity][ID:1][Communication integrity] from the mapping result of step S101 include four encryption suites, namely, "TLS_RSA_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_AES_256_CBC_SHA256", "TLS_RSA_WITH_AES_128_GCM_SHA256", and "TLS_RSA_WITH_AES_128_GCM_SHA512". The improvement review unit 22 determines from the constraint column 65 of the countermeasure proposal database 3 that any of the implementation forms is theoretically executable on the OS (CZ-Z) of the component C.

[0072] Furthermore, when the improvement examining unit 22 adds constraint B (CPU type) in addition to constraint A (OS type), that is, constraint A (OS=CZ-Z) ∧ constraint B (CPU=CZ(C=32[bit],c=1.0[GHz])), the selectable encryption suites are narrowed down from the above four candidates to two. This is because the CPU of component C selected in step S100 is 32-bit due to constraint B, and therefore the encryption suites executable in 32-bit are narrowed down to "TLS_RSA_WITH_AES_256_CBC_SHA256" and "TLS_RSA_WITH_AES_128_GCM_SHA256".

[0073] Furthermore, when constraint C (memory) is added, i.e., constraint A (OS=CZ-Z) ∧ constraint B (CPU=CZ (C=32[bit], c=1.0[GHz])) ∧ constraint C (cx=512), the improvement study unit 22 extracts both of the two narrowed down encryption suites as candidates for implementation forms, since it is possible to execute the algorithm while satisfying constraint C even if the key length of the AES (Advanced Encryption Standard) is 128 bits or 256 bits.

[0074] Therefore, since there is a combination (TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256) that satisfies the combination of constraints in step S102 (constraint A ∧ constraint B ∧ constraint C), the output unit 23 presents the implementation form of the security countermeasures (utilization of TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256) and the reason for selecting the countermeasures (because constraint A ∧ constraint B ∧ constraint C is satisfied) on the display device 5 in step S104, and terminates the processing.

[0075] Here, if there is no combination of constraint conditions in step S102, i.e., if a combination of constraint conditions cannot be selected in step S102, the output unit 23 displays on the display device 5 in step S105 a message indicating that there are no relevant security countermeasure proposals and reasons for selection.

[0076] In the above example, in step S102, the improvement review unit 22 selects a combination of constraint conditions according to the input to the input device 4, but, for example, a combination including all of the constraint conditions indicated by the constraint condition information 40 of the component selected in step S100 may be automatically selected. In this case, if the improvement review unit 22 determines that there is an implementation form that satisfies the combination, it may transition to step S104, and if it determines that there is no implementation form that satisfies the combination, it may transition to step S105.

[0077] Also, for example, the improvement review unit 22 may execute the process of step S103 for each of all combinations of constraint conditions. In this case, when the improvement review unit 22 determines that there is an implementation form that satisfies any of the combinations, it may execute the process of step S104 for each of the combinations, and when it determines that there is no implementation form for all of the combinations, it may transition to step S105.

[0078] 9 is an explanatory diagram showing an example of a screen configuration displayed on the display device 5 in step S104. The output unit 23 outputs the security measures and the reasons for selecting the measures by the improvement review unit 22 to the display device 5 together with the compliant laws and regulations, and notifies the contents to the user. The method of informing the user is not limited to this, and the security measures and the reasons for selecting the measures by the improvement review unit 22 may be notified by utilizing a generation AI.

[0079] The display screen of the display device 5 includes, for example, a law selection area 81, a law change button 82, a security countermeasures display area 88 for OT products, a component selection area 89, and a component change button 90.

[0080] The regulation selection area 81 is an area for selecting the regulation that needs to be addressed for the component, such as the EU Cyber ​​Resilience Act and IEC 62443. When a regulation is selected in the regulation selection area 81 and then the regulation change button 82 is selected, the display in the security measures display area 88 for OT products is changed to a display related to the regulation.

[0081] The security measures display area 88 for OT products includes, for example, a regulations column 83, an ID column 84, a requirements column 85, a security measures column 86, and a selection rationale column 87. The regulations column 83 indicates the name of the regulations that require action. The ID column 84 holds an ID that identifies the requirements for the regulations (the specific measures mapped in step S101). The requirements column 85 holds information indicating the requirements for the regulations.

[0082] The security measures column 86 shows security measures for requirements (implementation forms included in the specific measures mapped in step S101). Note that at least one security measure for legal requirements is displayed in the security measures column 86, and if there are multiple measures, the results of selecting implementable measures from among them are displayed.

[0083] In the example of Fig. 9, the implementation form with a black circle next to the name of the security measure shown in the security measure column 86 is the implementation form for which it is determined in step S103 that the constraint conditions are satisfied. As in the example of Fig. 9, not only the implementation form for which it is determined in step S103 that the constraint conditions are satisfied, but also the implementation form for which it is determined that the constraint conditions are not satisfied may or may not be displayed in the security measure column 86. The selection basis column 87 indicates the basis for indicating that the security measure shown in the security measure column 86 is selectable. The selection basis column 87 displays, as the basis, for example, information indicating that the constraint conditions required for the security measure are satisfied.

[0084] The security countermeasure decision device 1 of this embodiment can specify countermeasures as requirements for security regulations by mapping the countermeasure database 3 to the security regulation database 2. Furthermore, the security countermeasure decision device 1 can specify countermeasures that satisfy the constraint conditions of the components from the mapped countermeasures, and can quickly select countermeasures that can be implemented under the constraint conditions from the countermeasures as requirements for security regulations, thereby reducing the user's man-hours required for compliance with security regulations. Furthermore, the security countermeasure decision device 1 can also present the selection reasons for the constraint conditions when selecting a countermeasure.

[0085] In particular, in components specialized for embedding such as OT products, the constraints on the resources of the elements of the components are strict (for example, the specifications of each element are low compared to devices included in IT systems), so the security countermeasure decision device 1 of this embodiment can narrow down the number of candidates for security countermeasures that can be implemented in OT products to a small number by analyzing combinations of constraints specific to OT products, and can also present the reasons for selection. As a result, the security countermeasure decision device 1 can present highly appropriate security countermeasures with sufficient reasons, even in the security design and security operation of OT products. EXAMPLES

[0086] 10 to 14, a description will be given of a security measure decision and device for OT according to the second embodiment. Note that the same reference symbols are used for configurations that are the same as or equivalent to those described in the first embodiment, and differences will be mainly described.

[0087] Fig. 10 is a block diagram showing an example of a functional configuration of the security countermeasure decision device 1. The security countermeasure decision device 1 of this embodiment differs from the security countermeasure decision device 1 according to the first embodiment in that it further accepts the setting of a target security level 24. Hereinafter, the security level may be abbreviated as SL.

[0088] Target security level 24 is expressed differently depending on security regulations, but it is one example of an indicator for the security design and implementation of control systems. By setting target security level 24 and implementing security measures that satisfy target security level 24, it is expected that the security performance of systems and components will be improved.

[0089] Generally, security levels are divided into several levels, and in this example, the scope of application is SL0 to SL4 as described in IEC 62443. Each SL indicates the following: SL0: a state in which no security measures are implemented, SL1: a state in which there is resistance to sudden accidents and errors, SL2: a state in which there is resistance to deliberate attacks based on low resources and knowledge, SL3: a state in which there is resistance to attacks based on a certain level of resources and knowledge (resources and knowledge higher than SL2), and SL4: a state in which there is resistance to attacks with very high resources (resources higher than SL3) and motivation.

[0090] 11 is a diagram showing an example of the data configuration of the security regulation database 2. The security regulation database 2 of this embodiment differs from the security regulation database 2 according to the first embodiment in that it further includes a security level column 101.

[0091] In addition, the security regulations database 2 of this embodiment differs from the security regulations database 2 of Example 1 in that the requirements indicated in the requirements column 53 and the IDs indicated in the ID column 52 corresponding to the requirements are subdivided according to the security levels indicated in the security level column 101.

[0092] The security level column 101 stores a check mark indicating whether the corresponding requirement should be satisfied at each SL. In each record of the security regulations database 2, when a check mark is stored at a certain SL in the security level column 101, check marks are also stored at all SLs higher than that SL of that record. In other words, a requirement that should be satisfied at a certain SL should also be satisfied at SLs higher than that SL (a requirement that should be satisfied at SL1 should also be satisfied at SL2 or higher, a requirement that should be satisfied at SL2 should also be satisfied at SL3 or higher, and a requirement that should be satisfied at SL3 should also be satisfied at SL4).

[0093] Many security regulations have requirements that must be implemented at all security levels, such as the requirements for [ID:1] in the example of Figure 11, but also requirements that differ depending on the user's target security level 24, such as [ID:1-1].

[0094] In the example of Figure 11, [System Integrity] [ID: 1] [Communication integrity] in category column 51 must be achieved at all security levels, and in addition, [System Integrity] [ID: 1-1] [Cryptographic integrity protection] is a requirement for SL≧3.

[0095] The implementation forms also differ between SL≦2 and SL≧3. For SL≦2, attackers are assumed to have no specialized knowledge of OT systems or products, so implementation forms that implement measures against intentional tampering with information are not applicable. On the other hand, for SL≧3, attacks by terrorists with sufficient knowledge of cyber attacks or nation-state activities are also assumed, so a more secure implementation form is required. In this example, it is assumed that error control (parity check and CRC) will be used for SL≦2, and encryption techniques such as hash functions will be used for SL≧3.

[0096] 12 is a diagram showing an example of the data configuration of the countermeasures database 3. In the countermeasures database 3 of this embodiment, in the constraints column 65, constraints related to the security level in implementation are further defined as constraints required for the implementation form.

[0097] 12, the constraints column 65 indicates constraints (OS, CPU, memory, security level) for realizing the implementation form in the implementation form column 64. For example, TLS_RSA_WITH_AES_128_CBC_SHA in the implementation form column 64 indicates that it can be executed when the OS is any of AX-X, BY-Y, or CZ-Z, the CPU is CZ or higher spec, the memory is bx or higher spec, and the security level (SL) is SL=1.

[0098] [Internal processing of Improvement Review Department 22] 13 is a flowchart showing an example of processing by the improvement review unit 22. The improvement review unit 22 presents countermeasures and reasons for selecting the countermeasures, based on the component information 30, the component constraint condition information 40, the security regulations database 2, the countermeasures database 3, and the target security level 24. These processes will be described below.

[0099] In step S200, the improvement review unit 22 selects a component for which security measures are to be reviewed from the component information 30 in the same manner as in step S100. Hereinafter, it is assumed that the component C is selected in step S200. The details of the constraint condition AD are the same as those in the first embodiment.

[0100] In step S201, the improvement review unit 22 determines the target security level 24 according to an input from the user to the input device 4. In step S202, the improvement review unit 22 determines whether it is possible to extract from the security regulation database 2 a security requirement (a record that satisfies the security level) that satisfies the target security level 24 determined in step S201.

[0101] For example, when the user's target security level 24 is SL=3, the improvement review unit 22 extracts, as security requirements, [System Integrity][ID:1][Communication integrity] and [System Integrity][ID:1-1][Cryptographic integrity protection] from the security regulations database 2 in Fig. 11. Also, in step S202, if the improvement review unit 22 determines that a security requirement satisfying the target security level 24 cannot be extracted, the process returns to step S201 since the security level needs to be reviewed and re-determined.

[0102] In step S203, the improvement examining section 22 maps the countermeasures database 3 to the security requirements that satisfy the target security level 24 extracted in step S202. The mapping method in step S203 is the same as that in step S101.

[0103] In step S204, the improvement investigating unit 22 determines whether it is possible to select a combination of constraint conditions indicated by the constraint condition information 40 of the target component C. The process in step S204 is similar to that in step S102.

[0104] In step S205, the improvement examining section 22 determines whether or not there is an implementation form that satisfies the combination of constraint conditions selected in step S204, among the implementation forms included in the specific measures associated in the mapping in step S203.

[0105] Below, consider an example of a combination of constraint conditions for component C. As in the first embodiment, there are multiple ways to combine constraint conditions for component C, but in this example, it is assumed that a combination of constraint condition A (OS type), constraint condition B (CPU type), and constraint condition C (memory) is selected.

[0106] First, from the mapping result of step S203, for the security measure [Protocol][ID:1][Use the strongest encryption option and cipher suite for TLS] corresponding to [System Integrity][ID:1][Communication integrity] and [System Integrity][ID:1-1][Cryptographic integrity protection], there are multiple candidate implementation forms of encryption suites, such as TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, and TLS_RSA_WITH_AES_128_GCM_SHA512.

[0107] As in the first embodiment, when considering the combinations of constraints A, B, and C in order, there are two implementable encryption suites: TLS_RSA_WITH_AES_256_CBC_SHA256 and TLS_RSA_WITH_AES_128_GCM_SHA256.

[0108] Therefore, in step S205, the improvement review unit 22 determines that there are two types of implementation forms that satisfy the combination of constraint conditions (constraint condition A ∧ constraint condition B ∧ constraint condition C). If the combination of constraint conditions does not exist, that is, if the improvement review unit 22 determines in step S204 that the combination of constraint conditions is not selectable, the output unit 23 executes the process of step S209. The process of step S209 is the same as the process of step S105.

[0109] In step S206, the improvement examining unit 22 selects between the above two types of implementation. In this example, the target security level 24 is SL=3, so it must be assumed that information may be tampered with by terrorists or cybercrime groups. The TLS CBC (Cipher Block Chaining) mode is known to be susceptible to the Lucky Thirteen Attack, a type of Padding Oracle attack that targets weak points in the padding process.

[0110] Therefore, in step S206, the improvement review unit 22 needs to select the more secure implementation form from among TLS_RSA_WITH_AES_256_CBC_SHA256 and TLS_RSA_WITH_AES_128_GCM_SHA256.

[0111] In this embodiment, the security level is described in the constraint condition column 65 indicating the constraint conditions required for the implementation form of the countermeasure proposal database 3 shown in Fig. 12. According to the example of Fig. 12, TLS_RSA_WITH_AES_256_CBC_SHA256 can be implemented with SL=2, while TLS_RSA_WITH_AES_128_GCM_SHA256 can be implemented with SL≧3. Therefore, in step S206, the encryption suite TLS_RSA_WITH_AES_128_GCM_SHA256 with the GCM (Galois / Counter Mode) mode, which has a higher implementation security level, is selected.

[0112] In step S206, the improvement review unit 22 may display each of the implementation forms identified in step S205 on the display device 5 (and may further display the security level indicated in the constraint condition column 65 of the implementation form), and select the implementation forms according to the user's input to the input device 4. In step S206, the improvement review unit 22 may select an implementation form having a high implementation security level based on a predetermined condition (for example, a predetermined number of implementation forms in descending order of security level, or an implementation form having a security level equal to or higher than a predetermined value) from the implementation forms identified in step S205, or may exclude an implementation form having a low implementation security level based on a predetermined condition (for example, a predetermined number of implementation forms in descending order of security level, or an implementation form having a security level equal to or lower than a predetermined value).

[0113] Also, the process of step S206 may be omitted, that is, the determination of step S207 described below may be performed for all implementation forms identified in step S205.

[0114] In step S207, the improvement review unit 22 again verifies whether the target security level 24 can be reached with the implementation form selected in step S206. The improvement review unit 22 verifies the validity of the security measures by comparing the security level in the implementation with the target security level 24.

[0115] In this example, the target security level 24 is SL=3, whereas the security level in the implementation is SL≧3 (that is, the security level in the implementation is equal to or greater than the target security level 24), so the condition in step S207 is met. Here, if the improvement review unit 22 determines that the implementation form selected in step S206 cannot reach the target security level, the process again begins in step S202 to review the security requirements at the target security level 24. At that time, if it is not possible to extract security requirements that match the target security level 24 from the security regulations database 2 in step S202, the target security level 24 will be reviewed and re-determined in step S201. At this time, the target security level 24 may be lowered depending on the circumstances.

[0116] In step S208, the output unit 23 displays the security countermeasure (TLS_RSA_WITH_AES_128_GCM_SHA256), the reason for selecting the countermeasure (because constraint A ∧ constraint B ∧ constraint C is satisfied), and the security level (SL=3) on the display device 5, and ends the process.

[0117] As in the first embodiment, the improvement review unit 22 may automatically select in step S204 a combination that includes all of the constraint conditions indicated by the constraint condition information 40 of the component selected in step S200, or may execute the processing of steps S205 to S207 for each of all combinations of constraint conditions.

[0118] 14 is an explanatory diagram showing an example of a screen configuration displayed on the display device 5 in step S208. The display screen of the display device 5 differs from that of the first embodiment in that it is further provided with a security level display area 121. The security level display area 121 shows the user's target security level 24, that is, the security level that can be achieved when appropriate security measures presented by the improvement review unit 22 are taken, as an example of a basis for selection.

[0119] In the selection basis column 87 in the security measure display area 88 for OT products in this embodiment, in addition to the combination of constraint conditions being the basis for selection as in the first embodiment, whether or not the user's target security level 24 is satisfied is further displayed as the basis. Therefore, while two recommended security measures were presented in the first embodiment, in this embodiment, the recommended security measures are narrowed down to one as a result of considering those that satisfy the user's target security level 24 (SL=3).

[0120] According to the security countermeasure decision device 1 for OT of this embodiment, legal requirements corresponding to the user's target security level 24 can be extracted, and appropriate security countermeasures corresponding to the requirements can be output with a solid basis by analyzing the combination of constraint conditions, in accordance with the user's intended security level.

[0121] The present invention is not limited to the above-mentioned embodiment, and various modifications are included. For example, the above-mentioned embodiment has been described in detail to clearly explain the present invention, and is not necessarily limited to those having all the configurations described. It is also possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.

[0122] In addition, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. In addition, the above-mentioned configurations, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information such as the program, table, file, etc. that realizes each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

[0123] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are connected to each other. [Explanation of symbols]

[0124] 1 security countermeasure decision device, 2 security law database, 3 countermeasure proposal database, 4 input device, 5 display device, 11 computing device, 12 non-volatile memory, 13 volatile memory, 20 component information input reception unit, 21 constraint condition management unit, 22 improvement examination unit, 23 output unit, 24 target security level, 30 component information, 40 constraint condition information

Claims

1. A security countermeasure determination device, A processor and a memory, The memory includes: rule information indicating requirements imposed on components included in a target system in a security rule; Constraint information indicating a plurality of constraints regarding the specifications of the component; retaining countermeasure information indicating countermeasures that satisfy the requirements and constraints required to realize the countermeasures; The processor, Correlating the requirements indicated by the rule information with the countermeasures indicated by the countermeasure information to satisfy the requirements; selecting a countermeasure plan from the countermeasure plans associated with the requirement based on a constraint condition indicated by the countermeasure plan information of the countermeasure plan associated with the requirement and the plurality of constraint conditions indicated by the constraint condition information; A security countermeasure decision device that generates data for displaying the selected countermeasure plan.

2. 2. The security countermeasure determination device according to claim 1, The processor, a security countermeasure decision device that generates data for displaying a selection reason indicating that the plurality of constraint conditions indicated by the constraint condition information satisfy the constraint condition corresponding to the selected countermeasure plan in the countermeasure plan information.

3. 2. The security countermeasure determination device according to claim 1, The component includes an OS, a CPU, and a memory, A security countermeasure decision device, wherein the multiple constraint conditions indicated by the constraint condition information and the constraint conditions indicated by the countermeasure proposal information each include at least one of a condition regarding the OS type of the component, a condition regarding the CPU performance of the component, a condition regarding the memory capacity of the component, and a condition regarding the operating status of the component.

4. 2. The security countermeasure determination device according to claim 1, the rule information indicates a threat to the requirement; The countermeasure information indicates a correspondence between the threat and the countermeasure, The processor corresponds, based on the threats indicated by the rule information and the threats indicated by the countermeasure proposal information, requirements indicated by the rule information with countermeasure proposals that satisfy the requirements indicated by the countermeasure proposal information.

5. 2. The security countermeasure determination device according to claim 1, The processor, A security countermeasure decision device that selects from the countermeasure plans associated with the requirements a countermeasure plan whose combination of at least one of the multiple constraint conditions indicated by the constraint condition information satisfies the constraint condition indicated by the countermeasure plan information of the countermeasure plan associated with the requirement.

6. 2. The security countermeasure determination device according to claim 1, the memory holds information indicative of a target security level; the rule information holds information indicating whether the requirements should be satisfied at each security level; the constraint condition indicated by the countermeasure plan information includes a first condition required of the component to realize the countermeasure plan and a second condition related to a security level of the countermeasure plan; The processor, Identifying requirements to be satisfied at the target security level from the rule information; Correlating the identified requirements with countermeasures that satisfy the requirements, as indicated by the countermeasure information; A security countermeasure decision device that selects a countermeasure plan from the countermeasure plans associated with the identified requirements based on the first condition and the second condition in the countermeasure plan information that correspond to the countermeasure plan associated with the identified requirements, the multiple constraint conditions indicated by the constraint condition information, and the target security level.

7. 7. A security countermeasure determination device according to claim 6, The processor, A security countermeasure decision device that generates data for displaying a selection reason indicating that the multiple constraint conditions indicated by the constraint condition information satisfy the first condition corresponding to the selected countermeasure plan in the countermeasure plan information, and that the second condition corresponding to the selected countermeasure plan in the countermeasure plan information satisfies the target security level.

8. 7. A security countermeasure determination device according to claim 6, The processor, A security countermeasure decision device that selects from the countermeasure plans associated with the specified requirements a countermeasure plan in which a combination of at least one of the multiple constraint conditions indicated by the constraint condition information satisfies the first condition indicated by the countermeasure plan information of the countermeasure plans associated with the specified requirements.

9. A security countermeasure decision method by a security countermeasure decision device, comprising: The security countermeasure determination device includes a processor and a memory, The memory includes: rule information indicating requirements imposed on components included in a target system in a security rule; Constraint information indicating a plurality of constraints regarding the specifications of the component; retaining countermeasure information indicating countermeasures that satisfy the requirements and constraints required to realize the countermeasures; The security countermeasure determination method includes: The processor associates requirements indicated by the rule information with countermeasure proposals that satisfy the requirements indicated by the countermeasure proposal information; The processor selects a countermeasure plan from the countermeasure plans associated with the requirement based on a constraint condition indicated by the countermeasure plan information of the countermeasure plan associated with the requirement and the plurality of constraint conditions indicated by the constraint condition information; The security countermeasure decision method, wherein the processor generates data for displaying the selected countermeasure proposal.

Images