Security measure determination apparatus and security measure determination method

Abstract

To present security measures that conform to security rules and are applicable to a target system.SOLUTION: A security measure determination apparatus is configured to: extract combinations to satisfy security requirements of a system, each combination including a subsystem specific measure and a component specific measure; and determine subsystem specific measures for a subsystem and component specific measures for components included in the subsystem from the extracted combinations, based on results of comparison of constraints on operating states assigned to subsystems included in the system and constraints to be satisfied by the subsystem to implement the subsystem specific measure and results of comparison of constraints on specifications assigned to components included in the system and constraints to be satisfied to implement the component specific measure.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 cyberattacks 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 circulating within the EU, with the exception of digital products related to medical care, aviation, national defense, and automobiles.

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

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

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

[0006] Background art in this technical field is WO 2019 / 138542 (Patent Document 1), which states that "the threat analysis unit identifies threats that may occur in the object based on the design information of the 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 as second measures, based on the design information and standard information indicating the security standards applied to the object. The combination unit combines the first and second measures to generate a secure design diagram" (see abstract). [Prior art documents] [Patent documents]

[0007] [Patent Document 1] International Publication No. 2019 / 138542 Summary of the Invention [Problem to be solved by the invention]

[0008] Ensuring the security of a system requires following the rules described above while also taking into account the unique constraints of the subsystems and components included in the system, so implementing security measures is expected to take more time and cost.

[0009] The technology described in Patent Document 1 does not consider the constraints of the subsystems and devices used in designing security measures for the system, and even if security measures that satisfy the requirements of the standard can be extracted, there are issues with implementing them in the subsystems and components.

[0010] Therefore, one aspect of the present invention is to present security measures that comply with security rules and can be implemented in a target system. [Means for solving the problem]

[0011] In order to solve the above problems, one aspect of the present invention employs the following configuration. The security countermeasure determination device includes a processor and a memory, and the memory holds rule information indicating requirements placed on a target system in security-related rules, constraint condition information indicating a first constraint on the operating status imposed on a subsystem included in the target system and a second constraint on the specifications imposed on a component included in the target system, and countermeasure plan information indicating combinations including subsystem specific measures that are specific measures for the subsystems to satisfy the requirements and component specific measures that are specific measures for the components, a third constraint that is required of the subsystems to implement the subsystem specific measures, and a fourth constraint that is required of the components to implement the component specific measures. The processor accepts a designation of a first requirement, extracts the combination corresponding to the first requirement from the countermeasure plan information, and determines, from the extracted combinations, specific subsystem measures for the subsystems included in the target system and specific component measures for the components included in the subsystem based on a comparison result between the first constraint and the third constraint and a comparison result between the second constraint and the fourth constraint, and generates data for displaying information indicating the determined specific subsystem measures and specific component measures. [Effects of the Invention]

[0012] According to one aspect of the present invention, it is possible to present security measures that comply with security rules and that can be implemented in a target system.

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

[0014] [Figure 1] 1 is a block diagram illustrating an example of the hardware configuration of a security countermeasure determination device according to a first embodiment. [Figure 2]1 is a block diagram illustrating an example of a functional configuration of a security countermeasure determination device according to a first embodiment. [Figure 3] FIG. 4 is a diagram illustrating an example of a data configuration of system information according to the first embodiment. [Figure 4] FIG. 10 is a diagram illustrating an example of a data configuration of component information according to the first embodiment. [Figure 5] FIG. 4 is a diagram illustrating an example of a data configuration of constraint information according to the first embodiment. [Figure 6] 10 is a flowchart illustrating an example of a component role identification process according to the first embodiment. [Figure 7] FIG. 2 is a diagram illustrating an example of a data configuration of a security regulations database according to the first embodiment. [Figure 8] FIG. 4 is a diagram illustrating an example of a data configuration of role information according to the first embodiment. [Figure 9] FIG. 2 is a diagram illustrating an example of the configuration of a countermeasure database according to the first embodiment. [Figure 10] 10 is a flowchart illustrating an example of a countermeasure decision process according to the first embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of a screen configuration of a countermeasure location display screen in the first embodiment. [Figure 12] 10 is a flowchart illustrating an example of a countermeasure decision process according to the second embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of a screen configuration of a countermeasure location display screen in the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, embodiments of a security countermeasure determination system and a security countermeasure determination device will be described with reference to the drawings. However, the embodiments described below have technically preferable limitations for implementing the present disclosure, but are not intended to 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 thereof will be omitted as appropriate.

[0016] In this embodiment, the security measures determination device determines and presents security measures for OT systems including critical infrastructures, and for devices or equipment (OT products) that are components that make up the OT systems. However, security measures can also be determined and presented for any system (e.g., IT (Information Technology) systems) other than OT systems, using a procedure similar to that described below. [Example]

[0017] A security countermeasure decision apparatus and a security countermeasure decision method according to a first embodiment will be described with reference to FIGS.

[0018] 1 is a block diagram showing an example of the hardware configuration of a security countermeasure determination device 1. The security countermeasure determination device 1 determines security countermeasures for an OT system, which is an example of a target system, and components (devices) included in the OT system.

