Analyzing device and analyzing method

Abstract

To provide a CPS having both the availability and the security taken into consideration.SOLUTION: An analyzing device includes: a first detecting unit that detects a simulation attack result from a simulation result in which a predetermined security countermeasure is applied to an evaluation subjected model obtained by modeling an evaluation subject, and then a simulation attack is given thereto; a second detecting unit that detects an availability evaluation result representing whether the simulation result is in compliance with evaluation conditions relating to the availability of the evaluation subject or not; and a comprehensively evaluating unit that generates the comprehensive evaluation results of the security countermeasure and the availability both subjected to the evaluation on the basis of the simulation attack result detected by the first detecting unit and of the availability evaluation result detected by the second detecting unit.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to an analysis device and an analysis method for analyzing data. [Background technology]

[0002] In recent years, advances in technologies such as IoT (Internet of Things) have made it possible to collect various information from the real world, making it possible to model all of the information in the real world and reproduce what is happening in the real world in cyberspace. In this way, a model that electronically represents (digitally represents) a physical or perceptual real-world entity, concept, or concept, as well as the technology to realize it, are called digital twins.

[0003] The interconnected mechanism that uses digital twins to tightly link real space and cyberspace and have them work together is called a Cyber ​​Physical System (CPS). CPS is a method and technology that uses sensors to collect various data in the real world, analyzes it in cyberspace, and creates knowledge from it, then feeds the information and value created there back into the real world, automating some or all of the work that was previously done manually.

[0004] The following Patent Document 1 discloses a method for providing recommendations for optimizing the operation of a set of industrial assets. In this method, a digital twin of the set of industrial assets is generated. The digital twin includes a data structure representing the state of each of a plurality of subsystems of the set of industrial assets. These states are estimated based on the application of a simulation using a cumulative damage model. The cumulative damage model models the effect of exogenous factors on the operation of the set of industrial assets over a period of time. The digital twin is analyzed with respect to the simulated operational performance to determine an optimized control of the operation of the industrial assets. The optimized control of the operation is calculated jointly and individually to improve, with a certain probability, a certain operational performance criterion of the current and future industrial assets or to reduce an economic risk associated with the operation of the industrial assets. The use of a user interface is recommended to optimize the operation of the industrial assets or to automatically change operational setpoints related to the industrial assets.

[0005] The following Patent Document 2 discloses an analysis system. In this analysis system, a topology identification unit identifies a network topology of devices included in a system to be diagnosed. A detection unit detects a first attack route indicating a flow of a feasible attack in the system to be diagnosed based on security information related to the devices. A damage identification unit identifies damage information indicating the content of damage that will be caused when a device on the first attack route is attacked. The detection unit detects a second attack route indicating a flow of a feasible attack caused by the content of the damage based on the security information and the identified damage information. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] International Publication No. 2017 / 192998 [Patent Document 2] International Publication No. 2020 / 195300 Summary of the Invention [Problem to be solved by the invention]

[0007] To realize a CPS in a system including a control device, it is necessary to consider not only security but also availability of operation instructions to the control device, including security measures. The above-mentioned Patent Documents 1 and 2 do not disclose this point.

[0008] In systems that include control devices, it is strongly required that operations on the system not only ensure the normal operation of the device that is the target of the operation instructions, but also that they do not have a negative impact on other devices that are affected by the device that is the target of the operation instructions, or on the system as a whole.

[0009] For example, unlike models that are complete in cyberspace, operational instructions for a system in the real world change the state of control devices that have physically operating parts. If an incorrect operational instruction is given, it can lead to failures of the device that is the target of the instruction, other devices that are affected by it, and the entire system, as well as injuries to workers in the vicinity. For this reason, negative effects are not limited to cyberspace.

[0010] An object of the present invention is to provide a CPS that takes into consideration both availability and security. [Means for solving the problem]

[0011] An analysis device according to one aspect of the invention disclosed in the present application is characterized in having a first detection unit that detects simulated attack results from simulation results in which a simulated attack is performed by applying predetermined security measures to an evaluation target model that is a model of an evaluation target, a second detection unit that detects availability evaluation results indicating whether the simulation results comply with evaluation conditions regarding the availability of the evaluation target, and a comprehensive evaluation unit that generates a comprehensive evaluation result of the security measures and availability of the evaluation target based on the simulated attack results detected by the first detection unit and the availability evaluation results detected by the second detection unit.

[0012] An analytical device according to another aspect of the invention disclosed in the present application includes a memory unit that stores associated information correlating a first range in which a value of a first parameter related to an evaluation object can be taken and a second range in which a value of a second parameter related to the evaluation object can be taken when the value of the first parameter is within the first range, a first detection unit that detects the value of the first parameter from the evaluation object, a second detection unit that detects a calculated value of the second parameter from a simulation result in which the detected value of the first parameter detected by the first detection unit is applied to an evaluation object model that models the evaluation object, a judgment unit that judges whether the detected value is within the first range and the calculated value detected by the second detection unit is within the second range by referring to the associated information, and an output unit that outputs a result of the judgment made by the judgment unit. Effect of the Invention

[0013] According to a representative embodiment of the present invention, it is possible to provide a CPS that takes into consideration both availability and security. Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a security system according to a first embodiment. [Diagram 2] FIG. 2 is a block diagram showing an example of a hardware configuration of a computer. [Diagram 3] FIG. 3 is an explanatory diagram showing an example of data transmission and reception relationships for the security digital twin core system. [Figure 4] FIG. 4 is a sequence diagram showing an example of a processing procedure for collecting data from a system to be evaluated in a security digital twin and generating a model for the security digital twin. [Diagram 5] FIG. 5 is a sequence diagram showing an example of an operation and control process procedure for the evaluation target system. [Figure 6]Figure 6 is a sequence diagram showing an example of the behavior procedure of the security digital twin core system. [Figure 7] FIG. 7 is an explanatory diagram showing an example of the data transmission / reception relationship related to the simulation function group 110 in the security digital twin core system. [Figure 8] FIG. 8 is a sequence diagram showing the procedure for generating a security digital twin model and an availability evaluation condition list. [Figure 9] FIG. 9 is a sequence diagram illustrating an example of a procedure for automatically generating an availability evaluation condition list. [Figure 10] FIG. 10 is a sequence diagram showing an example of a procedure in which the action module group generates model operation data. [Figure 11] FIG. 11 is a sequence diagram showing an example of the procedure until a simulation is executed in the security digital twin core system. [Figure 12] FIG. 12 is an explanatory diagram showing an example of the data transmission / reception relationship related to the evaluation / control function group 120 in the security digital twin core system. [Figure 13] FIG. 13 is a sequence diagram showing an example of a procedure for performing various evaluations after the simulation is performed and outputting the evaluation results within the scope of FIG. [Figure 14] FIG. 14 is a block diagram showing an example of the configuration of a security digital twin model for a system to be evaluated. [Figure 15] FIG. 15 is an explanatory diagram illustrating an example of the node information table. [Figure 16] FIG. 16 is an explanatory diagram illustrating an example of the vulnerability information table. [Figure 17] FIG. 17 is an explanatory diagram showing an example of the availability evaluation condition list. [Figure 18] FIG. 18 is an explanatory diagram showing a first example of an attack by model operation data on a system to be evaluated, using the security digital twin model shown in FIG. [Figure 19]FIG. 19 is an explanatory diagram showing a second example of an attack by model operation data on the evaluation target system using the security digital twin model shown in FIG. [Figure 20] FIG. 20 is an explanatory diagram showing a third example of an attack by model operation data on a system to be evaluated, using the security digital twin model shown in FIG. [Figure 21] FIG. 21 is an explanatory diagram showing a fourth example of an attack by model operation data on a system to be evaluated, using the security digital twin model shown in FIG. [Figure 22] FIG. 22 is an explanatory diagram showing an example of the security countermeasure model operation list. [Diagram 23] FIG. 23 is an explanatory diagram showing a simulation result when the measure α is applied. [Figure 24] FIG. 24 is an explanatory diagram showing a simulation result when the measure β is applied. [Diagram 25] FIG. 25 is an explanatory diagram showing a simulation result when the measure γ is applied. [Figure 26] FIG. 26 is an explanatory diagram showing an example of detection of the availability evaluation result of the measure α by the availability evaluation result detection unit. [Figure 27] FIG. 27 is an explanatory diagram showing an example of detection of the availability evaluation result of the measure β by the availability evaluation result detection unit. [Figure 28] FIG. 28 is an explanatory diagram showing an example of detection of the availability evaluation result of the measure γ by the availability evaluation result detection unit. [Figure 29] FIG. 29 is an explanatory diagram illustrating an example of a comprehensive evaluation result. [Diagram 30] FIG. 30 is a diagram illustrating a configuration example of a security system according to the second embodiment. [Diagram 31] FIG. 31 is an explanatory diagram illustrating an example of the operation range table. [Diagram 32] FIG. 32 is a sequence diagram illustrating an example of a procedure for verifying a parameter change. [Diagram 33] FIG. 33 is an explanatory diagram of an example of the availability evaluation result list in the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS EXAMPLES

[0015] <Security system configuration> 1 is an explanatory diagram showing a configuration example of a security system according to Example 1. The security system includes a security digital twin 1, an evaluation target system 2, a user computer system 3, an external system or service 5, and a digital twin system 6.

[0016] In the first embodiment, the system to be evaluated, operated, and controlled by the security digital twin 1 is referred to as the evaluation target system 2. Furthermore, a user who operates the security digital twin 1 and evaluates, operates, and controls the evaluation target system 2 is referred to as a user 4. A computer used by the user 4 to operate the security digital twin 1 is referred to as a user computer system 3.

[0017] The security digital twin 1 has a security digital twin core system 100, a core system operation API interface 101, a system information collection unit 102, a system control unit 103, and a management function unit 104.

[0018] The security digital twin core system 100 executes the main processing of the security digital twin 1. The core system operation API interface 101 is an application side interface of the security digital twin core system 100. The system information collection unit 102 collects system information of the evaluation target system 2 from the evaluation target system 2 side interface of the security digital twin core system 100. The system control unit 103 executes control of the evaluation target system 2. The management function unit 104 has an interface function that enables the user 4 to operate the security digital twin 1 and the security digital twin core system 100 using the user's computer system 3.

[0019] The security digital twin core system 100 is a system that executes the main processing of the security digital twin 1, and has a simulation system function group 110 and an evaluation / control system function group 120. Each function of the simulation system function group 110 and the evaluation / control system function group 120 is operated and managed by a core system operation API interface 101.

[0020] The simulation function group 110 is a function group that reproduces the evaluation target system 2 as a digital twin in cyberspace based on information collected from the evaluation target system 2, and executes operations and simulated attacks on the evaluation target system 2. Specifically, for example, the simulation function group 110 has, as functions, a security digital twin model generation unit 111, an availability evaluation condition generation unit 112, an action module group 113, and a simulation execution unit 114.

[0021] The evaluation / control system function group 120 is a function group that evaluates the results of the simulation executed by the simulation system function group 110 from the viewpoints of security and availability, and generates control for the evaluation target system 2. Specifically, for example, the evaluation / control system function group 120 has a first detection unit 121, a second detection unit 122, a security countermeasure comprehensive evaluation unit 123, and a system automatic application determination unit 124. In addition to the first detection unit 121 to the system automatic application determination unit 124, additional functions and function groups may be provided depending on the functions of the action module group 113. Details of each function of the security digital twin core system 100 will be described later with reference to FIG. 3 and subsequent figures.

[0022] In addition to these, the security digital twin 1 may include one or more optional automation systems 105 as a system that automatically executes the security digital twin core system 100. An example of the automation system 105 is an automatic security evaluation execution system that checks vulnerabilities in the evaluation target system 2 in response to the disclosure of vulnerability information and automatically executes countermeasures.

[0023] In addition, a digital twin system 6 shared with a system external to the security digital twin 1 may be provided as a means for collecting information from the system 2 under evaluation and controlling the system 2 under evaluation. The digital twin system 6 has functions such as generating a digital twin model and generating controls that serve as the basis for an external system or service 5 other than the security digital twin.

[0024] In addition, a path 106 may be provided as a path for operating the security digital twin core system 100 from an external system or service 5.

[0025] Furthermore, the functions that make up the security digital twin 1 described above, and the blocks represented by squares which are groups of functions, may be composed of multiple functions for the purpose of realizing the function, or may have their own individual memory system such as a storage or database.

[0026] In addition, the security digital twin 1 and the security digital twin core system 100 may each have any memory system, such as storage or a database, that can be used by the entire system or some of the functions that make up the system, not shown in Figure 1.

[0027] In addition, the security digital twin 1 and the systems, functions, and functional groups that constitute it may have communication paths not shown in Figure 1.

[0028] <Computer hardware configuration> 2 is a block diagram showing an example of a hardware configuration of a computer. A computer 200 is a collective term for the security digital twin 1, the evaluation target system 2, the user computer system 3, the external system 5, and the digital twin system 6 shown in FIG.

[0029] The computer 200 includes a processor 201, a storage device 202, an input device 203, an output device 204, and a communication interface (communication IF) 205. The processor 201, the storage device 202, the input device 203, the output device 204, and the communication IF 205 are connected by a bus 206. The processor 201 controls the computer 200. The storage device 202 serves as a working area for the processor 201. The storage device 202 is a non-transient or temporary recording medium that stores various programs and data. Examples of the storage device 202 include a ROM (Read Only Memory), a RAM (Random Access Memory), a HDD (Hard Disk Drive), and a flash memory. The input device 203 inputs data. Examples of the input device 203 include a keyboard, a mouse, a touch panel, a numeric keypad, a scanner, a microphone, and a sensor. The output device 204 outputs data. The output device 204 may be, for example, a display, a printer, or a speaker. The communication IF 205 connects to a network and transmits and receives data.

[0030] In addition, some or all of the programs and data stored in computer 200 may be stored in advance in a non-temporary area of ​​storage device 202 provided in computer 200, or, if necessary, may be stored in the non-temporary area of ​​storage device 202 from a non-temporary storage device of another device connected to the network, or from a non-temporary storage medium connected to an interface not shown.

[0031] In addition, the security digital twin 1, the system to be evaluated 2, the user computer system 3, the external system 5, and the digital twin system 6 shown in Figure 1 can realize each of the processes described below, for example, by being executed on one or more computers 200 having a hardware configuration such as that illustrated in Figure 2.

[0032] <Data transmission and reception relationship for the security digital twin core system 100> Fig. 3 is an explanatory diagram showing an example of data transmission / reception relationships for the security digital twin core system 100. Data transmission / reception relationships within the security digital twin core system 100 will be described in Fig. 7 and subsequent figures.

[0033] First, the relationship between the system to be evaluated 2 and the security digital twin core system 100 and the system information collection unit 102, system control unit 103, and digital twin system 6 on the route therebetween will be described.

[0034] The security digital twin 1 acquires raw data 300 expressing system information and system operation of the group of devices constituting the evaluation target system 2 from the evaluation target system 2 by the system information collection unit 102. The acquired raw data 300 is converted into structured data 301 by the system information collection unit 102 and sent to the inside of the security digital twin core system 100.

[0035] The control commands generated within the security digital twin core system 100 are transmitted from within the security digital twin core system 100 to the system control unit 103 as structured control command data 302.

[0036] The system control unit 103 converts the structured control command data 302 into an optimum form for controlling the control target device by the control command data 302 in the device constituting the evaluation target system 2, and transmits the control command 303 to the control target device.

[0037] In this process, the functions of the system information collection unit 102 and the system control unit 103 may be executed by the digital twin system 6 as a common function with the external system 5. Furthermore, even if the functions of the system information collection unit 102 and the system control unit 103 are not executed, the digital twin system 6 may provide a function of relaying the structured data 301 and the control command data 302 and converting them into an optimal form for the security digital twin core system 100.

[0038] Next, we will describe the relationship between the user 4, the user computer system 3, and the security digital twin 1. The user 4 who uses the security digital twin 1 uses the user computer system 3 to access the security digital twin 1 via a path 310.

[0039] In this case, the security digital twin 1 is provided with a management function unit 104 as a user interface for the security digital twin 1. As a method for operating the security digital twin 1, for example, the management function unit 104 may be used as a Web application operated using Web browsing software provided in the user's computer system 3. In addition, dedicated client application software for operating the security digital twin 1 may be installed in the user's computer system 3, and the management function unit 104 may be used as a communication destination of the client application software.

[0040] In addition, the management function unit 104 may display an operation screen on the user's computer system 3 using a GUI (Graphical User Interface), or may provide the user's computer system 3 with a function to be operated using a CUI (Command-Line User Interface).

[0041] Next, the relationship between the security digital twin core system 100 and its interface, the core system operation API interface 101, the management function unit 104 that controls the security digital twin core system 100, the automation system 105, and the external system 5 will be described.

[0042] Operations performed from the user computer system 3 to the management function unit 104 via path 310 are transmitted via path 306 to the core system operation API interface 101 to operate the security digital twin core system 100 .

[0043] On path 307, data is sent to the management function unit 104 to respond to the user computer system 3 and the user 4, such as commands and operation results sent to the security digital twin core system 100 on path 306.

[0044] Similarly, an operation is performed on the security digital twin core system 100 from the external system 5 via path 308 and the core system operation API interface 101, and the response is sent via path 309.

[0045] Similarly, commands from the automation system 105 are sent to the security digital twin core system 100 via path 304 and the core system operation API interface 101, and responses are sent to the automation system 105 via path 305.

[0046] Finally, the user computer system 3 and the external system 5 may have a function of operating the external system 5 via a path 311. In addition, the external system 5 may obtain system information from the digital twin system 6 via a path 312, and may transmit information for operating the evaluation target system 2 to the digital twin system 6 via a path 313.

[0047] <Procedure for generating security digital twin models> FIG. 4 is a sequence diagram showing an example of the processing procedure for collecting data from the system 2 to be evaluated in the security digital twin 1 and generating a model for the security digital twin. FIG. 4 describes the procedure for the system information collection unit 102 to collect information from the system 2 to be evaluated and send the data to the security digital twin core system 100. The procedure is explained below. Note that in FIG. 4, the dotted line indicates the case where the digital twin system 6 is used as the system information collection unit 102. In that case, the "system information collection unit 102" can be read as the "digital twin system 6" in the following explanation.

[0048] First, an information collection trigger occurs in the system information collection unit 102 (step S400). Examples of the information collection trigger include a trigger that occurs on an hourly basis, a trigger due to a request from the security digital twin core system 100, and the like.

[0049] Next, the system information collector 102 requests the raw data 300 of system information and system operation data from the system 2 under evaluation based on the information collection trigger of step S400 (step S401).

[0050] The devices constituting the system 2 to be evaluated transmit the raw data 300 of system information and system operation data to the system information collector 102 in response to the request in step S401 (step S402). Note that the devices of the system 2 to be evaluated may execute step S402 without going through the processes of steps S400 and S401.

[0051] When the system information collection unit 102 receives the raw data 300 in step S402, it converts the raw data 300 into structured data 301 and stores it therein (step S403). The structured data 301 may be stored in any place and by any method. For example, the structured data 301 may be stored in the same place as the system information collection unit 102 on a file basis, or a database shared by the security digital twin 1 may be prepared and stored therein.

[0052] After step S403 is executed, the system information collection unit 102 may immediately transmit the structured data 301 to the security digital twin core system 100, or may store it in the system information collection unit 102 until a request is received from the security digital twin core system 100 (step S404).

[0053] Next, the procedure for sending data from the system information collection unit 102 to the security digital twin core system 100 will be described.

[0054] First, in the case where data is collected using the security digital twin core system 100 as a trigger, a model generation trigger occurs in the security digital twin core system 100 (step S410). The model generation trigger may be any trigger, similar to step S400.

[0055] Next, based on step S410, the security digital twin core system 100 executes a data transmission request to the system information collection unit 102 (step S411). Up to this point, this is the flow up to executing a data transmission request to the system information collection unit 102 when the security digital twin core system 100 collects data.

[0056] Next, when the system information collection unit 102 itself sends data to the security digital twin core system 100, a data transmission trigger is first generated in the system information collection unit 102 (step S412). The data transmission trigger may be any trigger, as in step S400. Also, when data is transmitted continuously from step S403, the end of step S403 is step S412.

[0057] When the system information collection unit 102 receives a data transmission request (step S411) or when a data transmission trigger occurs (step S412), it transmits the structured data 301 stored in the system information collection unit 102 to the security digital twin core system 100 (step S413).

[0058] Finally, the security digital twin core system 100 uses the structured data 301 received in step S413 to execute internal processing such as model generation (step S414).