[0019] In particular, the security countermeasure determination device 1 presents security countermeasures for the OT system and the components included in the OT system to the user. The user can implement security countermeasures that can be implemented on the OT system and the components that make up the OT system, using the output results from the security countermeasure determination device 1. Hereinafter, the OT system will also be simply referred to as the system.

[0020] The security countermeasure determination device 1 is configured, for example, by 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 run software and realize multiple functions.

[0021] The arithmetic device 11 is an example of a processor, and is configured by, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), and / or a DSP (Digital Signal Processor).

[0022] 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, etc. The volatile memory 13 includes, for example, a RAM (Random Access Memory) used as a main storage device, etc.

[0023] 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 on a virtual computer constructed on multiple physical computer resources.

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

[0025] For example, a flash memory, a hard disk drive, or the like, which is the nonvolatile memory 12, stores programs executable by the arithmetic device 11 and data used when the programs are executed. That is, the nonvolatile memory 12 is a storage medium (storage device) from which a program that realizes the functions of this embodiment can be read. Also, for example, a ROM, or the like, which is the nonvolatile memory 12, stores an unchanging program (e.g., a BIOS (Basic Input / Output System)).

[0026] 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 14.

[0027] The arithmetic unit 11 executes calculations by loading a program stored in the nonvolatile memory 12 into the volatile memory 13. The arithmetic unit 11 performs predetermined calculations on data received from the input / output interface 14, the nonvolatile memory 12, and the volatile memory 13 in accordance with the program.

[0028] 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. 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 also function as a network interface device that controls communication with external devices in accordance with a predetermined protocol.

[0029] 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.

[0030] In this embodiment, the information used by the security countermeasure decision device 1 does not depend on any 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.

[0031] The input section of 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. In addition, the output section of the input / output interface 14 generates an output signal according to the calculation result in the calculation device 11 and outputs the signal to the display device 5.

[0032] 2 is a block diagram showing an example of the functional configuration of the security countermeasure decision device 1. The security countermeasure decision device 1 includes, for example, a system information input receiving unit 20, a component information input receiving unit 21, a component role identification unit 22, a countermeasure decision unit 23, a constraint condition identification unit 24, and a countermeasure location output unit 25, all of which are functions.

[0033] The system information input receiving unit 20 displays a user interface on the display device 5 to allow the user to input system information 30 via the input device 4, and outputs the system information 30 input by the user to the constraint information 60 and the component information input receiving unit 21. The system information 30 stores information indicating the tasks performed by the system. These tasks include, for example, monitoring, control, and maintenance. Details of the system information 30 will be described later using FIG. 3.

[0034] A system includes one or more subsystems that each perform a task. In other words, the tasks performed by a system refer to all tasks performed by the subsystems included in the system. Each subsystem is composed of some or all of the components included in the system. For example, if the tasks performed by a system include monitoring, control, and maintenance, each of the monitoring, control, and maintenance tasks is performed by one of the subsystems included in the system.

[0035] Note that one subsystem may perform only one task, or may perform multiple tasks. Also, one task may be performed by multiple subsystems. Also, some or all of the components included in different subsystems may overlap, or the components included in different subsystems may not overlap. Also, one subsystem may be composed of one component, or may be composed of multiple components. Also, all of the components included in a system may belong to one of the subsystems, or some components included in a system may not belong to any subsystem.

[0036] The component information input receiving unit 21 displays a user interface on the display device 5 to allow the user to input component information 40 via the input device 4, and outputs the component information 40 input by the user to the constraint condition information 60 and the component role identifying unit 22. Details of the component information 40 will be described later with reference to FIG.

[0037] The constraint information 60 generates constraints related to subsystems and components (for example, conditions related to the production rate and operating status of the subsystem, and constraints related to the specifications of the component) from the system information 30 and the component information 40 and / or from input from the user via the input device 4, and transmits the generated constraints to the constraint specification unit 24. The constraint information 60 will be described later with reference to FIG. 5.

[0038] The constraint specification unit 24 specifies constraints that can be achieved by the subsystems and / or components included in the target system, among the constraints required of the subsystems and / or components in order to implement specific security measures, and outputs the constraints to the countermeasure determination unit 23.

[0039] The component role identification unit 22 identifies the role of the component in the system and the degree of impact on the system from the system data flow 50 and the component information 40 acquired from the component information input reception unit 21, and transmits information indicating the role of the component and the degree of impact to the countermeasure decision unit 23. The internal processing of the component role identification unit 22 will be described later with reference to FIG. 6.

[0040] The data flow 50 includes, for example, data sent and received by each component within the system between other components within the system, data generated by each component when work is performed in the system, and data sent and received by each component within the system between other systems.

[0041] The countermeasure determination unit 23 uses the roles and impacts of the components mentioned above, the constraints that can be achieved in the system determined by the constraint specification unit 24, the security regulations database 2, and the countermeasure proposal database 3 to identify a subsystem as a countermeasure zone on the system, and determines the security measures required for the subsystem itself and the security measures required for the components within the subsystem.

[0042] The security legislation database 2 will be described later with reference to FIG. 7. The security legislation database 2 is, for example, generated in advance. The countermeasure proposal database 3 will be described later with reference to FIG. 8. The countermeasure proposal database 3 may be generated by the security countermeasure decision device 1, or may be generated in advance by an external system or the like. Details of the processing by the countermeasure decision unit 23 will be described later with reference to FIG. 9.

[0043] The countermeasure location output unit 25 notifies the user of the security countermeasures decided by the countermeasure decision unit 23 by outputting them together with the laws and regulations to the display device 5. The display screen output by the countermeasure location output unit 25 to the display device 5 will be described later with reference to FIG.

[0044] For example, the computing device 11 functions as a system information input accepting unit 20 by operating in accordance with a system input accepting program loaded in the volatile memory 13, and functions as a constraint condition identifying unit 24 by operating in accordance with constraint condition information 60 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.

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

[0046] The business field 31 holds information indicating the business performed by the target system, and the business includes, for example, control, monitoring, and maintenance. The related component field 32 holds information indicating components included in the OT system that are related to the business. In the related component field 32, "to" indicates that the component is related to the corresponding business.

[0047] The correspondence between "control" and "PLC to EWS" in the example of system information 30 in Figure 3 indicates that, among the components included in the OT system, the components related to the "control" task include a PLC (Programmable Logic Controller) and an EWS (Engineering Work Station).

[0048] 4 is a diagram showing an example of the data configuration of component information 40. The component information 40 is stored, for example, in the non-volatile memory 12 and / or the volatile memory 13. The component information 40 includes, for example, a component column 41 and an element column 42.

[0049] The component column 41 indicates components included in the OT system. A component is a device or apparatus (e.g., an OT product) included in the OT system, and includes, for example, a PLC, an EWS, a SCADA (Supervisory Control And Data Acquisition), an HMI (Human Machine Interface), and an IoTGW (IoT Gateway Way).

[0050] The element column 42 shows information about the elements that make up each component (such as the elements included in the component, and the specifications, type, and performance of each element). Specifically, for example, the element column 42 shows the type of OS and CPU chip installed in the PLC or IoTGW. For example, the OS type can be a general-purpose OS or a real-time operating system (RTOS). The component information 40 may also include a hardware interface, a product ID, and a media access control (MAC) address.

[0051] 5 is a diagram showing an example of the data configuration of the constraint information 60. The constraint information 60 is stored, for example, in the non-volatile memory 12 and / or the volatile memory 13. The constraint information 60 is determined, for example, by information automatically extracted from the system information 30 and the component information 40 and / or information directly input by the user.

[0052] The constraint information 60 includes, for example, a subsystem constraint table 61 that indicates constraints imposed on subsystems included in the system, and a component constraint table 62 that indicates constraints imposed on components that make up the system.

[0053] The subsystem constraint table 61 stores constraints imposed on a subsystem in association with a combination of the task performed by the subsystem and the subsystem configuration. The constraints imposed on a subsystem include, for example, the production rate of the subsystem (an example of the operating status of the subsystem) and the control period of the subsystem (an example of the operating status of the subsystem).

[0054] In the example of Figure 5, even subsystems that perform the same control tasks have different constraints depending on their configuration. For example, even if a subsystem that performs control tasks includes one PLC, the latter may have a higher production rate constraint value set than the other, since the latter has a higher processing capacity. Also, in the example of Figure 5, subsystems that perform monitoring and maintenance tasks do not necessarily have constraints on all items, just as no production rate constraint is imposed on them because they do not perform production.

[0055] Also, in the example of Figure 5, the constraints of the subsystem are defined for each combination of the business performed by the subsystem and the configuration of the subsystem, but they may also be defined for each business performed by the subsystem (without taking into account the configuration of the subsystem), or for each configuration of the subsystem (without taking into account the business performed by the subsystem).

[0056] The component constraint table 62 shows the constraints imposed on each component included in the system. In the example of Fig. 5, specific constraints on components include constraints on component specifications such as the version and type of OS, the type and performance of the CPU chip, and the type and capacity of memory, as well as constraints on the operating status of the system and / or components such as the control period of the component. Note that not all constraints need to be imposed on each component.

[0057] [Component role identification process] FIG. 6 is a flowchart showing an example of a component role identification process performed by the component role identification unit 22.

[0058] In step S60, the component role identification unit 22 automatically extracts control data and communication data from, for example, the system data flow 50. For example, the control data includes input / output data of a controller included in the system, such as a PLC, and the communication data includes data transmitted and received between components included in the system, both of which are included in the data flow 50. The control data and / or communication data may include, for example, information indicating the control cycle or communication cycle of the system.

[0059] In step S61, the component role identification unit 22 identifies the role of each component in the system from the data size of the control data and / or communication data acquired in step S60, the frequency of data communication, the type of communication protocol, etc. Here, the role of a component in the system may be, for example, information indicating only the task itself, such as control, maintenance, and monitoring (i.e., the task is also an example of a role), or may further indicate information on subdivided tasks (information on detailed tasks) such as robot control, warning light control, and integrated monitoring.

[0060] For example, if the communication between component A and component B is via a communication protocol specific to the control system (a predetermined communication protocol), the communication frequency is extremely high (for example, the communication frequency is higher than a predetermined threshold), the data size of the communication data is small (for example, the data size is equal to or smaller than a predetermined threshold), and data reading and writing occurs between component A and component B, then either component A or component B can be identified as playing the role of control. Furthermore, for example, if the communication data describes a robot's identifier (for example, the security countermeasure determination device 1 is assumed to hold information on the robot's identifier), then either component A or component B may be identified as playing the role of robot control.