[0059] <Operation and control procedures for evaluation target system 2> FIG. 5 is a sequence diagram showing an example of an operation and control processing procedure for the system 2 to be evaluated. In FIG. 5, the security digital twin 1 obtains some results in the security digital twin core system 100 and performs operation and control on the system 2 to be evaluated. Note that in FIG. 5, the dotted line indicates the case where the digital twin system 6 is used as the system control unit 103. In that case, the "system control unit 103" can be read as the "digital twin system 6" in the following explanation.

[0060] First, a request for evaluation and control occurs in security digital twin core system 100 (step S500), and based on that, security digital twin core system 100 executes an evaluation process and generates a control request (step S501). Details of this step will be explained from Figure 6 onwards, but Figure 5 shows that a procedure has been performed in which some kind of control request is generated as a function of security digital twin core system 100.

[0061] Next, the security digital twin core system 100 transmits the control request generated in step S501 to the system control unit 103 as structured control command data 302 (step S502).

[0062] When the system control unit 103 receives the control command data 302 structured in step S502, it executes internal processing (step S503). The internal processing (step S503) is, for example, a process of converting the control command data 302 into a control command suitable for a device in the evaluation target system 2 specified by the control command data 302.

[0063] Next, the control command generated in step S503 is transmitted to the target device of the system 2 under evaluation (step S504). Based on this, the target device executes control (step S505).

[0064] Next, the system control unit 103 requests the control result of step S505 from the target device of the evaluation target system 2 in order to confirm the control result of step S505 in the security digital twin core system 100 (step S506).

[0065] When the target device of the system 2 to be evaluated receives the request in step S506, it transmits the state after the control, which is the control result, to the system control unit 103 (step S507).

[0066] When the system control unit 103 receives the control result of step S507, it executes internal processing to convert the received control result into a form that can be interpreted by the security digital twin core system 100 (step S508).

[0067] Finally, the system control unit 103 transmits the control result converted in step S508 to the security digital twin core system 100 as a processing result response (step S509).

[0068] <Example of behavior procedure of Security Digital Twin Core System 100> FIG. 6 is a sequence diagram showing an example of the behavior procedure of the security digital twin core system 100. FIG. 6 shows an example of the behavior procedure of the security digital twin core system 100 when a user 4 in the security digital twin 1 operates the security digital twin core system 100 that controls the security digital twin 1 and its main functions, and requests evaluation, control, and operation of the evaluation target system 2. Note that the process within the dashed line 614 is executed when some control or operation is involved with the evaluation target system 2, and this process is not executed when only evaluation is performed. Also, the process within the dashed line 615 is a process for inquiring of the user 4 as to whether or not to execute the control process, but this process may or may not be executed. Also, whether or not to execute the process within the dashed line 615 may be determined depending on the process.

[0069] First, the user computer system 3 receives an input of a request for evaluation, control, and operation of the security digital twin 1 through the operation of the user 4 (step S600). Based on this, the user computer system 3 executes the request for evaluation, control, and operation to the management function unit 104 (step S601).

[0070] The management function unit 104 transfers the evaluation, control, and operation requests in step S601 to each function unit of the security digital twin core system 100 (step S602). The security digital twin core system 100 executes evaluation processing and operation processing (step S603).

[0071] Next, based on the processing result of step S603, if a control process is required, the security digital twin core system 100 generates the control process (step S604). At this time, if the user 4 needs to confirm the execution of the control process, the security digital twin core system 100 sends a confirmation request to the management function unit 104 (step S605). Upon receiving the confirmation request, the management function unit 104 requests the user computer system 3 to input confirmation of the execution of the control process (step S606).

[0072] The user computer system 3 receives an input of whether or not to confirm the control processing execution displayed on the user computer system in step S606 through the operation of the user 4 (step S607), and transmits the response to the management function unit 104 (step S608). At this time, if the response input in step S607 indicates that the control processing is possible, the management function unit 104 commands the security digital twin core system 100 to execute the control processing (step S609).

[0073] Next, when executing control processing, the security digital twin core system 100 uses the entry into step S609 as a trigger for a request for evaluation and control in step S500 of Figure 5, executes control processing based on steps S500 to S509 of Figure 5, and obtains a processing result response (step S509) (step S610).

[0074] Next, the security digital twin core system 100 transmits the processing result of step S603 to the management function unit 104 as a result response if only evaluation processing and operation processing are performed, or the processing results of steps S603 and S611 if control processing is included (step S611).

[0075] The management function unit 104 transfers the result response of step S611 to the user computer system 3 (step S612). When the user computer system 3 receives the result response of step S612, it displays it on its display screen (step S613). The user 4 checks the displayed result response.

[0076] The procedure described in steps S600 to S613 may be applied to the automation system 105 and external system 5 in Fig. 3. In that case, the parts corresponding to the user 4, the user computer system 3, and the management function unit 104 become the automation system 105 and the external system 5. The external system 5 may be operated by the operation of the user 4 and the user computer system 3 via the path 311. The procedure described in steps S600 to S613 may be executed by connecting to the functions and systems directly connected to the path 106 in Fig. 1 or the management function unit 104 by other methods.

[0077] <Data transmission / reception relationship related to the simulation system function group 110> 7 is an explanatory diagram showing an example of the data transmission / reception relationship related to the simulation function group 110 in the security digital twin core system 100. Each function and its relationship will be described below.

[0078] The structured data 301 sent from the system information collection unit 102 to the security digital twin core system 100 is input to the security digital twin model generation unit 111 and the availability evaluation condition generation unit 112.

[0079] The security digital twin model generation unit 111 generates a security digital twin model 700, which is a model of the system required to execute various simulations and evaluations in the security digital twin 1. The availability evaluation condition generation unit 112 generates an availability evaluation condition list 701, which is a list including conditions required to evaluate the availability of the system.

[0080] The action module group 113 is a functional group that generates any operation to be performed on the security digital twin model 700. The action module group 113 is one of the core functions in the security digital twin 1, and generates model operation data 702 that indicates the operation to be performed on the evaluation target system 2 as an operation on the model.

[0081] Examples of operations that may be desired to be performed on the system 2 under evaluation include control commands that the external system or service 5 in Figure 1 is attempting to perform on the system 2 under evaluation, simulated attacks to evaluate the impact of attacking vulnerabilities in the system 2 under evaluation, and security measures that are being attempted to be applied to the system 2 under evaluation in order to eliminate vulnerabilities that exist in the system 2 under evaluation.

[0082] The action module group 113 generates model operation data 702 based on the operation request for the model sent from the core system operation API interface 101 and the security digital twin model 700 sent from the security digital twin model generation unit 111, and transmits it to the simulation execution unit 114. The security digital twin model 700 is data in which the evaluation target system 2 is modeled.

[0083] The core system operation API interface 101 receives requests to the security digital twin core system 100 from the management function unit 104, the automation system 105, and the external system or service 5. The core system operation API interface 101 transmits operations and commands to internal functions of the security digital twin core system 100, such as a request to generate a security digital twin model 700, a request to generate an availability evaluation condition list 701, an operation request 703 to the action module group 113, and a simulation execution command 704, receives the results 705 of a simulation based thereon, and responds with the results to the request sender.

[0084] The simulation execution unit 114 executes a simulation from the viewpoint of a CPS that takes availability and security into consideration, using a security digital twin model 700, an availability evaluation condition list 701, and model operation data 702, in response to a simulation execution command 704 via the core system operation API interface 101. The simulation execution unit 114 transmits a result 705 of the simulation to the core system operation API interface 101 and the evaluation / control system function group 120.

[0085] <Procedure for generating security digital twin model 700 and availability evaluation condition list 701> Fig. 8 is a sequence diagram showing the procedure for generating a security digital twin model 700 and an availability evaluation condition list 701. Fig. 8 shows an example of the procedure for collecting system information from the system information collection unit 102, and generating the security digital twin model 700 and the availability evaluation condition list 701 by the security digital twin model generation unit 111 and the availability evaluation condition generation unit 112. Note that dashed line 810 represents the contents described in steps S410 to S414 in Fig. 4.

[0086] The generation of the security digital twin model 700 and the availability evaluation condition list 701 is initiated by the occurrence of a model generation trigger (step S410) and a data transmission trigger (step S412) as described in steps S410 to S414 of Fig. 4. Of these, the model generation trigger may be generated by, for example, a request from the core system operation API interface 101.

[0087] In this case, when the core system operation API interface 101 receives a model generation request (step S800), it transmits the model generation request to the security digital twin model generation unit 111 and the availability evaluation condition generation unit 112 (step S801). This causes the generation of a model generation trigger (step S410). The following steps S410 to S414 are as already described.

[0088] Finally, when the security digital twin model generation unit 111 and the availability evaluation condition generation unit 112 complete the generation of the model (step S414), they transmit the result to the core system operation API interface 101 (step S802). The core system operation API interface 101 transmits the result to the request source of the model generation request (step S800) (step S803).

[0089] The availability evaluation condition generating unit 112 may read out the availability evaluation condition list 701 created in advance by the user 4, or may automatically generate the availability evaluation condition list 701. A specific description will be given of the case where the availability evaluation condition list 701 is automatically generated.

[0090] <Procedure for automatically generating availability evaluation condition list 701> 9 is a sequence diagram showing an example of a processing procedure for automatically generating the availability evaluation condition list 701. The procedure will be described below. The core system operation API interface 101 receives a request to generate the availability evaluation condition list 701 (step S900). The request to generate the availability evaluation condition list 701 is sent, for example, from the user's computer system 3 operated by the user 4, from the automation system 105, or from an external system or service 5.

[0091] When the core system operation API interface 101 receives a request to generate the availability evaluation condition list 701, it transmits it to the availability evaluation condition generating unit 112 (step S901).

[0092] When the availability evaluation condition generating unit 112 receives a request to generate the availability evaluation condition list 701, it requests the system information collecting unit 102 for normal operation data of the equipment system constituting the evaluation target system 2 related to the generation of the requested availability condition (step S902). Normal operation refers to the operation when the equipment system is operating normally without any problems. Examples of data indicating this operation include application and system logs.

[0093] The system information collecting unit 102 requests the system operation data from the system 2 to be evaluated (step S903) and receives the system operation data from the system 2 to be evaluated (step S904). The dashed line 911 including steps S903 and S904 may be executed based on step S900, or may be executed by the occurrence of an information collection trigger in FIG. 4 (step S400). When executed by the occurrence of an information collection trigger (step S400), the system information collecting unit 102 reads out the system operation data stored in the system information collecting unit 102. In addition, both the system operation data acquired by the occurrence of an information collection trigger (step S400) and the data acquired by the dashed line 911 based on step S900 may be used.