[0061] Also, for example, if communication between component A and component C is via a general-purpose protocol (a predetermined communication protocol), the communication speed is not that fast (for example, the communication frequency is below a predetermined threshold), the data size of the communication data is large (for example, the data size is larger than a predetermined threshold), and one-sided data reading is occurring, then either component A or component C can be identified as playing a monitoring role.Furthermore, for example, if the communication data describes identifiers of a predetermined number or more of components (for example, it is assumed that the security countermeasure determination device 1 holds information on each component identifier), then either component A or component C may be identified as playing an integrated monitoring role.

[0062] Here, based on the communication between component A and component B, and component A and component C, component A is considered to have both control and monitoring roles, and therefore component A can be considered to be SCADA. Furthermore, component B is considered to be a controller that is responsible for control, and component C is considered to be a SCADA server or other IT terminal.

[0063] In this way, the component role identification unit 22 can identify roles based on the data size of the control data and / or communication data, the frequency of data communication, the type of communication protocol, etc. The roles are identified according to a conditional branch based on, for example, the data size of the control data and / or communication data, the frequency of data communication, the type of communication protocol, etc., and the conditional branch is determined in advance.

[0064] In step S62, the component role identification unit 22 identifies the subsystems included in the system (a subsystem is also an example of the control range (zone) of the system) from the roles identified in step S61, and identifies the degree of influence that the component has on the system.

[0065] For example, if it is determined in step S61 that the component "PLC" has the role of "control," the component role identification unit 22 refers to the system information 30, searches for a record in which the value of the task column 31 is "control" and the value of the related component column 32 includes "PLC," and identifies the component ("EWS" in the example of FIG. 3) associated with "PLC" based on the value of the related component column 32 of the record. The component role identification unit 22 determines that "PLC" and "EWS" belong to the same subsystem. In this way, the component role identification unit 22 can identify one or more subsystems.

[0066] For example, SCADA, which plays a role in integrated monitoring of a system, centrally manages control data, and therefore has a large impact on the system. The component role identification unit 22 calculates the impact on the system, for example, by Impact = Risk / Likelihood, which is a general-purpose method for quantitatively calculating the risk of cyber-attacks. Here, for example, Impact is the impact on the system when a component is attacked, Risk is an index indicating the risk when the component is attacked, and Likelihood is the probability of an attack on the component. Risk and Likelihood can be obtained, for example, by a method such as the Common Vulnerability Scoring System.

[0067] In step S63, the component role identification unit 22 transmits role information indicating the role identified in step S61 and the impact level identified in step S62 to the countermeasure decision unit 23 and the constraint condition identification unit 24, and transmits information indicating the components that constitute each of the subsystems identified in step S62 to the constraint condition identification unit 24.

[0068] 7 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 70, a category column 71, an ID column 72, and a requirement column 73.

[0069] The law name column 70 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 system and / or 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, an international standard, an industry standard, and a company standard. In other words, the security law database 2 can be said to be an example of rule information.

[0070] The category column 71 holds information indicating macro categories within security regulations. The ID column 72 holds IDs that identify requirements within a category. The requirement column 73 holds information indicating requirements within a category.

[0071] Examples of security legislation include the EU Cyber ​​Resilience Act and international standards for control system security, such as IEC (International Electrotechnical Commission) 62443. IEC 62443-4-2 classifies security requirements for components into seven categories.

[0072] The category [System Integrity] shown in the example in Figure 7 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, the component must have the function to verify the integrity of information.

[0073] FIG. 8 is a diagram showing an example of the data configuration of role information transmitted to the countermeasure determination unit 23 in step S63. The role information 80 includes, for example, an ID column 81, an impact column 82, a component column 83, and a role column 84. The ID column 81 holds an ID that identifies the record of the role information 80. The impact column 82 holds information indicating the impact identified in step S62. Note that, according to the above-mentioned method, the impact is obtained as a numerical value, and the impact obtained as the numerical value is classified into "heavy" and "low" based on a predetermined threshold. The component column 83 holds information indicating the component that has the impact indicated by the impact column 82 and plays the role indicated by the role column 84. The role column 84 holds information indicating the role identified in step S61.

[0074] 9 is a diagram showing an example of the configuration of the countermeasures database 3. The countermeasures database 3 includes, for example, a category column 301, an impact column 302, a component column 303, a role column 304, a subsystem specific measure column 305, a component specific measure column 306, a subsystem constraint column 307, and a component constraint column 308.

[0075] The category column 301 holds information indicating macro categories within security regulations. The impact column 302 holds information indicating the impact corresponding to the component indicated in the component column 303. The component column 303 holds information indicating the component included in the subsystem that is the target of the countermeasure. The role column 304 holds information indicating the role corresponding to the component.

[0076] The subsystem specific measures column 305 holds information indicating specific security measures to be implemented for the subsystem (as an entire subsystem). The component specific measures column 306 holds information indicating specific security measures to be implemented for the component indicated in the component column 303.

[0077] The subsystem constraints field 307 holds information indicating constraints required for a subsystem in order to implement in the subsystem the specific measures indicated in the subsystem specific measures field 305. The component constraints field 308 holds information indicating constraints required for a component indicated in the component field 303 in order to implement in the component the specific measures indicated in the component specific measures field 306.