[0094] The system information collecting unit 102 returns the system operation data of the evaluation target system 2 to the availability evaluation condition generating unit 112 as operation data of the normal system (step S905).

[0095] When the availability evaluation condition generating unit 112 acquires the operation data of the normal system, it extracts the system operation data related to the availability condition requested in step S900, and converts it so that it can be used for analysis (step S906). For example, in the example of acquiring operation data using the log described in step S902, the availability evaluation condition generating unit 112 extracts items related to the availability condition requested from the log, and converts them into structured data.

[0096] The availability evaluation condition generating unit 112 extracts conditions for a normal system to be satisfied from the extracted system operation data (step S907). Specifically, for example, the availability evaluation condition generating unit 112 extracts conditions for the evaluation target system 2 to satisfy the availability based on the extracted system operation data. Methods for extracting conditions for satisfying the availability include a method of selecting corresponding items by comparing with general normal system operation items listed in advance, and a method of extracting conditions by converting the system operation into analyzable structured data.

[0097] Next, the availability evaluation condition generating unit 112 saves the data generated in step S907 (step S908). As a result, the availability evaluation condition to be transmitted in S1105 in Fig. 11, which will be described later, is prepared in advance. Finally, the availability evaluation condition generating unit 112 returns the results up to step S908 to the core system operation API interface 101 (step S909), and transmits them to the source of the generation request for the availability evaluation condition list 701 (step S910).

[0098] <Procedure for generating model operation data 702> 10 is a sequence diagram showing an example of a procedure in which the action module group 113 generates the model operation data 702. The procedure is shown below. First, the core system operation API interface 101 receives a generation request for the model operation data 702 (step S1000). Upon receiving the generation request, the core system operation API interface 101 transmits the generation request to the action module group 113 (step S1001).

[0099] Next, the action module group 113 requests the security digital twin model 700 required for model generation from the security digital twin model generation unit 111 (step S1002). When the security digital twin model generation unit 111 receives the model transmission request in step S1002, it transmits the security digital twin model 700 to the action module group 113 (step S1003).

[0100] When the action module group 113 receives the security digital twin model 700 and the request to generate the model operation data 702 in step S1003, it generates the model operation data 702 (step S1004).

[0101] Finally, the action module group 113 transmits the model operation data 702 of step S1004 to the core system operation API interface 101 (step S1005), and transmits the model operation data 702 to the sender of the generation request for the model operation data 702 (step S1006).

[0102] <Simulation execution processing procedure in the security digital twin core system 100> 11 is a sequence diagram showing an example of the procedure until a simulation is executed in the security digital twin core system 100. The procedure will be described below. First, the core system operation API interface 101 receives a simulation execution command 704 (step S1100). The core system operation API interface 101 transmits the received simulation execution command 704 to the simulation execution unit 114 (step S1101).

[0103] Next, the simulation execution unit 114 transmits a model acquisition request to the security digital twin model generation unit 111 (step S1102). Upon receiving the model acquisition request, the security digital twin model generation unit 111 transmits the security digital twin model 700 to the simulation execution unit 114 (step S1103).

[0104] Furthermore, the simulation execution unit 114 transmits a condition list acquisition request to the availability evaluation condition generation unit 112 (step S1104). Upon receiving the condition list acquisition request, the availability evaluation condition generation unit 112 transmits the availability evaluation condition list 701 to the simulation execution unit 114 (step S1106).

[0105] Furthermore, the simulation execution unit 114 transmits a model operation data acquisition request to the action module group 113 (step S1106). Upon receiving the model operation data acquisition request, the action module group 113 transmits the model operation data 702 to the simulation execution unit 114 (step S1107).

[0106] The processing steps in the security digital twin model generation unit 111, the availability evaluation condition generation unit 112, and the action module group 113 have already been described with reference to Figures 8 and 10. At this time, steps S800 and S1000, which are the initial requests in Figures 8 and 10, may be executed simultaneously with step S1100.

[0107] In this case, responses to requests to acquire the security digital twin model 700, availability evaluation condition list 701, and model operation data 702 will wait for completion of model generation requested by steps S800 and S1000. Also, for the three combinations of steps S1102 to S1103, steps S1104 to S1105, and steps S1106 to S1107, step numbers are assigned for convenience, but they may be acquired asynchronously, or the order of the combinations may be changed.

[0108] After completing acquisition of the security digital twin model 700, the availability evaluation condition list 701, and the model operation data 702, the simulation execution unit 114 executes a simulation (step S1108) based on a simulation execution command (step S1100).

[0109] When the execution of step S1108 is completed, the simulation execution unit 114 transmits the simulation result 705 to the evaluation / control system function group 120 and the core system operation API interface 101 (step S1109). Note that steps S1110 and S1111 executed by the evaluation / control system function group 120 will be described in FIG. 12 and subsequent figures.

[0110] Finally, the core system operation API interface 101 transmits the received simulation result 705 to the source of the simulation execution command 704 (step S1112).

[0111] <Data transmission / reception relationship related to the evaluation / control system function group 120> 12 is an explanatory diagram showing an example of the data transmission / reception relationship related to the evaluation / control function group 120 in the security digital twin core system 100. Each function and its relationship will be described below.

[0112] The simulation function group 110 transmits the simulation result 705 to the core system operation API interface 101 , the first detection unit 121 and the second detection unit 122 .

[0113] When model operation data 702 related to a simulated attack is included in the model operation data 702 generated by the action module group 113, the first detection unit 121 detects the model operation data 702 related to the simulated attack from the simulation result 705. The first detection unit 121 sends the detected model operation data 702 related to the simulated attack as a simulated attack result 1201 to the core system operation API interface 101 and the security countermeasure comprehensive evaluation unit 123.

[0114] The second detection unit 122 detects an availability evaluation result 1202 in the simulation performed by the simulation execution unit 114 based on the availability evaluation condition list 701 .

[0115] The second detection unit 122 sends the detected availability evaluation result 1202 to the core system operation API interface 101 and the system automatic application determination unit 124. Furthermore, if the model operation data 702 generated by the action module group 113 includes a model operation related to a simulated attack, and if the model operation data 702 generated by the action module group 113 includes a model operation related to a security measure, the second detection unit 122 also sends the availability evaluation result 1202 to the security measure comprehensive evaluation unit 123.

[0116] When a simulation performed by the simulation function group 110 includes something related to security, the security countermeasures comprehensive evaluation unit 123 evaluates the simulation result 705 from the perspectives of both security and availability. Specifically, for example, the security countermeasures comprehensive evaluation unit 123 judges whether or not the operation planned to be applied to the evaluation target system 2 presents any problems from the perspectives of both security and availability. The security countermeasures comprehensive evaluation unit 123 sends the attack risk evaluation data 1203, which is the evaluation result, to the system automatic application judgment unit 124.

[0117] The system automatic application judgment unit 124 assumes application to the evaluation target system 2 and judges whether the operations and measures in the model operation data 702 issued by the action module group 113 may be automatically applied to the evaluation target system 2 based on the availability evaluation result 1202 and the attack risk evaluation data 1203. Furthermore, when multiple operations have been input, the system automatic application judgment unit 124 compares and considers them to determine which operation is most suitable.

[0118] In the judgment of automatic application, a judgment threshold may be set in advance by the user 4, or an arbitrary judgment technique such as machine learning may be used to make the judgment. In addition, when an automatic judgment cannot be made, the system automatic application judgment unit 124 may request a response from the user 4 regarding the applicability of the measure via the core system operation API interface 101. When actually executing a control command, the system automatic application judgment unit 124 sends a structured control command 1205 to the system control unit 103. The system control unit 103 sets the measures that are determined to be applicable by the control command 1205 to the evaluation target system 2. In addition, regardless of whether automatic application is possible, the system automatic application judgment unit 124 sends the application possibility result and the control command 1204 to the core system operation API interface 101.

[0119] <Procedure for evaluation after simulation and output of the evaluation results> Fig. 13 is a sequence diagram showing an example of various evaluations after a simulation is executed and the output process procedure of the evaluation results within the scope of Fig. 11. The procedure will be explained below. Note that dashed line 1312 is a step that is executed when security-related processing is included in the simulation executed by simulation system function group 110. Also, dashed line 1313 is a step that is executed when dashed line 1312 is not executed.

[0120] 11, the simulation result 705 is finalized (step S1300). After that, the simulation function group 110 transmits the simulation result 705 to the core system operation API interface 101 and the second detection unit 122. If the simulation includes security-related processing, the simulation function group 110 also transmits the simulation result 705 to the first detection unit 121 (step S1301).

[0121] Next, the second detection unit 122 detects an availability evaluation result 1202 in the simulation performed by the simulation execution unit 114 based on the availability evaluation condition list 701 .

[0122] Next, the second detection unit 122 transmits the availability evaluation result 1202 detected in step S1302 to the core system operation API interface 101 (step S1303).

[0123] Next, if the condition of the dashed line 1312 described above is satisfied, the following steps S1304 to S1308 are executed.

[0124] First, the first detection unit 121 detects the model operation data 702 related to the simulated attack (step S1304). Next, the first detection unit 121 transmits the model operation data 702 related to the simulated attack of step S1304 to the core system operation API interface 101 and the security countermeasure comprehensive evaluation unit 123 as the simulated attack result 1201 (step S1305).

[0125] Moreover, the second detection unit 122 transmits the availability evaluation result 1202 to the security countermeasures comprehensive evaluation unit 123 (step S1306).

[0126] When the security countermeasures comprehensive evaluation unit 123 receives the simulated attack results 1201 and the availability evaluation results 1202 in steps S1305 and S1306, it evaluates the operations that were planned to be applied to the evaluation target system 2 in the simulation in terms of both security and availability (step S1307).

[0127] Next, the security countermeasure comprehensive evaluation unit 123 transmits the comprehensive evaluation result of step S1307 to the core system operation API interface 101 and the system automatic application determination unit 124 (step S1308).

[0128] If the condition of dashed line 1312 is not satisfied, as the step of dashed line 1313, the second detection unit 122 transmits the availability evaluation result 1202 transmitted to the core system operation API interface 101 in step S1303 to the system automatic application determination unit 124 (step S1309).

[0129] After the final steps S1308 and S1309 of dashed lines 1312 and 1313 are executed, the system automatic application judgment unit 124 judges whether to automatically apply the system to be evaluated 2 based on the received overall evaluation result (step S1308) and evaluation result (step S1309) (step S1310).

[0130] Finally, the system automatic application judgment unit 124 transmits the automatic application judgment result of step S1310 to the core system operation API interface 101, and if automatic application to the evaluation target system 2 is to be performed, transmits the control command 1205 therefor to the system control unit 103 (step S1311).

[0131] As described above in Figures 1 to 13, the security digital twin 1 makes it possible to realize a CPS that takes into account both security and availability for operations performed on the system 2 under evaluation.

[0132] Below, we will describe an example of implementing a CPS using a security digital twin 1, in which the security risks of the system under evaluation 2 are evaluated, and security measures are planned and implemented without affecting availability.

[0133] <Example of security digital twin model configuration> 14 is a block diagram showing a configuration example of a security digital twin model 700 for the evaluation target system 2. The security digital twin model 700 is data that models a small-scale system in which an information system and a control system are integrated, and specifically, for example, has an external service providing computer 1405 and an internal service providing computer 1410 as model data.

[0134] The external service providing computer 1405 is a computer model that provides Web services to an external customer 1401 and an external customer computer 1400 used by the external customer 1401. The internal service providing computer 1410 is a computer model that provides Web services to an internal employee 1409 and an employee OA computer 1408 used by the employee 1409.

[0135] In addition, the security digital twin model 700 is connected to a control network 1414 via a control device monitoring and operation computer 1407 connected to an information network 1411. The security digital twin model 700 has a PLC (Programmable Logic Controller) 1412 that controls the control device, and a control device 1413 controlled by the PLC 1412. The PLC 1412 and the control device 1413 are connected to the control network 1414.

[0136] Additionally, the security digital twin model 700 has, as model data, a firewall 1403 and a WAF (Web Application Firewall) 1404 at the connection surface with the Internet 1402. The security digital twin model 700 also has, as model data, an in-house network router 1406 at the boundary between the Internet 1402 and an in-house information network 1411.

[0137] That is, with the Internet 1402 as the boundary, the firewall 1403, WAF 1403, external service providing computer 1405, internal network router 1406, control device monitoring and operation computer 1407, employee OA computer, employee 1409, internal service providing computer 1410, information network 1411, PLC 1412, control device 1413, and control network 1414 are model data existing within the internal network. On the other hand, the external customer computer 1400 and customer 1401 are model data existing outside the internal network, with the Internet 1402 as the boundary.

[0138] Below, we will explain the process in which security digital twin 1 evaluates the presence or absence of vulnerabilities in the evaluation target system 2 based on a security risk assessment using security digital twin model 700, and if vulnerabilities are found, evaluates countermeasures from both the security and availability perspectives and plans appropriate countermeasures.

[0139] In the first embodiment, it is assumed that there is a vulnerability in the external service providing computer 1405 and the internal service providing computer 1410. Specifically, it is assumed that there is a vulnerability that allows arbitrary commands to be executed in the external service providing computer 1405 and the internal service providing computer 1410 by exploiting "ShellShock", a vulnerability in Bash, a command line operation application installed in the external service providing computer 1405 and the internal service providing computer 1410, via CGI (Common Gateway Interface), which is one of the functions required for executing a Web application. It is known that this vulnerability is executable if the Web server (the external service providing computer 1405 and the internal service providing computer 1410 in this example) can be accessed from a Web browser.

[0140] 14, the components 1400-1414 excluding the customer 1401 and employee 1409 are expressed as they are as the security digital twin model 700. At this time, various information constituting the components 1400-1414 (excluding the customer 1401 and employee 1409) is recorded in the security digital twin model 700. Hereinafter, the components 1400-1414 (excluding the customer 1401 and employee 1409) are referred to as "nodes."

[0141] The recorded information includes, for example, the type and vendor of the hardware, and if the node is an information device, the operating system, its version, installed software and its version, and IP address.

[0142] <Node information table> 15 is an explanatory diagram showing an example of a node information table. The node information table 1500 is a data table in which information recorded for each node is expressed in a tabular format. The node information table 1500 is stored in the storage device 202 of the computer 200 operating as the security digital twin 1.

[0143] The node information table 1500 has, as fields, for example, a node 1501, a Bash version 1502, and a CGI validity 1503. In addition to these, information related to vulnerabilities may also be present as a field.

[0144] Node 1501 uniquely identifies components 1400 to 1414 (excluding customer 1401 and employee 1409). Bash version 1502 is the version number of Bash installed in node 1501. CGI validity 1503 is a flag indicating whether CGI is enabled or not, with "Yes" indicating enabled and "No" indicating disabled.

[0145] In the example of FIG. 14, by referring to the node information table 1500, it can be seen that the Bash version 1502 of both the external service providing computer 1405 and the internal service providing computer 1410 is "4.2", and that CGI is "Yes", indicating that it is enabled.

[0146] <Vulnerability Information Table> 16 is an explanatory diagram showing an example of a vulnerability information table. The vulnerability information table 1600 is a data table showing, in tabular form, some examples of vulnerability information held by an action module that generates simulated attacks among the action module group 113. The vulnerability information table 1600 is stored in the storage device 202 of the computer 200 that operates as the security digital twin 1.

[0147] As an example, the vulnerability information table 1600 stores vulnerability information related to the above-mentioned Bash vulnerability "ShellShock." Specifically, for example, the vulnerability information table 1600 has fields such as a CVE (Common Vulnerabilities and Exposures) number 1601, a vulnerability name 1602, a score 1603, a target 1604, a target version 1605, and a security risk 1606. A combination of values ​​of the fields 1601 to 1606 in the same row defines one piece of vulnerability information.

[0148] CVE number 1601 is a number that uniquely identifies a vulnerability. Vulnerability name 1602 is a name given to the vulnerability identified by CVE number 1601. Score 1603 is data that quantifies the impact of the vulnerability on evaluation target system 2 on a scale of 0 to 10. A smaller value of score 1603 indicates a smaller impact on evaluation target system 2, and a larger value indicates a greater impact.

[0149] Target 1604 is the name of the application in which the vulnerability identified by CVE number 1601 exists. Target version 1605 is the version of the application in which the vulnerability identified by CVE number 1601 exists. Security risk 1606 is a statement explaining what kind of security risk the vulnerability identified by CVE number 1601 poses. In FIG. 16, vulnerability information is stored for CVE numbers 1601 "CVE-2014-6271" and "CVE-2014-7169" and vulnerability name 1602 "ShellShock."

[0150] <Availability evaluation condition list 701> 17 is an explanatory diagram showing an example of the availability evaluation condition list 701. The availability evaluation condition list 701 is information that specifies the availability evaluation conditions, and is stored in the storage device 202 of the computer 200 that operates as the security digital twin 1.

[0151] The availability evaluation condition list 701 specifies an evaluation target node 1701, an availability evaluation item 1702, a violation allowable time 1703, and a violation allowable exception 1704. The evaluation target node 1701 specifies a node that is to be evaluated for availability in the evaluation target system 2. In the first embodiment, the external service providing computer 1405 and the in-house service providing computer 1410 are the evaluation target nodes 1701.

[0152] The availability evaluation item 1702 specifies what and how to evaluate the node to be evaluated 1701. The violation tolerance time 1703 specifies the time during which the node to be evaluated 1701 is permitted to not satisfy the availability evaluation item 1702. The violation tolerance exception 1704 specifies the condition during which the node to be evaluated 1701 is permitted to not satisfy the availability evaluation item 1702.

[0153] The availability evaluation condition list 701 prescribes that for the external service providing computer 1405, the computer 1405 and the Web services running thereon are not permitted to be stopped except for maintenance that has been notified in advance.

[0154] Similarly, the availability evaluation condition list 701 specifies that, for the in-house service providing computer 1410, the computer 1410 and the Web services running on it are permitted to be stopped during notified maintenance periods, outside business hours on business days, and outside business days, and that even in other cases, a stoppage is permitted for a maximum of 10 minutes.

[0155] <Example of an attack using model manipulation data 702> Next, an example of an attack using model operation data 702 generated by an action module that generates a simulated attack among the action module group 113 will be described with reference to FIGS.

[0156] Fig. 18 is an explanatory diagram showing a first example of an attack by model operation data 702 on the evaluation target system 2 using the security digital twin model 700 shown in Fig. 14. In Fig. 18, an attacker 1800 and an attacker computer 1801 are model data that exist outside the in-house network, with the Internet 1402 as the boundary.

[0157] In the first attack example, an attacker 1800 uses an attacker computer 1801 to launch an attack on an external service providing computer 1405 via the Internet 1402 (path 1802), infiltrates an internal information network 1411 by executing arbitrary code (path 1803), operates a PLC 1412 via a control device monitoring / operation computer 1407 (path 1804), and executes unauthorized commands on a control device 1413 (path 1805), causing a fatal failure in the control device 1413.

[0158] These paths 1802 to 1805 are model operation data 702 that indicate the attack path of the simulated attack, and by providing a simulated attack going through paths 1802 to 1805 to the security digital twin 1 and running a simulation, the results of the simulated attack if the paths 1802 to 1805 are followed are detected by the first detection unit 121.

[0159] Fig. 19 is an explanatory diagram showing a second example of an attack by model operation data 702 on the evaluation target system 2 using the security digital twin model 700 shown in Fig. 14. In Fig. 19, an attacker 1800 and an attacker computer 1801 are model data that exist outside the in-house network, with the Internet 1402 as the boundary.

[0160] In the second attack example, an attacker 1800 uses an attacker computer 1801 to launch a simulated attack on an external service providing computer 1405 via the Internet 1402 (path 1900), causing a fatal failure in the external service providing computer 1405 and halting its service.

[0161] This path 1900 is the model operation data 702 regarding the simulated attack, and by applying a simulated attack through path 1900 to the security digital twin 1 and running a simulation, the first detection unit 121 detects the results of the simulated attack if path 1900 is passed.

[0162] Fig. 20 is an explanatory diagram showing a third example of an attack by model operation data 702 on the evaluation target system 2 using the security digital twin model 700 shown in Fig. 14. In Fig. 20, an attacker 1800 and an attacker computer 1801 are model data that exist inside the in-house network, with the Internet 1402 as the boundary.

[0163] In the third attack example, an attacker 1800 connects an attacker computer 1801 to an in-house information network 1411 by any means, and infiltrates and attacks an external service providing computer 1405 via the in-house information network 1411 and the in-house network router 1406 (path 2000), causing a fatal failure in the external service providing computer 1405 and stopping its service.