[0078] The top record in the example of Figure 9 indicates that, as security measures for a system to achieve the category "availability" (satisfying the requirements corresponding to "availability"), both the specific measure "transition to degenerate operation" for the subsystem and the specific measure "provide exception handling" for the component "PLC" included in the subsystem may be implemented. Furthermore, this record indicates that the impact level of this "PLC" must be "heavy" and its role must be "robot control," that in order to implement the specific measure "transition to degenerate operation" in the subsystem, the subsystem must have an "uptime of 90% or more," and that in order to implement the specific measure "provide exception handling" in the "PLC," the "PLC" must have an "OS type: AX-X, CPU: type Bx, memory: cx."

[0079] In the example of Figure 9, the security measures indicated by one record in the countermeasure proposal database 3 are defined by a combination of specific measures for a subsystem and specific measures for a component (i.e., the security requirements indicated by the category are met by implementing both specific measures indicated by this combination), but security measures may consist of only specific measures for a subsystem (i.e., there may be a record in which the impact, component, role, component specific measures, and component constraints are not described), or may consist of only specific measures for a component (i.e., there may be a record in which the subsystem specific measures and subsystem constraints are not described).

[0080] Furthermore, there may be records in which specific measures and component constraints for a component are defined, but the impact and / or role is not defined, in the countermeasures database 3. In other words, there may be specific measures for a component that can be implemented regardless of the impact and / or role.

[0081] 9, one record describes a specific measure for one component, but there may be a record describing specific measures for multiple components. In this case, the impact, role, and constraints for each of the multiple components are also described in the record.

[0082] [Countermeasure decision process] 10 is a flowchart showing an example of a countermeasure decision process. The countermeasure decision unit 23 presents countermeasure proposals based on the roles and impact levels identified by the component role identification unit 22, the constraints that can be achieved by the subsystems and components identified by the constraint condition identification unit 24, the security regulations database 2, and the countermeasure proposal database 3.

[0083] In step S80, the countermeasure decision unit 23 accepts input of security requirements, for example, in accordance with input from the user via the input device 4, and identifies the name of the law corresponding to the requirement from the security law database 2. Hereinafter, in step S80, it is assumed that the security requirement desired by the user is "maintaining system availability."

[0084] In step S81, the countermeasure decision unit 23 extracts specific countermeasures corresponding to the security requirements input in step S80 from the countermeasure proposal database 3. Specifically, for example, the countermeasure decision unit 23 identifies a category corresponding to the input requirements from the security regulations database 2, and acquires countermeasure proposals (i.e., records in the countermeasure proposal database 3) corresponding to the identified category from the countermeasure proposal database 3. Note that the name of the regulation and the category may be input directly in step S80.

[0085] For example, if the category corresponding to the requirement "Maintain system availability" is "Availability," then the top record is obtained from the example of Countermeasure Proposal Database 3 in Figure 9. An attack that violates the "availability" of a system is a DoS (Denial of Service) attack, and one method for protecting a subsystem from a DoS attack is "degenerate operation." "Degenerate operation" is an operating method that ensures a minimum level of control performance when an abnormality occurs in a subsystem.

[0086] The following processing of steps S82 to S86 is executed for each subsystem identified in step S62, but for the sake of simplicity, the following description will be given assuming that only one subsystem is identified in step S62.

[0087] In step S82, the constraint condition identification unit 24 determines whether any of the countermeasures extracted in step S81 satisfy the subsystem constraints corresponding to the countermeasures (subsystem constraints identified from the subsystem constraint table 61) imposed on the subsystem.

[0088] Specifically, for example, the constraint condition identification unit 24 acquires, from the subsystem constraint table 61, subsystem constraints corresponding to the role (task) of the subsystem and the configuration of the subsystem indicated by the information output in step S63. The constraint condition identification unit 24 determines whether or not any of the countermeasures extracted in step S81 has the acquired subsystem constraints that satisfy the subsystem constraints indicated in the subsystem constraint column 307. Note that, among the countermeasures extracted in step S81, for countermeasures for which no subsystem constraint is described in the subsystem constraint column 307 (i.e., countermeasures for which only a component constraint is described), it is preferable to determine in step S82 that the constraints are satisfied, regardless of the contents of the subsystem constraints acquired from the subsystem constraint table 61.

[0089] According to the example of the countermeasure plan database 3 in FIG. 9, the subsystem constraint for the countermeasure plan of the top record is "availability of 90% or more," so in step S82, it is determined whether the constraints imposed on the subsystems included in the system (i.e., the subsystem constraints obtained from the subsystem constraint table 61) satisfy "availability of 90% or more."

[0090] If the constraint condition identification unit 24 determines in step S82 that there are no countermeasures that comply with the constraints imposed on the subsystem, then in step S86 the countermeasure decision unit 23 determines that countermeasures are not possible for the subsystem and terminates the countermeasure decision unit processing.

[0091] At this time, information indicating the subsystem and information indicating that a countermeasure is not possible may be displayed on the display device 5. If the constraint condition identification unit 24 determines in step S82 that there is a countermeasure that complies with the constraints imposed on the subsystem, the process proceeds to step S83.

[0092] In step S83, the constraint condition identification unit 24 determines whether, among the countermeasures determined in step S82 to be in line with the constraints imposed on the subsystem, there is any countermeasure whose constraints imposed on the components included in the subsystem (component constraints identified from the component constraint table 62) satisfy the component constraints corresponding to the countermeasures.

[0093] Specifically, for example, the constraint condition identification unit 24 acquires, from the component constraint table 62, component constraints corresponding to the components included in the subsystem indicated by the information output in step S63, and further identifies the role and impact corresponding to the component from the role information 80. The constraint condition identification unit 24 determines whether, among the countermeasures determined in step S82 to be in compliance with the constraints imposed on the subsystem, there is any countermeasure in which the combination of the component, the identified role, and the identified impact corresponds to the combination of the component indicated in the component column 303, the role indicated in the role column 304, and the impact indicated in the impact column 302, and the acquired component constraint satisfies the component constraint indicated in the component constraint column 308.

[0094] Among the countermeasures determined in step S82 to comply with the constraints imposed on the subsystem, for countermeasures for which no component constraints are described in the component constraint column 308 (i.e., for countermeasures for which only subsystem constraints are described), it is preferable to determine in step S83 that the constraints are satisfied, regardless of the content of the component constraints obtained from the component constraint table 62. Furthermore, among the countermeasures determined in step S82 to comply with the constraints imposed on the subsystem, for countermeasures for which no impact in the impact column 302 and / or role in the role column 304 are described, it is preferable to ignore the role and / or impact of the component in step S83.

[0095] 9, in the countermeasure plan database 3, the component constraint for the component "PLC" in the countermeasure plan for the top record is "OS type: AX-X, CPU: type Bx, memory: cx," so in step S82, it is determined whether the subsystems included in the system include "PLC" and whether the constraints imposed on "PLC" (i.e., the component constraints obtained from the component constraint table 62) satisfy "OS type: AX-X, CPU: type Bx, memory: cx." Furthermore, for example, when "PLC" is used as a component, the key to ensuring availability is whether exception handling for when an abnormality occurs is built into "PLC."

[0096] If the constraint condition identification unit 24 determines in step S83 that there is no countermeasure plan that satisfies the constraints imposed on the component, the process proceeds to step S86. Examples of situations in which there is no countermeasure plan that satisfies the constraints imposed on the component include a situation in which exception handling cannot be incorporated due to the memory capacity of the component, or a situation in which a backup system cannot be provided because the CPU configuration of the component is a single CPU.

[0097] If the constraint condition identification unit 24 determines in step S83 that there is a countermeasure that complies with the constraints imposed on the component (i.e., determines that there is a countermeasure that satisfies the constraints of both the subsystem and the component), it transitions to step S84.

[0098] In step S84, the countermeasure determination unit 23 determines countermeasures that satisfy the constraints of both the subsystem and the component, based on the role and impact of the component. Specifically, for example, for countermeasures that satisfy the constraints of both the subsystem and the component, the priority is determined based on the role and impact, and countermeasures up to a predetermined number of priorities are selected. For example, a rule is set in advance that assigns the priority according to a combination of role and impact, and in this rule, if the roles are the same, the higher the impact, the higher the priority, and if the impact is the same, the priority differs depending on the role.

[0099] For example, in the countermeasure proposal shown by the top record in the example in Figure 9, "PLC" has a high impact on the system and plays the important role of (robot) "control," so if the PLC is subjected to a DoS attack, it will affect the entire system. Therefore, by implementing security functions that should be implemented in "PLC," such as exception handling (which allows interrupts to degenerate operation), the impact on the system can be minimized.

[0100] In step S85, the countermeasure decision unit 23 transmits information indicating matters related to the regulations (such as the requirements input in step S80 and the names of the identified regulations) and information indicating matters related to the decided countermeasure plan (the specific measures indicated by the countermeasure plan decided in step S84, the subsystems and / or components in which the specific measures are implemented, and the configuration of the subsystems) to the countermeasure location output unit 25, and terminates the countermeasure decision process.

[0101] 11 is a diagram showing an example of the screen configuration of the countermeasure location display screen. The countermeasure location display screen 90 is a screen that the countermeasure location output unit 25 displays on the display device 5 based on the information received in step S85. Specifically, for example, the countermeasure location output unit 25 outputs the security countermeasures (specific measures) decided by the countermeasure decision unit 23 to the display device 5 together with the names of the laws and regulations to which they comply, and notifies the user of the contents thereof. The method of notifying the user is not limited to this, and the security countermeasures decided by the countermeasure decision unit 23 may also be notified by utilizing a generation AI.

[0102] The countermeasure location display screen 90 includes, for example, a law selection area 91, a law change button 92, a system display area 93, a subsystem operation display area 94, and a countermeasure list display area 95.

[0103] The legal regulation selection area 91 is an area for selecting the legal regulation that the system needs to comply with, such as the EU Cyber ​​Resilience Act and IEC 62443. When the user selects a legal regulation in the legal regulation selection area 91 and selects a control system task in the subsystem task display area 94, the display in the system display area 93 and the countermeasure list display area 95 changes to a display corresponding to the legal regulation and the subsystem.

[0104] The regulation change button 92 is used to change the target of security regulations. For example, it is used when changing from the EU Cyber ​​Resilience Act to IEC 62443.