[0164] This path 2000 is model operation data 702 related to the simulated attack, and by applying a simulated attack through path 2000 to the security digital twin 1 and running a simulation, the first detection unit 121 detects the results of the simulated attack if path 2000 is passed.

[0165] Fig. 21 is an explanatory diagram showing a fourth example of an attack by model operation data 702 on the evaluation target system 2 using the security digital twin model 700 shown in Fig. 14. In the fourth example of an attack, an attacker 1800 connects an attacker computer 1801 to an in-house information network 1411 by any method, and executes an attack on the in-house service providing computer 1410 via the in-house information network 1411 (path 2100), causing a fatal fault in the in-house service providing computer 1410 and halting its service.

[0166] This path 2100 is the model operation data 702 regarding the simulated attack, and by applying a simulated attack through the path 2100 to the security digital twin 1 and running a simulation, the first detection unit 121 detects the results of the simulated attack if the path 2100 is passed.

[0167] <Security Measures Model Operation List> 22 is an explanatory diagram showing an example of a security countermeasures model operation list 2200. The security countermeasures model operation list 2200 is data showing security countermeasure examples in a table format, generated by an action module that performs model operations related to security countermeasures among the action module group 113.

[0168] The security countermeasure model operation list 2200 specifies a countermeasure type 2201, an execution process 2202, a process execution target 2203, and a remark 2204. The countermeasure type 2201 specifies the type of security countermeasure for the model operation data 702 indicating the above-mentioned simulated attack. In the first embodiment, for example, three types of countermeasures α, β, and γ are specified as security countermeasures for the model operation data 702.

[0169] The execution process 2202 specifies the process to be executed on the security digital twin model 700 as the security measure specified by the measure type 2201. The process execution target 2203 specifies the node to which the execution process 2202 is applied as the security measure specified by the measure type 2201. The remarks 2204 specify an event that occurs as a result of the execution process 2202.

[0170] In the security measure model operation list 2200, measure α is a security measure that applies a patch to correct Bash vulnerability to the external service providing computer and the external service providing computer in the actual evaluation target system 2, and performs an operation of restarting them. It is also found that measure α requires restarting the external service providing computer and the external service providing computer in the evaluation target system 2, which is the measure type 2201, and that this operation takes 10 minutes.

[0171] Moreover, measure β is a security measure that applies rules to prevent exploitation of Bash vulnerabilities to the WAF in the evaluation target system 2. And measure γ does not perform any operation.

[0172] The security digital twin model 700 of the evaluation target system 2 shown in Fig. 14, the availability evaluation condition list 701 shown in Fig. 17, the model operation data 702 for performing the four simulated attacks shown in Fig. 18 to Fig. 21, and the model operation data 702 for performing the three types of security countermeasures shown in Fig. 22 are transmitted to the simulation execution unit 114. Using this received data, the simulation execution unit 114 executes a simulation showing the behavior of the countermeasures, attacks, and defenses related to the evaluation target system 2 (step S1108).

[0173] The simulation execution unit 114 applies the model operation data 702 generated by the action module group 113 to the security digital twin model 700 and acquires its behavior. Specifically, for example, in the first embodiment, when the measures α, β, and γ shown in Fig. 22 are applied to the security digital twin model 700, the simulation execution unit 114 acquires the behavior of the component elements of the security digital twin model 700 when the four simulated attacks shown in Figs. 18 to 21 are applied to the security digital twin model 700, and the success or failure of the simulated attacks (simulated attack results) shown in Figs. 18 to 21. The simulation results for each of the measures α to γ ​​will be specifically described below.

[0174] <Simulation results> 23 is an explanatory diagram showing a simulation result when the measure α is applied. The measure α is a security measure for removing vulnerability by applying a patch to the external service providing computer 1405 and the internal service providing computer 1410.

[0175] Defense 2300 in which a patch has been applied to the external service providing computer 1405 indicates that the attacker 1800 and the attacker computer 1801 have failed to intrude into the external service providing computer 1405. Defense 2301 in which a patch has been applied to the internal service providing computer 1410 indicates that the attacker 1800 and the attacker computer 1801 have failed to intrude into the internal service providing computer 1410. In other words, all the simulated attacks shown in Figures 18 to 21 have failed.

[0176] A behavior list 2302 is data in tabular form showing the state of the node to be evaluated 1701 when a countermeasure α is applied. A behavior 2303 is the operation of the node to be evaluated 1701 when a simulated attack is received with the countermeasure α applied. An execution time 2304 is the time required to execute the behavior 2303. A cause 2305 is the event that caused the behavior 2303.

[0177] In the case of measure α, it is specified in the execution process 2202 of the security measure model operation list 2200 that when measure α is applied, a reboot is executed as behavior 2303 with an execution time 2304 of 10 minutes. Therefore, in the external service providing computer 1405 and the internal service providing computer 1410, a reboot with a required time of 10 minutes occurred with application of measure α as the cause 2305.

[0178] Fig. 24 is an explanatory diagram showing the simulation results when measure β is applied. Measure β is a security measure applied to the WAF 1404. As a result, due to the defense 2400 of the WAF 1404 to which measure β is applied, an intrusion attempt by an attacker 1800 and an attacker computer 1801 using a simulated attack from outside the company shown by paths 1802 and 1900 failed. This failure corresponds to Fig. 18 and Fig. 19. However, the simulated attacks from inside the company shown by paths 2000 and 2100 were not defended against, indicating that they were successful.

[0179] The behavior list 2401 is data showing, in tabular form, the state of the node to be evaluated 1701 when the countermeasure β is applied. The impact of the success of the simulated attacks from within the company shown by paths 2000 and 2100 indicates that the external service providing computer 1405 and the internal service providing computer 1410 stopped due to the simulated attack from an internal attacker 1800, as shown in behavior 2303. There was no stoppage caused by the application of the countermeasure 2305.

[0180] Fig. 25 is an explanatory diagram showing the simulation results when measure γ is applied. Measure γ is a security measure that "does not take measures", so the initial situation is left as it is. As a result, as shown in Fig. 25, all the simulated attacks described in Figs. 18 to 21 were successful.

[0181] The behavior list 2500 is data showing in table form the state of the node to be evaluated 1701 when the countermeasure γ is applied. The behavior 2303 of the node to be evaluated 1701 was stopped due to simulated attacks from internal and external attackers 1800. Note that there was no stop due to the application of the countermeasure as the cause 2305, because no special operation was performed as a security measure.

[0182] The simulation execution unit 114 transmits the behavior lists 2302, 2401, and 2500 as the simulation results 705 to the evaluation / control system function group 120 (step S1109).

[0183] In the evaluation / control system function group 120, the first detection unit 121 judges the success or failure of the simulated attack and the extent of its influence based on the model operation data 702 shown in Figures 27 to 29. The first detection unit 121 judges the success or failure of the simulated attack based on whether or not the simulated attack has reached the computer model targeted by the simulated attack via the paths 1802 to 1805, 1900, 2000, and 2100 shown in Figures 18 to 21. If at least one path has been reached, the simulated attack has been successful, and if no path has been reached, the simulated attack has failed.

[0184] The first detection unit 121 judges the extent of the influence based on the computer model into which the attacker 1800 has invaded. For example, in the case of a simulated attack using the model operation data 702 in Fig. 18, if the attacker 1800 starts the simulated attack from the attacker computer 1801 and reaches the control device 1413 that is the target of the simulated attack, the simulated attack is successful, and the extent of the influence in this case is the external service providing computer 1405, the control device monitoring and operation computer 1407, the PLC 1412, and the control device 1413. The results of this simulated attack have already been described with reference to Figs. 27 to 29.

[0185] Next, the second detection unit 122 evaluates the behavior lists 2302, 2401, and 2500 shown in Figures 27 to 29 using the availability evaluation condition list 701 shown in Figure 17, and detects the impact of each of the measures α, β, and γ and the simulated attack on availability as the availability evaluation result.

[0186] <Example of availability evaluation results> 26 is an explanatory diagram showing an example of detection of the availability evaluation result of measure α by the second detection unit 122. The availability evaluation result list 2600 of measure α is data in which pass / fail / cause 2601 for measure α is added to the availability evaluation condition list 701. Pass / fail / cause 2601 includes "o" or "x" indicating pass / fail, and cause 2305. "o" for pass / fail indicates pass, i.e., compliance with availability evaluation item 1702 (availability exists). "x" for pass / fail indicates fail, i.e., violation of availability evaluation item 1702 (no availability).

[0187] For the external service providing computer 1405, the cause 2305 in the behavior list 2302 indicating that the measure α has been applied is recorded in the pass / fail / cause 2601 in the availability evaluation result list 2600. Furthermore, as a result of the application of the measure α, the 10 minutes of the execution time 2304 of the restart, which is the behavior 2303 in the behavior list 2302, violates the availability evaluation item 1702 and the violation allowable time 1703 in the availability evaluation condition list 701 (the violation allowable exception 1704 is not applied either), so the pass / fail is determined to be "X".

[0188] On the other hand, for the in-house service providing computer 1410, cause 2305 in behavior list 2302 indicating that measure α has been applied is recorded in pass / fail / cause 2601 in availability evaluation result list 2600. Also, by applying measure α, the 10 minutes of execution time 2304 of restart, which is behavior 2303 in behavior list 2302, complies with availability evaluation item 1702 and violation allowable time 1703 in availability evaluation condition list 701, so pass / fail is determined to be "◯".

[0189] 27 is an explanatory diagram showing an example of detection of the availability evaluation result of measure β by the second detection unit 122. The availability evaluation result list 2700 of measure β is data in which pass / fail / cause 2601 for measure β is added to the availability evaluation condition list 701.

[0190] As shown in the behavior list 2401, the behavior 2303 of both the external service providing computer 1405 and the internal service providing computer 1410 is "stopped" due to the simulated attack from within the company as the cause 2305. Since the "stopped" behavior 2303 violates the availability evaluation item 1702 and the violation allowable time 1703 of the availability evaluation condition list 701 (the power has not been turned on for 0 seconds or more) (violation allowable exception 1704 is not applied either), the pass / fail result is determined to be "X".

[0191] 28 is an explanatory diagram showing an example of detection of the availability evaluation result of measure γ by the second detection unit 122. The availability evaluation result list 2800 of measure γ is data in which pass / fail / cause 2601 for measure γ is added to the availability evaluation condition list 701.