[0105] In the system display area 93, the subsystem selected in the subsystem operation display area 94 is displayed on the system configuration diagram as a zone (in the diagram, a zone surrounded by a dotted line and hatched) along with the type of component. This allows the user to visually understand where in the system security measures should be implemented.

[0106] The countermeasure list display area 95 displays the requirements entered in step S80, the subsystem selected in the subsystem task display area 94, and specific measures (specific measures for the system to respond to the requirements) indicated by the countermeasure proposals decided for the components included in the subsystem. In the example of Fig. 11, the countermeasure list display area 95 lists subsystem duplication for the subsystem and enabling switching processing to degenerate operation for the PLC as security measures that can be implemented in the subsystem and component for the requirement "maintain availability."

[0107] As described above, the security countermeasure decision device 1 of this embodiment can identify countermeasure proposals that comply with the requirements of security laws based on the security laws database 2 and the countermeasure proposal database 3, and these countermeasure proposals are implementable in the system because they satisfy the constraints of the subsystems and components. The security countermeasure decision device 1 further determines countermeasure proposals that take into account the roles and impacts of components in the system, so can preferentially present security countermeasures that are highly important to the system. Because the security countermeasure decision device 1 can quickly determine countermeasure proposals such as those described above, it can reduce the user's man-hours required to select important security measures that comply with security laws, are implementable, and are important.

[0108] In particular, components specialized for embedding, such as OT products, have strict constraints on the resources of the elements of the component (for example, the specifications of each element are lower compared to devices included in IT systems), so the security countermeasure decision device 1 of this embodiment can narrow down the number of candidate security countermeasures that can be implemented for OT products to a small number by analyzing the combinations of constraints specific to OT products, and as a result, the security countermeasure decision device 1 can present highly appropriate security countermeasures in the security design and security operation of OT products. [Example]

[0109] A security countermeasure decision and device according to the second embodiment will be described with reference to Figures 12 and 13. Components that are the same as or equivalent to those described in the first embodiment will be given the same reference symbols, and differences will be mainly described. An example of the functional configuration of the security countermeasure decision device 1 in this embodiment is the same as that in Figure 2, so it is not shown in the figure, but the internal processing by the countermeasure decision unit 23 and the countermeasure location output unit 25 differs from that in the first embodiment.

[0110] 12 is a flowchart showing an example of a countermeasure decision process. The countermeasure decision process of this embodiment differs from the countermeasure decision process of the first embodiment (FIG. 10) in that a process of step S87 is added. The processes of steps S82 to S87 are executed for each subsystem identified in step S62.

[0111] If the constraint condition identification unit 24 determines in step S82 that there are countermeasures that comply with the constraints imposed on the subsystem, but determines that none of the countermeasures comply with the constraints imposed on the component, it transitions to step S87.

[0112] In step S87, the countermeasure determination unit 23 allocates specific countermeasures between the components included in the subsystem. Specifically, for example, the countermeasure determination unit 23 identifies components in the system information 30 that are associated (via "to") with the components in the component column 303 indicated by the countermeasure proposal that conforms to the constraints imposed on the subsystem, and allocates countermeasures between these components. Note that the countermeasures to be allocated between the components may be determined in advance for each requirement, or may be determined in advance for each combination of a requirement and the type of the component.

[0113] For example, consider a case where "availability" is a legal requirement. Due to component constraints, it may be impossible to implement specific security measures that can withstand DoS attacks, but as long as the subsystem constraints are met, the constraints can be met by incorporating specific security measures between components. For example, by introducing a data diode between a PLC and an EWS, one-way control of data becomes possible, and the component itself is also protected. In this way, even if specific security measures cannot be implemented in the component, there are cases where legal requirements can ultimately be met by linking it with the subsystem.

[0114] Following step S87, the process proceeds to step S85. In step S85, which is executed following step S87, information indicating the matters related to the determined countermeasure plan is transmitted, such as information indicating the countermeasure between components determined in step S87, the subsystem in which the countermeasure is implemented, and the configuration of the subsystem.

[0115] According to the countermeasure decision process of this embodiment, even if there is no countermeasure that complies with the constraints of both the subsystem and the component, or even if there is a countermeasure that complies only with the constraints of the subsystem, it is possible to decide on a countermeasure that can meet the requirements of the regulations.

[0116] FIG. 13 is a diagram showing an example of the screen configuration of the countermeasure location display screen. In the example of the countermeasure location display screen 90 in FIG. 13, information indicating countermeasures between components as specific countermeasures to be implemented in the subsystem is displayed in the countermeasure list display area 95. Note that information indicating which components the countermeasures are to be implemented between may also be displayed in the countermeasure list display area 95. In the example of FIG. 13, for the requirement "availability," there are no specific countermeasures that can be implemented for the components, but countermeasures that can be implemented in the subsystem (that can be implemented between components) are displayed. In the example of FIG. 13, it is shown that by introducing a data diode into the subsystem, it is possible to satisfy the availability requirements of the regulations even if security measures cannot be implemented in the PLC itself.

[0117] The present invention is not limited to the above-described embodiments, but includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0118] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement 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.

[0119] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0120] 1 security countermeasure decision device, 2 security law database, 3 countermeasure proposal database, 4 input device, 5 display device, 11 calculation device, 12 non-volatile memory, 13 volatile memory, 20 system information input reception unit, 21 component information input reception unit, 22 component role identification unit, 23 countermeasure decision unit, 24 constraint condition identification unit, 25 countermeasure location output unit, 30 system information, 40 component information, 50 data flow, 60 constraint condition information, 90 countermeasure location display screen

Claims

1. A security countermeasure determination device, a processor and a memory, The memory includes: rule information indicating requirements imposed on a target system in security rules; Constraint condition information indicating a first constraint on an operating status imposed on a subsystem included in the target system and a second constraint on a specification imposed on a component included in the target system; retaining countermeasure plan information indicating a combination including a subsystem specific measure, which is a specific measure for a subsystem, and a component specific measure, which is a specific measure for a component, for satisfying the requirements, a third constraint required for the subsystem in order to implement the subsystem specific measure, and a fourth constraint required for the component in order to implement the component specific measure; The processor: Accept the designation of the first requirement, extracting the combination corresponding to the first requirement from the countermeasure plan information; determining, from the extracted combinations, specific subsystem measures for subsystems included in the target system and specific component measures for components included in the subsystems, based on a comparison result between the first constraint and the third constraint and a comparison result between the second constraint and the fourth constraint; a security countermeasure determination device that generates data for displaying information indicating the determined subsystem specific measures and component specific measures;

2. 2. The security countermeasure determination device according to claim 1, the memory holds role information indicating a role in the target system of a component included in the target system and an impact of the component on the target system; The processor: selecting a subsystem specific measure and a component specific measure from the determined subsystem specific measure and component specific measure based on a priority determined in accordance with predetermined conditions related to the role and the impact of the component in which the component specific measure is implemented; generating data for displaying the selected subsystem and component measures; A security countermeasure determination device, wherein under the predetermined conditions, the priority is determined by a combination of the role and the degree of impact, and the higher the degree of impact, the higher the priority.

3. 3. The security countermeasure determination device according to claim 2, The countermeasure plan information includes information indicating a role and an impact of a component on which the component specific countermeasure is implemented; The processor determines specific subsystem measures for subsystems included in the target system and specific component measures for components included in the subsystems from the extracted combinations based on the results of comparing the first constraint with the third constraint, the results of comparing the second constraint with the fourth constraint, and the results of comparing the role and impact indicated by the role information with the role and impact indicated by the countermeasure proposal information.

4. 3. The security countermeasure determination device according to claim 2, The memory holds a data flow indicating control data and / or communication data in components included in the target system; The processor refers to the data flow to identify at least one of a data size, a communication frequency, and a communication protocol of the control data and / or the communication data; a security countermeasure determination device that identifies a role of a component included in the target system in the target system based on the at least one of the components and a predetermined condition related to the at least one of the components, and stores information indicating the identified role in the role information.

5. 2. The security countermeasure determination device according to claim 1, The security countermeasure determination device, wherein the processor generates data for displaying information indicating subsystems and components in which the determined subsystem-specific measures and component-specific measures are implemented.

6. 2. The security countermeasure determination device according to claim 1, The component includes an OS, a CPU, and a memory; the first constraint and the third constraint include at least one of a constraint on a production rate of the subsystem and a constraint on a control period of the subsystem; The security countermeasure determination device, wherein the second constraint and the fourth constraint include at least one of a constraint on the OS type of the component, a constraint on the CPU performance of the component, a constraint on the memory capacity of the component, and a constraint on the control period of the component.

7. 2. The security countermeasure determination device according to claim 1, the memory holds system information indicating relevant components within the target system; The processor: If it is determined that, among the extracted combinations, there is a combination of a subsystem specific measure that can be implemented in a subsystem included in the target system and a component specific measure that cannot be implemented in a component included in the subsystem, based on a comparison result between the first constraint and the third constraint and a comparison result between the second constraint and the fourth constraint, determining inter-component measures corresponding to the first requirement to be implemented between the component and a component related to the component in the system information; generating data for displaying information indicating the determined inter-component measures; The security countermeasure determination device, wherein the inter-component countermeasures are determined in advance for each of the requirements.

8. A security countermeasure determination method by a security countermeasure determination device, comprising: the security measure determination device has a processor and a memory, The memory includes: rule information indicating requirements imposed on a target system in security rules; Constraint condition information indicating a first constraint on an operating status imposed on a subsystem included in the target system and a second constraint on a specification imposed on a component included in the target system; retaining countermeasure plan information indicating a combination including a subsystem specific measure, which is a specific measure for a subsystem, and a component specific measure, which is a specific measure for a component, for satisfying the requirements, a third constraint required for the subsystem in order to implement the subsystem specific measure, and a fourth constraint required for the component in order to implement the component specific measure; The security measure determination method includes: the processor accepts a designation of a first requirement; the processor extracts the combination corresponding to the first requirement from the countermeasure plan information; the processor determines, from the extracted combinations, a subsystem-specific measure for a subsystem included in the target system and a component-specific measure for a component included in the subsystem, based on a comparison result between the first constraint and the third constraint and a comparison result between the second constraint and the fourth constraint; The security countermeasure determination method, wherein the processor generates data for displaying information indicating the determined subsystem specific measures and component specific measures.

Images