[0192] As shown in the behavior list 2500, the behavior 2303 of both the external service providing computer 1405 and the internal service providing computer 1410 is "stopped" due to the simulated attacks from inside and outside the company as the cause 2305. Since the "stopped" behavior 2303 violates the availability evaluation item 1702 and the violation allowable time 1703 of the availability evaluation condition list 701 (the power has not been turned on for 0 seconds or more) (violation allowable exception 1704 is not applied either), the pass / fail result is determined to be "X".

[0193] <Overall evaluation results> Fig. 29 is an explanatory diagram showing an example of a comprehensive evaluation result. The comprehensive evaluation result 2900 is data generated by the security countermeasure comprehensive evaluation unit 123 executing the security / availability comprehensive evaluation (step S1307) as shown in Fig. 13, and is transmitted to the system automatic application determination unit 124.

[0194] The overall evaluation result 2900 has a countermeasure type 2201, an evaluation item 2902, and a target-specific evaluation result 2903. The evaluation item 2902 has availability (countermeasure application), availability (attack execution), defense success (~ outside the company), and defense success (~ inside the company). The target-specific evaluation result 2903 is stored separately for the external server (external service providing computer 1405) and the internal server (internal service providing computer 1410).

[0195] Availability (countermeasure application) is an item in which the security countermeasure comprehensive evaluation unit 123 evaluates whether the node to be evaluated 1701 can continue to operate when a security countermeasure specified by the countermeasure type 2201 is applied to the node to be evaluated 1701. Specifically, for example, this is an item in which the effect on the availability of the system to be evaluated 2 is evaluated by the action module group 113 executing (i.e., applying to the security digital twin model 700) the security countermeasure of the countermeasure type 2201 shown in Fig. 22.

[0196] When the target-specific evaluation result 2903 is “◯”, it indicates that the measure indicated in the measure type 2201 complies with the availability evaluation item 1702 in the availability evaluation condition list 701. On the other hand, when the target-specific evaluation result 2903 is “×”, it indicates that the security measure indicated in the measure type 2201 violates the availability evaluation item 1702 in the availability evaluation condition list 701.

[0197] An example will be given of the availability evaluation result list 2600. When the node to be evaluated 1701 is the external service providing computer 1405, the pass / fail / cause 2601 in the availability evaluation item 1702 is all "X". Therefore, the target-specific evaluation result 2903 of the external service providing computer 1405 will also be "X", indicating no availability.

[0198] Availability (attack execution) is an item in which the security measures comprehensive evaluation unit 123 refers to the results of the simulated attack detected by the first detection unit 121 and evaluates what impact a successful simulated attack had on the availability of the system 2 to be evaluated when security measures are applied.

[0199] For example, when security measures are applied, the external service providing computer 1405 and the internal service providing computer 1410, which are the processing execution targets 2203, apply a patch and reboot as the execution processing 2202, and it takes 10 minutes for the internal service providing computer 1410 to reboot the execution processing 2202.

[0200] 18 to 21 are successful against the evaluation target system 2 with security measures implemented, the availability of the evaluation target system 2 is not impaired so long as all the availability evaluation items 1702 in the availability evaluation condition list 701 are complied with. In this case, the target-specific evaluation results 2903 of both the external service providing computer 1405 and the internal service providing computer 1410 will be "◯", indicating success.

[0201] 18 to 21 are successful against the evaluation target system 2 with security measures implemented, the availability of the evaluation target system 2 will be impaired if any one of the availability evaluation items 1702 in the availability evaluation condition list 701 is violated. In this case, the target-specific evaluation results 2903 of both the external service providing computer 1405 and the internal service providing computer 1410 will be "X", indicating failure.

[0202] For example, when the availability evaluation result list 2600 for countermeasure α is obtained, if the node to be evaluated 1701 is the external service providing computer 1405, even if countermeasure α is applied, the pass / fail result in the pass / fail cause 2601 is "X", that is, since the availability evaluation item 1702 has been violated, the security countermeasures comprehensive evaluation unit 123 determines the target-specific evaluation result 2903 to be "X".

[0203] On the other hand, if the node to be evaluated 1701 is the in-house service providing computer 1410, then in the pass / fail / cause 2601, the measure α has been applied and the pass / fail result is “O”, that is, the availability evaluation item 1702 has been complied with, so the security measure comprehensive evaluation unit 123 determines the target-specific evaluation result 2903 to be “O”.

[0204] Defense success (~outside the company) is an item for evaluating whether or not the external service providing computer 1405 and the internal service providing computer 1410 were able to defend against a simulated attack from outside the company detected by the first detection unit 121 when the security countermeasure specified by the countermeasure type 2201 was applied. The simulated attack from outside the company is, for example, a simulated attack that passes through the paths 1802 to 1805 and 1900 shown in Figs. 18 and 19.

[0205] If none of the simulated attacks against the external service providing computer 1405 are successful, that is, if the external service providing computer 1405 is defended against all paths 1802 to 1805, 1900 of the simulated attacks, no failure will occur in the external service providing computer 1405, and the target-specific evaluation result 2903 of the external service providing computer 1405 will be ``O'', indicating successful defense.

[0206] 18 and 19 do not reach the in-house service providing computer 1410, so that the in-house service providing computer 1410 is not physically subjected to the simulated attack. Therefore, the target-specific evaluation result 2903 of the in-house service providing computer 1410 becomes “no attack possible”.

[0207] Furthermore, if any of these simulated attacks are successful against the external service providing computer 1405, that is, if the external service providing computer 1405 is unable to defend against any of the paths 1802 to 1805, 1900 which indicate simulated attacks, a fault will occur in the external service providing computer 1405, and the target-specific evaluation result 2903 of the external service providing computer 1405 will be "X", indicating a failed defense.

[0208] Defense success (~inside the company) is an item for evaluating whether or not the external service providing computer 1405 and the internal service providing computer 1410 were able to defend against a simulated attack from within the company detected by the first detection unit 121 when the security countermeasure specified by the countermeasure type 2201 was applied. An internal simulated attack is, for example, an attack that passes through the paths 2000 and 2100 shown in Fig. 20 and Fig. 21. In the case of an internal simulated attack, the attacker includes a malicious employee.

[0209] If none of the simulated attacks against the in-house service providing computer 1410 are successful, in other words, if the in-house service providing computer 1410 is defended against all paths 2000, 2100 of the simulated attacks, no failure occurs in the in-house service providing computer 1410, and therefore the target-specific evaluation result 2903 of the in-house service providing computer 1410 will be "o" indicating successful defense. Similarly, if none of the simulated attacks against the external service providing computer 1405 are successful, the target-specific evaluation result 2903 of the external service providing computer 1405 will be "o" indicating successful defense.

[0210] Furthermore, if any of these simulated attacks against the in-house service providing computer 1410 is successful, in other words, if the in-house service providing computer 1410 fails to defend against even one of the paths 2000, 2100 indicating the simulated attacks, a fault will occur in the in-house service providing computer 1410, and the target-specific evaluation result 2903 of the in-house service providing computer 1410 will be "X" indicating a defense failure. Similarly, if all of these simulated attacks against the external service providing computer 1405 are successful, the target-specific evaluation result 2903 of the external service providing computer 1405 will be "X" indicating a defense failure.

[0211] On the other hand, if the path 2100 indicating the simulated attack in Fig. 21 is not detected, the simulated attack does not reach the in-house service providing computer 1410, and therefore the in-house service providing computer 1410 is not physically subjected to the simulated attack. Therefore, the target-specific evaluation result 2903 of the in-house service providing computer 1410 is "no attack". Similarly, if the path 2000 indicating the simulated attack in Fig. 20 is not detected, the simulated attack does not reach the external service providing computer 1405, and therefore the external service providing computer 1405 is not physically subjected to the simulated attack. Therefore, the target-specific evaluation result 2903 of the external service providing computer 1405 is "no attack".

[0212] As shown in FIG. 29, for the in-house service providing computer 1410, it can be seen that measure α is optimal because application of measure α has no impact on the availability of the system 2 under evaluation and can defend against all simulated attacks.

[0213] As for the external service providing computer 1405, it can be seen that the application of measure α does not satisfy the availability conditions of the evaluation target system 2, and that the application of measure β satisfies the availability conditions of the evaluation target system 2, but allows attacks from within the company, which may affect the availability. Also, it can be seen that the attack risk is high for measure γ, which does not implement any measures, and that there is an impact on the availability of the evaluation target system 2 due to simulated attacks.

[0214] The system automatic application determination unit 124 determines whether or not the security countermeasure can be automatically applied to the evaluation target system 2 based on the overall evaluation result 2900. Specifically, for example, for the in-house service providing computer 1410, if the evaluation items 2902 are all "o" or "attack-impossible" for each security countermeasure, the system automatic application determination unit 124 determines that the security countermeasure can be automatically applied. Similarly, for the external service providing computer 1405, if the evaluation items 2902 are all "o" or "attack-impossible" for each security countermeasure, the system automatic application determination unit 124 determines that the security countermeasure can be automatically applied. Also, for both the in-house service providing computer 1410 and the external service providing computer 1405, if the evaluation items 2902 are all "o" or "attack-impossible" for each security countermeasure, the system automatic application determination unit 124 may determine that the security countermeasure can be automatically applied.

[0215] For example, for the in-house service providing computer 1410, it is determined that the operation of measure α can be automatically applied (the target-specific evaluation result 2903 is "◯" and "attack not possible"), and the corresponding control is executed for the evaluation target system 2. For the external service providing computer 1405, the availability of the evaluation item 2902 is "X", so it depends on the setting made by the user 4 for the security digital twin 1. As an example of a setting, the system automatic application judgment unit 124 may determine that the risk of an attack from within the company is low because the defense success (~inside the company) for measure α is "◯", and then automatically apply measure β, and ask the user 4 for a judgment on the application of measure α.

[0216] In this way, the security digital twin 1 automatically determines the security risk of the evaluation target system 2. Then, the security digital twin 1 generates the countermeasures as a CPS and determines the degree to which the security risk is reduced by the countermeasures. Furthermore, the security digital twin 1 also determines the impact on the availability of the evaluation target system 2. This enables the security digital twin 1 to set the optimal countermeasures for the evaluation target system 2.

[0217] The benefit of using security digital twin 1 is that not only security risk assessments but also availability assessments of security measures, which have been performed manually up until now, can be performed within security digital twin 1. In this case, security digital twin 1 may output security risk assessments and availability assessments by comparing the results when they have been performed manually up until now with the results when they are automatically determined by security digital twin 1.

[0218] Furthermore, the security digital twin 1 can automatically apply security measures as is if the availability of the evaluation target system 2 is not affected in determining the availability of the evaluation target system 2. This makes it possible to realize automatic security measures similar to those for information systems in the evaluation target system 2, which includes a control system, while ensuring the availability of the evaluation target system 2.

[0219] Thus, according to the first embodiment, it is possible to provide a CPS that takes both availability and security into consideration. This enables various changes to be made to the system that could not be implemented without going through a costly verification step in the past, and makes it possible to expand the range of CPS that can be provided. In addition, with regard to security, which can be a concern when introducing a CPS, measures can be quickly applied without sacrificing availability. EXAMPLES

[0220] Next, a description will be given of Example 2. In Example 1, the first detection unit 121 detects the simulated attack result, and the second detection unit 122 detects the availability evaluation result, but in Example 2, the first detection unit 121 detects the value of a first parameter from the evaluation target system 2, and the second detection unit 122 provides the detected value of the first parameter to the security digital twin model 700 to execute a simulation, and detects the calculated value of a second parameter from the simulation result. Note that in Example 2, the differences from Example 1 will be mainly described, so that the same components as in Example 1 are given the same reference numerals and their description will be omitted.

[0221] <Security system configuration> 30 is a diagram illustrating a configuration example of a security system according to Example 2. In FIG. 30, a business efficiency improvement system 3001 corresponds to an external system or service 5.

[0222] The evaluation target system 2 in the second embodiment is a control system, and includes a management server 3003 that manages the control system, a PLC 3004 that issues commands to a control device group 3006, and the control device group 3006. The evaluation target system 2 is linked to the management server 3003 via the Internet 3002 using a business efficiency improvement system 3001 built on a cloud service 3000 for the purpose of improving business efficiency, and a mechanism for optimizing the operation of the control device group 3006 is introduced.

[0223] In this mechanism, the security digital twin 1 is used for the purpose of verifying the availability of operation requests from the business efficiency system 3001. The control device sensor 3005 is an IoT device installed by the security digital twin 1 to collect additional information on the control device group 3006.

[0224] <Operation range table> 31 is an explanatory diagram showing an example of an operating range table. The operating range table 3100 is a data table showing the normal operating range of parameter A in a control device constituting the control device group 3006, and is stored in the storage device 202. The operating range table 3100 has fields such as load 3101 on the control device and normal operating range 3102 of parameter A.

[0225] The normal operating range 3102 is not the manufacturer's specification of the control device. Specifically, for example, it is the knowledge of an on-site worker that, in actual behavior, when a value x of load 3101 is applied to the control device, the value y of parameter A falls within the normal operating range 3102. It is known that this phenomenon can be reproduced by simulating the operation of the control device on a computer when the value x of load 3101, which is parameter B, is appropriately input.

[0226] However, the relationship between the load 3101 and the normal operating range 3102 shown in the operating range table 3100 is not a specification of the control device, and therefore is not set as a value constraint in the business efficiency improvement system 3001. In addition, the management server 3003 and the PLC 3004 do not measure the value x of the load 3101, and therefore do not have an error processing mechanism that uses the value x shown in Fig. 31 as a constraint. At this time, the security digital twin 1 verifies the value x of the load 3101 before an operation is executed from the business efficiency improvement system 3001 on the control device group 3006, and only the value x appropriate for the current load 3101 is applied to the control device group 3006.

[0227] <Verification of parameter changes> Fig. 32 is a sequence diagram showing an example of a verification process procedure for a parameter change. Fig. 32 shows a procedure for verifying a parameter change instruction sent from the business efficiency improvement system 3001 using a security digital twin. The procedure will be described below.

[0228] First, the business efficiency system 3001 transmits a change request for parameter A to the security digital twin 1 or the management server 3003 (step S3200). At this time, when the change request for parameter A is transmitted to the management server 3003, the management server 3003 inquires of the security digital twin 1 whether or not the change request for parameter A can be executed (step S3201).

[0229] Next, as part of generating the security digital twin 1, the security digital twin 1 checks the value x of the current load 3101 of the control device via the sensor 3005 for the control device (step S3202). Hereinafter, the value x of the current load 3101 of the control device is referred to as the detected value x.

[0230] Next, the security digital twin 1 gives the detected value x obtained in step S3202 to the security digital twin model 700 that models the evaluation target system 2, executes a simulation, and checks the normal operation of the control device group 3006 (step S3203). Specifically, for example, when the detected value x is given, the security digital twin 1 determines whether the value y of parameter A (hereinafter referred to as the calculated value y) in the security digital twin model 700 is within the normal operation range 3102.

[0231] More specifically, for example, if the detected value x is a load 3101 where α < x ≤ β, and the calculated value y of parameter A in the security digital twin model 700 is within the normal operation range 3102 indicated by a < y ≤ b, it is determined that the control device group 3006 is operating normally. If it is outside the normal operation range 3102 indicated by a < y ≤ b, it is determined that the control device group 3006 is not operating normally.

[0232] If the security digital twin 1 can confirm the normal operation of the control device group 3006, it instructs the management server 3003 to execute the change of parameter A (step S3204), and the PLC 3004 is instructed to change the parameter A. If the security digital twin 1 cannot confirm the normal operation of the control device group 3006, it does not instruct the management server 3003 to execute the change of parameter A.

[0233] Thereafter, the security digital twin 1 transmits the change result of parameter A (calculated value y) to the business efficiency improvement system 3001 (step S3205). At this time, if step S3200 was executed via the management server 3003, the transmission of the change result of parameter A (calculated value y) is also executed via the management server 3003.

[0234] <Availability evaluation result list> 33 is an explanatory diagram showing an example of the availability evaluation result list in the embodiment 2. In the embodiment 2, the system automatic applicability determining unit 124 determines that there is no problem with availability (passes) if it is confirmed in the availability evaluation result list 3300 that the control device group 3006 operates normally in the simulation, in other words, if the availability evaluation items 1702 are complied with within the violation allowable time 1703.

[0235] In the second embodiment, the behavior of each control device in the control device group 3006 is defined as a security digital twin model 700, and in the action module group 113, a change to parameter A instructed by the business efficiency improvement system 3001 is defined as model operation data 702.

[0236] In the security digital twin model 700, the current load of the control device group 3006 acquired via the control device sensor 3005 and the system information collection unit 102 is set.

[0237] In this state, the simulation execution unit 114 simulates the behavior of the control device group 3006. If the result of the simulation shows that the control device group 3006, which is the node to be evaluated 1701, operates normally, that is, if the calculated value y of parameter A falls within the normal operation range 3102 corresponding to the load 3101 in Fig. 31, it means that the availability evaluation item 1702 is complied with within the violation allowable time 1703, and the system automatic application judgment unit 124 judges that there is no problem with the availability of the control device group 3006, which is the node to be evaluated 1701 (passes).

[0238] As a result, the system automatic application determination unit 124 applies the change to the calculated value y of the parameter A from the business efficiency improvement system 3001 to the control device group 3006 that is the component device of the evaluation target system 2 .

[0239] As a result, it is possible to evaluate the security and availability of operations of CPS other than security measures via the security digital twin 1. This solves the problem that, until now, it was not possible to know the impact of the operation on the evaluation target system 2, and the range of operations by the CPS was limited.

[0240] The present invention is not limited to the above-described embodiments, and includes various modified examples and equivalent configurations within the spirit of the appended claims. 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 having all of the configurations described. Also, a part of the configuration of one embodiment may be replaced with a configuration of another embodiment. Also, a configuration of another embodiment may be added to a configuration of one embodiment. Also, a part of the configuration of each embodiment may be added, deleted, or replaced with another configuration.

[0241] Furthermore, each of the aforementioned configurations, functions, processing units, processing means, etc. may be realized in hardware, for example by designing some or all of them as an integrated circuit, or may be realized in software by a processor interpreting and executing a program that realizes each function.

[0242] Information such as programs, tables, files, etc. that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a recording medium such as an IC (Integrated Circuit) card, an SD card, or a DVD (Digital Versatile Disc).

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

[0244] 1. Security Digital Twin 2. Evaluated System 3. User computer system 4 User 100 Security Digital Twin Core System 101 Core system operation API interface 102 System Information Collection Department 103 System control section 104 Management Function Department 105 Automation Systems 110 Simulation Functions 111 Security Digital Twin Model Generation Department 112 Availability evaluation condition generation unit 113 Action Modules 114 Simulation Execution Unit 120 Control System Function Group 121 First detection unit 122 Second detection unit 123 Security Measures Comprehensive Evaluation Department 124 System automatic application decision part 200 calculator 201 Processor 202 Storage Devices 700 Security Digital Twin Model 701 Availability Evaluation Condition List 702 Model Operation Data 1201 Simulation Attack Results 1202 Availability Evaluation Results 1203 Attack Risk Assessment Data 1500 Node Information Table 1600 Vulnerability Information Table 1801 Attacker's Computer 2200 Security Measures Model Operation List 2302,2401,2500 Behavior List 2600,2700,2800 Availability evaluation result list 2900 Overall evaluation result 3100 Operating Range Table

Claims

1. a storage unit that stores association information that associates a first range in which a value of a first parameter related to an evaluation object can be taken with a second range in which a value of a second parameter related to the evaluation object can be taken when the value of the first parameter is within the first range; a first detection unit that detects a value of a first parameter from the evaluation object; a second detection unit that detects a calculated value of the second parameter from a simulation result in which a detection value of the first parameter detected by the first detection unit is applied to an evaluation object model obtained by modeling the evaluation object; a determination unit that determines whether or not the detected value is within the first range and the calculated value detected by the second detection unit is within the second range by referring to the related information; an output unit that outputs a result of the determination by the determination unit; An analytical device comprising:

2. The analysis device according to claim 1 , a setting unit that sets the calculated value to the evaluation target when the determination result indicates that the detected value is within the first range; An analytical device comprising:

3. An analysis method performed by an analysis device having a processor that executes a program and a storage device that stores the program, comprising: the storage device stores association information associating a first range in which a value of a first parameter related to an evaluation object can be taken with a second range in which a value of a second parameter related to the evaluation object can be taken when the value of the first parameter is within the first range; The processor, a first detection process for detecting a value of a first parameter from the evaluation object; a second detection process for detecting a calculated value of the second parameter from a simulation result in which a detection value of the first parameter detected by the first detection process is applied to an evaluation object model obtained by modeling the evaluation object; a determination process for determining whether or not the detected value is within the first range and the calculated value detected by the second detection process is within the second range by referring to the related information; an output process for outputting a result of the determination process; An analysis method comprising the steps of:

Images