JP7574170B2 - State analysis device and state estimation method - Google Patents

Description

The present invention relates to a state analysis device and a state estimation method.

Damage caused by cyber attacks targeting organizations such as companies and government agencies is becoming more serious. Recently, these cyber attacks have expanded their targets to include social infrastructure-related systems, energy control systems for electricity and gas, and industrial control systems such as factory production lines. The impact on real society of an industrial control system would be significant if it were to go down, so measures against cyber attacks targeting industrial control systems are becoming increasingly important.

For example, Patent Document 1 describes a security management method for cyber attacks targeting industrial control systems, in which data obtained from sensors and actuators such as those of a gas turbine is classified into normal and abnormal patterns, and cyber attacks on the gas turbine are detected based on the data obtained from the sensors and actuators. It also describes a method of searching for parameters suitable for the monitored object from a data repository and customizing the searched parameters in order to set the parameters used for detection.

Furthermore, Non-Patent Document 1 describes a method of modeling a normal state using a process mining method that uses as input a device log acquired when a programmable logic controller (PLC) controls a reactor, and then using a conformance check method to obtain an index showing the normality of the device log output by the PLC based on the generated model, and detecting cyber attacks using the obtained index.

US Patent No. 2020/0169574

“Anomaly detection for industrial control systems using Process Mining”, David Myers et.al, Queensland University of Technology (QUT), Computers & Security 78 (2018), pp.103-125

One method for monitoring cyberattacks targeting industrial control systems is to collect and analyze information indicating failures, process abnormalities, and warnings issued by devices that make up the industrial control system (hereinafter referred to as "alerts"). However, this method requires humans, such as monitors, to distinguish whether an issued alert is due to a device failure or process abnormality, or due to a cyberattack, which imposes a large human burden.

As a method for reducing the human burden of monitoring, for example, the techniques described in Patent Document 1 and Non-Patent Document 1 can be used. However, in Patent Document 1, knowledge and experience are required to manually set up the design of parameters (DOE: Design Of Experiments parameters) for monitoring the behavior. In Non-Patent Document 1, the state estimation model for the normal state is expressed by a Petri net, but the difficulty of learning Petri nets is relatively high, and sufficient knowledge and experience are required of the monitor, etc.

The present invention has been made in light of this background, and aims to provide a state analysis device and a state estimation method that can easily and accurately detect the state of an industrial control system.

To achieve the above object, one aspect of the present invention is an information processing device that estimates the state of an industrial control system that is configured with multiple assets, which has a processor and memory, stores a state estimation model that includes information indicating one or more scenarios of state transitions that may occur in the industrial control system, and compares an alert sequence in which alerts issued from the assets are arranged in chronological order with the scenario of the state estimation model, thereby determining and outputting an index indicating the commonality between the alert sequence and the scenario.

Other problems and solutions disclosed in this application will be made clear in the detailed description of the invention and the drawings.

The present invention makes it possible to easily and accurately detect the state of an industrial control system.

1 is an example of a state analyzer. This is an example of a function provided in the state analyzer. 1 is an example of an information processing device used to realize a state analysis device. 1 is an example of a graph. 13 is an example of a place management table. 13 is an example of a transition management table. 1 is an example of an asset class table. 13 is an example of an alert class table. 2 is an example of a state estimation model. 11 is a flowchart illustrating an example of a state estimation model generation process. 13 is an example of a base model setting screen. 13 is an example of a state estimation model setting screen. 13 is an example of a state estimation model setting screen. 11 is a flowchart illustrating an example of a state estimation process. 13 is a diagram illustrating an example of a process for converting an alert sequence into a transition. 11 is a diagram illustrating an example of a process for matching an alert sequence with a scenario. FIG. 11 is a diagram illustrating an example of a process for matching an alert sequence with a scenario. FIG. 13 is an example of a state estimation result. 13 is an example of a state estimation result. 11 is a flowchart illustrating an example of a state estimation model update process. 11 is a diagram illustrating an example of a process for analyzing trends in the degree of progress and the degree of alarm occurrence. FIG. 11 is a diagram illustrating an example of a process for analyzing trends in the degree of progress and the degree of alarm occurrence. FIG. 13 is an example of a state estimation model update screen. This is an example of a failure scenario. This is an example of a failure scenario. This is an example of a failure scenario. This is an example of an attack scenario. This is an example of an attack scenario. This is an example of an attack scenario.

The following describes in detail an embodiment of the present invention with reference to the drawings. Note that the following description and drawings are merely examples for explaining the present invention, and have been omitted or simplified as appropriate for clarity of explanation. The present invention can also be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

In the following explanation, the letter "S" before a symbol indicates a processing step. In the following explanation, various information may be explained using expressions such as "table", but the various information may be expressed in other data structures. In addition, an "XX table" may be referred to as "XX information" to indicate independence from the data structure. In addition, when explaining identification information, expressions such as "identification information", "identifier", "name", "ID", and "number" are used, but these are interchangeable.

1 shows a schematic configuration (system flow diagram) of a state analysis device 100 which is an information processing device described as one embodiment. As shown in the figure, the state analysis device 100 includes an industrial control system (ICS (Industrial Control System), hereinafter referred to as "ICS2") and the state analysis device 100 which is an information processing device (computer) communicably connected to the ICS2 via a communication network 5.

ICS2 includes, for example, social infrastructure-related systems such as electricity, gas, water, and railways; control systems for energy-related facilities such as electricity and gas; monitoring and control systems in factories and plants for the petroleum, chemical, steel, automobile, transportation equipment, precision machinery, food, pharmaceuticals, and building management; IT systems used in production lines and processing lines; IoT (Internet of Things) systems; and IIoT (Industrial IoT) systems.

The state analysis device 100 monitors the physical/logical operating (operating) state (hereinafter collectively referred to as "state") of the ICS2, generates information on the operating state of the ICS2 and information on the state of the ICS2, such as the presence or absence of security intrusion, and provides this information to the monitor or operator of the ICS2. The state analysis device 100 analyzes the state of the ICS2 based on an alert sequence, which is data in which information indicating abnormalities or warnings (hereinafter referred to as "alerts") issued by the devices (hereinafter referred to as "assets") that constitute the ICS2 due to failures or process abnormalities is arranged in chronological order. The assets are, for example, sensors, actuators, controllers, safety instrumentation systems, control servers, engineering workstations, monitoring and control servers, data historians, transmission servers, etc.

The communication network 5 is a wired or wireless communication network, such as a local area network (LAN), a wide area network (WAN), the Internet, various public wireless communication networks, a dedicated line, etc. The communication network 5 may be a communication infrastructure that communicatively connects the assets constituting the ICS 2. The state analysis device 100 may be a component of the ICS 2.

Figure 2A is a block diagram explaining the main functions of the state analysis device 100. As shown in the figure, the state analysis device 100 has the functions of a memory unit 110, an alert receiving unit 120, a state estimation unit 130, an estimation result output unit 140, a base model generating unit 150, a state estimation model generating unit 160, and a state estimation model updating unit 170.

Of the above functions, the storage unit 110 stores an alert sequence 111, a state estimation model 112, a state estimation result 113, and a base model 114.

The alert receiving unit 120 receives alerts issued (output) from the devices and equipment that constitute the ICS2, arranges the received alerts in chronological order, and manages them in the memory unit 110 as an alert sequence 111. The alert receiving unit 120 also inputs the generated alert sequence to the state estimation unit 130.

The state estimation unit 130 estimates the state of ICS2 by comparing the alert sequence input from the alert receiving unit 120 with a state estimation model 112 that includes information indicating one or more scenarios that indicate state transitions that can occur in ICS2, and by finding an index indicating commonality (consistency, similarity) between the alert sequence and the scenario, and manages the estimated result (hereinafter referred to as the "state estimation result") in the storage unit 110 as the state estimation result 113. The state estimation unit 130 also presents the state estimation result to a user such as a supervisor or an operator via a user interface. The state estimation unit 130 re-estimates the state of ICS2, for example, every time the alert sequence 111 is updated.

The base model generation unit 150 generates a base model, which is a general-purpose model that serves as the base (template) for the state estimation model 112, while interacting with the user via a user interface, and manages the generated base model in the storage unit 110 as the base model 114. For example, if ICS2 is a hydroelectric power plant system, the base model generation unit 150 generates a base model 114 based on a scenario of state transitions leading up to a failure for assets that are shared or general-purposely equipped by the hydroelectric power plant systems in the Kanto region and the hydroelectric power plant systems in the Kansai region.

The state estimation model generation unit 160 generates the state estimation model 112 based on the base model 114 and information about ICS2.

The state estimation model update unit 170 updates the state estimation model 112 based on the state estimation result 113. Based on the state estimation result 113, the state estimation model update unit 170 identifies scenarios in which deviations in state estimation by the state estimation model 112 occur and identifies the locations of deviation. The state estimation model update unit 170 also generates a proposed revision of the scenario by interactive processing with the user via a user interface. The state estimation model update unit 170 also presents the state estimation results 113 before and after the scenario is revised by the proposed revision to the user in a comparable state, and if the user accepts the proposed revision, updates the state estimation model 112 based on the proposed revision.

FIG. 2B is an example of an information processing device used to realize the state analysis device 100. The illustrated information processing device 10 includes a processor 11, a main storage device 12 (memory), an auxiliary storage device 13, an input device 14, an output device 15, and a communication device 16. Examples of the information processing device 10 include a personal computer, an office computer, a server device, a smartphone, a tablet, a general-purpose machine (mainframe), etc.

The information processing device 10 may be realized, in whole or in part, by using virtual information processing resources provided by using virtualization technology, process space separation technology, or the like, such as a virtual server provided by a cloud system. Furthermore, all or in part of the functions provided by the information processing device 10 may be realized, for example, by a service provided by a cloud system via an API (Application Programming Interface) or the like. Furthermore, all or in part of the functions provided by the information processing device 10 may be realized, for example, by a service provided by a cloud system via an API (Application Programming Interface), or the like. Furthermore, all or in part of the functions provided by the information processing device 10 may be realized, for example, by a service provided by a service provider such as SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure
This may be realized by using the Service as a Service, etc.

The processor 11 may be, for example, a central processing unit (CPU), a micro processing unit (MPU), a graphics processing unit (GPU), a field programmable gate array (FPGA), or the like.
It is composed of a gate array, an application specific integrated circuit (ASIC), an artificial intelligence (AI) chip, etc.

The main memory device 12 is a device for storing programs and data, and is, for example, a ROM (Read Only Memory).
The main memory 12 may include a random access memory (RAM), a random access memory (RAM), a non-volatile memory (NVRAM), etc. The functions realized in each component of the security management system 1 are realized by the processor 11 reading and executing a program stored in the main memory 12.

The auxiliary storage device 13 is, for example, a solid state drive (SSD), a hard disk drive, an optical storage device (CD (Compact Disc), DVD (Digital Versatile Disc), etc.), a storage system, an IC card, a read/write device for a non-transient recording medium such as an SD card or an optical recording medium, a non-transient storage area of a cloud server, etc. Programs and data can be read into the auxiliary storage device 13 from other information processing devices equipped with non-transient recording media or non-transient storage devices via a recording medium reader or a communication device 16. The programs and data stored (stored) in the auxiliary storage device 13 are read into the main storage device 12 as needed.

The input device 14 is an interface that accepts information input from the outside, and is, for example, a keyboard, a mouse, a touch panel, a card reader, a pen-input tablet, a voice input device, etc.

The output device 15 is an interface that outputs various information such as the progress of processing and the results of processing to the outside. The output device 15 is, for example, a display device (liquid crystal monitor, LCD (Liquid Crystal Display), graphic card, etc.) that visualizes the various information described above, a device that converts the various information described above into audio (audio output device (speaker, etc.)), or a device that converts the various information described above into text (printer, etc.). Note that, for example, the information processing device 10 may be configured to input and output information to and from other devices via the communication device 16.

The input device 14 and the output device 15 constitute a user interface that realizes interactive processing with the user (accepting information, providing information, etc.).

The communication device 16 is a device that realizes communication with other devices. The communication device 16 is a wired or wireless communication interface that realizes communication with other devices that comply with a specific communication protocol via the communication network 5, and is, for example, a NIC (Network Interface Card), a wireless communication module, a USB module, etc.

The information processing device 10 may be equipped with, for example, an operating system, a file system, a DBMS (DataBase Management System) (relational database, NoSQL, etc.), a KVS (Key-Value Store), etc.

Next, we will explain the base model 114. Note that the state estimation model 112 has a similar configuration to the base model 114.

The base model 114 is information (data) that expresses one or more scenarios that represent the state of the ICS 2 in a format that can be mechanically processed by an information processing device or the like. In the following, a case where the above format is a Petri net will be described as an example. However, the above format is not necessarily limited. A Petri net is a bipartite digraph (hereinafter, "graph") having two types of nodes (places and transitions).
(Places are nodes represented by circles and represent conditions. Transitions are nodes represented by bars or boxes and represent events. Arcs (arrows) connecting them represent relationships between conditions or events.

The base model 114 includes information on a graph representing a scenario, a place management table 50 in which information about the places that define the scenario is managed, a transition management table 60, an asset class table 70, and an alert class table 80.

Figures 3A to 3C and 4A to 4B are specific examples of each of the above information. Each piece of information will be explained in turn below.

Figure 3A is an example of a graph 40 of the base model 114. As shown in the figure, the illustrated base model 114 includes two scenarios, scenario X41 and scenario Y42. Of these, scenario X41 has a structure in which places "P_X0", "P_X1", "P_X2", and "P_X3" indicating the state of ICS2 and transitions "T_X1", "T_X2", and "T_X3" indicating the conditions of state transition are connected by arcs. Also, scenario Y42 has a structure in which places "P_Y0", "P_Y1", "P_Y2", and "P_Y3" defining the state of ICS2 from a different perspective than scenario X41 and transitions "T_Y1", "T_Y1'", "T_Y2", "T_Y3", and "T_Y3'" indicating the conditions of state transition are connected by arcs.

In the illustrated scenario X41, the state transitions linearly from "P_X0" to "P_X3", whereas the illustrated scenario Y42 includes a structure in which a transition from "P_Y0" to "P_Y1" occurs only when either transition "T_Y1" or "T_Y1'" is satisfied (the OR condition is satisfied). In addition, scenario Y42 includes a structure in which a transition from "P_Y2" to "P_Y3" occurs when both transitions "T_Y3" and "T_Y3'" are satisfied (the AND condition is satisfied).

Figure 3B shows an example of a place management table 50 for the base model 114. As shown in the figure, the place management table 50 is made up of one or more entries (records) having each of the following items: scenario 51, place 52, and progress level 53.

Of the above items, progress level 53 stores the progress level, which is an index showing the degree of progress of the state of ICS2. In the example of scenario X41 shown in the figure, the progress level is set to "0" for place "P_X0", "1/3" for "P_X1", "2/3" for "P_X2", and "3/3=1" for place "P_X3".

Figure 3C shows an example transition management table 60 of the base model 114. As shown in the figure, the example transition management table 60 is composed of one or more entries (records) having each of the following items: scenario 61, transition 62, asset class 63, and alert class 64.

Of the above items, asset class 63 stores an asset class that is an index for categorizing assets of ICS2. Alert class 64 stores an alert class that is an index for categorizing alerts. The entry for each transition 62 in the transition management table 60 indicates that when an alert of the corresponding alert class 64 is issued from the asset class 63, the transition 62 of the corresponding entry is ignited.

In this way, in the transition management table 60, each scenario is defined (expressed) by asset classes that categorize assets and alert classes that categorize alerts. Therefore, by appropriately allocating assets to asset classes and alerts to alert classes, the state analysis device 100 of this embodiment can be widely applied to ICS2, which can take a variety of forms. In addition, if the configuration or functions of the ICS2 change, it can be flexibly adapted, making it easier to operate the ICS2.

Figure 4A shows an example of an asset class table for the base model 114. As shown in the figure, the asset class table 70 is made up of one or more entries (records) each having a subclass 71, an asset class 72, and a description 73.

Of the above items, subclass 71 stores the subclass (physical subclass, logical subclass) that is the classification unit of the asset class. Asset class 72 stores the asset class ID that is the identifier of the asset class that belongs to the subclass. In this example, asset classes "ASC1" to "ASC5" are defined as physical subclasses, and asset classes "ASC6" to "ASC11" are defined as logical subclasses. Description 73 stores information that describes each asset class.

In this way, by dividing asset classes into physical subclasses and logical subclasses, i.e. by defining asset classes from a physical perspective and a logical perspective, it is possible to appropriately define scenarios that conform to the characteristics of state changes for each perspective, thereby improving the accuracy of state estimation of ICS2 by the state analysis device 100.

Figure 4B is an example of an alert class table for the base model 114. As shown in the figure, the alert class table 80 is composed of one or more entries (records) each consisting of a combination of a subclass 81, an asset class 82, an alert class 83, and a description 84.

Of the above items, subclass 81 stores a "physical subclass" or a "logical subclass." Asset class 82 stores an asset class ID. Alert class 83 stores an alert class ID, which is an identifier for the alert class. Description 84 stores a description of the alert class. In this example, asset classes 82 "ALC1" to "ALC27" are associated with the physical subclasses of subclass 81, and asset classes 82 "ALC28" to "ALC45" are associated with the logical subclasses of subclass 81.

In this way, by dividing the alert class into physical subclasses and logical subclasses, i.e. by defining the alert class from a physical perspective and a logical perspective, it is possible to appropriately define a scenario that conforms to the characteristics of state changes for each perspective, thereby improving the accuracy of state estimation of ICS2 by the state analysis device 100.

Next, we will explain the state estimation model 112 that is generated based on the base model 114 illustrated above.

Figure 5 is an example of a state estimation model 112. The state estimation model 112 is generated for each ICS2. The illustrated state estimation model 112 is composed of one or more entries (records) having the following items: asset 91, alert 92, asset class 93, and alert class 94.

Of the above items, asset 91 stores an asset ID that is an identifier of an asset that constitutes the ISC2 system. Alert 92 stores an alert ID that is an identifier of an alert output by the asset. Asset class 93 stores an asset class ID of an asset class corresponding to the asset. Alert class 94 stores an alert class ID of an alert class corresponding to the asset class.

Figure 6 is a flowchart explaining the process (hereinafter referred to as "state estimation model generation process S600") in which the state estimation model generation unit 160 generates the state estimation model 112 while performing dialogue processing with a user such as a supervisor or an operator via a user interface. Below, the state estimation model generation process S600 will be explained with reference to the same figure.

First, the user creates a list of the assets of the target ISC2 (S601). For example, if the system has two controllers configured for redundancy due to a multiplexing system, the user creates a list of the assets as separate controllers, such as the first controller and the second controller.

The user then decides whether to use the base model 114 as is to generate the state estimation model 112 without editing it (S602). If the user decides to edit and use the state estimation model 112 (S602: NO), the user edits the base model 114 (S603), and then the process proceeds to both S611 and S621. If the user decides to use the base model 114 as is without editing it (S602: NO), the process proceeds to both S611 and S621.

Figure 7 is an example of a user interface (hereinafter referred to as the "base model setting screen 700") provided by the state analysis device 100 when the user edits the base model 114. As shown in the figure, the base model setting screen 700 includes a scenario list display area 710, a scenario display area 720, a place attribute list display area 730, and a transition attribute list display area 740.

In the scenario list display area 710, the scenarios included in the base model 114 are displayed in a list format. The user can, for example, select one scenario from the scenario list display area 710 and edit it. The user can also, for example, add or delete scenarios by performing a specified operation in the scenario list display area 710.

The scenario display area 720 displays a graph (a graph that visualizes a Petri net) corresponding to the scenario included in the base model 114. The user can easily check the contents of the scenario by referring to the graph in the scenario display area 720. The user can also easily edit the scenario by performing specified operations on the displayed graph.

The place attribute list display area 730 displays a list of places for all scenarios included in the base model 114, and a value indicating the progress of the scenario for each place. For example, the user can easily check the places and the progress in the place attribute list display area 730. The user can also easily edit information about places by performing specified operations in the place attribute list display area 730 while checking the Petri net shown in the scenario display area 720.

The transition attribute list display area 740 displays a list of transitions of all scenarios included in the base model 114, and the asset classes and alert classes corresponding to each transition. The user can easily check the asset classes and alert classes that constitute a transition in the transition attribute list display area 740. The user can also easily edit information related to a transition by performing a predetermined operation in the transition attribute list display area 740 while checking the structure of the Petri net shown in the scenario display area 720.

Returning to FIG. 6, in S611, the user assigns a logical subclass to the asset. Also, in S621, the user assigns a physical subclass to the asset.

Figure 8 shows a user interface (hereinafter referred to as the "state estimation model setting screen 800") provided to the user in both steps S611 and S621. As shown in the figure, the state estimation model setting screen 800 includes an ICS network display area 810, a logical subclass allocation display area 820, and a physical subclass allocation display area 830.

Displays the classification (hereinafter referred to as "level") of the network (hereinafter referred to as the "ICS network") that constitutes ICS2. An example of a level is the "Purdue model" of ISA99. In the "Purdue model," ICSs are classified into "Level 0 (physical process)," "Level 1 (intelligent device)," "Level 2 (control system)," "Level 3 (manufacturing operating system)," and "Level 4 (business logistics system)." In many ICSs, system design is often based on these level classifications. Therefore, users such as supervisors and operators can easily imagine the corresponding assets from the levels displayed in the ICS network display area 810.

In the logical subclass assignment display area 820, the user can configure each level of the ICS network while checking a list of the assets included in each level. In the logical subclass assignment display area 820, the user can assign a logical subclass by setting a "Check" to each asset. Note that each asset can be assigned one or more logical subclasses. The user can also use the logical subclass assignment display area 820 to add or delete assets.

In the physical subclass assignment display area 830, the user can assign a physical subclass to each asset by setting a check mark. Each asset can be assigned one or more physical subclasses. The user can also use the physical subclass assignment display area 830 to add or delete assets.

When assigning logical subclasses and physical subclasses, when the user inputs an asset, the state estimation model generation unit 160 may display candidates for the assignment of the logical subclasses and physical subclasses based on the product name and model of the input asset.

Returning to FIG. 6, in S612, the user identifies the control flow of ICS2. In S613, the user assigns a logical subclass of the alert class. Meanwhile, in S622, the user assigns a physical subclass of the alert class.

Figure 9 is an example of a user interface (hereinafter referred to as the "state estimation model setting screen 900") provided by the state analysis device 100 in each step of S612, S613, and S622. As shown in the figure, the state estimation model setting screen 900 includes an ICS function display area 910, a control flow display area 920, a logical subclass assignment display area 930, and a physical subclass assignment display area 940.

A list of functions provided by the ICS 2 is displayed in the ICS function display area 910. The list of functions provided by the ICS 2 is assigned in advance in a standard manner. In the ICS function display area 910, the user can check the list of functions provided by the ICS 2 and add or delete functions by performing a predetermined operation.

The control flow display area 920 displays a diagram showing the control flow when realizing one function using two or more assets, in the form of a sequence diagram that combines the source, destination, and content of messages. The user uses the control flow display area 920 to set the assets and messages that will realize the function of ICS2 selected in the ICS function display area 910.

In the logical subclass assignment display area 930, the user assigns an alert related to the message entered in the control flow display area 920 to a logical subclass of the alert class. The user uses the logical subclass assignment display area 930 to assign an alert class of a logical subclass to an alert issued by an asset in one control flow.

In the physical subclass assignment display area 940, the user assigns an alert class of the physical subclass to each asset. The user uses the physical subclass assignment display area 940 to assign, for each asset, an alert class of the physical subclass for the alerts that the asset will issue.

When allocating logical and physical subclasses, when a user inputs an alert, the state estimation model generation unit 160 may provide the user with candidates for allocating logical and physical subclasses based on the type and format of the input alert.

Returning to FIG. 6, in S630, the identification of assets, assignment of asset classes, identification of alerts, and assignment of alert classes are completed, and the user saves the results as the state estimation model 112 in the state estimation model 112. This ends the state estimation model generation process S600. As described above, the user can efficiently generate the state estimation model 112 by using the user interface provided by the state analysis device 100.

Figure 10 is a flowchart explaining the process (hereinafter referred to as "state estimation process S1000") in which the state estimation unit 130 estimates the state of ICS2 using the state estimation model 112. Below, the state estimation process S1000 will be explained with reference to the same figure.

The state estimation unit 130 acquires the alert sequence received by the alert receiving unit 120 from ICS2 (S1011).

Next, the state estimation unit 130 assigns an alert sequence ID, which is an identifier for the alert sequence, to the acquired alert sequence (S1012).

Then, the state estimation unit 130 converts each alert constituting the acquired alert sequence into an alert class based on the state estimation model 112, and converts each alert class obtained by the conversion into a transition based on the transition management table 60 (S1013). Note that, when multiple transitions correspond to one alert, the state estimation unit 130 associates the one alert with all the transitions.

FIG. 11 is a diagram for explaining the process from S1011 to S1013. For example, it is assumed that two assets "AS1" and "AS2" have issued alerts. In this case, the state estimation unit 130 imports three alerts "T1", "T2", and "T3" issued between the import start time and the current time as an alert sequence 1111. The import start time refers to a start time that is long enough to determine that one of the scenarios in the alert sequence is occurring. For example, if ICS2 is completely repaired by overhaul, the time when the overhaul is performed is the import start time. Also, for example, if an asset breaks down and is replaced, the time when the asset is replaced is the import start time.

The state estimation unit 130 generates the converted alert sequence 1112 shown in the figure by assigning an alert sequence ID to the alert sequence 1111. The state estimation unit 130 assigns an asset class according to the type of asset to the alert issued by the asset, and assigns an alert class according to the type of alert. The state estimation unit 130 also associates the alert issued by the asset with a corresponding scenario and transition.

Returning to FIG. 10, the state estimation unit 130 then repeatedly executes the processes of S1014 to S1016 for each scenario of the state estimation model 112.

First, in S1015, the state estimation unit 130 compares the converted alert sequence 1112 with the scenario defined in the state estimation model 112.

In S1016, the state estimation unit 130 obtains the progress and the alert level as the results of S1015. Here, the progress level is the value of the progress level 53 shown in the place management table 50. The alert level is an index that indicates the degree to which the alert sequence occurs in the order defined in the scenario. Note that, for example, the "fitness value" of "conformance checking," known as process mining, can be used as the alert level.

Figures 12A and 12B are diagrams explaining the processing of S1015 to S1016 in Figure 10. Figure 12A illustrates the firing state of the transitions of each scenario (scenario X41, scenario Y42) at time T1 in Figure 11, and Figure 12B illustrates the firing state of the transitions at time T3 in Figure 11.

In the example of Fig. 12A, transition "T_X1" of scenario X41 is fired, and the token of asset "AS1" that triggered the alert transitions from "P_X0" to "P_X1". Also, transition "T_Y2" of scenario Y42 is fired, and the token of asset "AS1" transitions from "P_Y0" to "P_Y2". In this example, the progress and alert level of asset "AS1" at time T1 are as follows:
[Number 1]
(Progress, Alert Level) of asset "AS1" in scenario X41 = (1/3, 1)
[Number 2]
(Progress, Alert) of asset "AS1" in scenario Y42 = (2/3, 1/2)

In the example of Figure 12B, the transition "T_X2" in scenario X41 is fired, but nothing is fired in scenario Y42, and the token of the asset "AS1" that triggered the alert transitions from "P_X1" to "P_X2." In this example, the progress and alert level of the asset "AS1" at time T3 are as follows:
[Number 3]
(Progress, Alert Level) of asset "AS1" in scenario X41 = (2/3, 1)
[Number 4]
(Progress, Alert) of asset "AS1" in scenario Y42 = (2/3, 1/2)

In this example, at time T3, both scenario X41 and scenario Y30 have the same degree of progress of "2/3", but a comparison of the alarm occurrence rates indicates that the state transition of scenario X41 is more likely to have occurred than the state transition of scenario Y42.

Note that the above example shows the state transition when asset "AS1" is triggered, but the user can know the progress and triggering rate of each asset at each time using a similar method.

Returning to FIG. 10, next, in S1017, the state estimation unit 130 presents a screen (hereinafter referred to as the "estimated result display screen 1300") that lists the matched alert sequence, progress level, and alert level to the user via the user interface.

Figure 13A shows an example of the estimation result display screen 1300 at time T1, and Figure 13B shows an example of the estimation result display screen 1300 at time T3.

As shown in FIG. 13A, the progress and alert level of each of scenarios X41 and Y42 are displayed due to alert "AL1" issued by asset "AS1". Also, as shown in FIG. 13B, the progress and alert level in scenario X41 are updated due to alert "AL3" issued by asset "AS1", and the progress and alert level in scenario Y42 are displayed. Note that if the progress level at each time is the same value, the information may be sorted in ascending or descending order of alert level and displayed. Also, as shown in the figure, the value with the larger alert level (progress, alert level) may be highlighted (displayed with a thick frame in this example).

Returning to FIG. 10, in S1018, the state estimation unit 130 determines whether an event that ends the state estimation process S1000 (e.g., receipt of an end instruction from the user) has occurred. If the above event has not occurred (S1018: NO), the process returns to S1011. If the above event has occurred, the state estimation unit 130 ends the state estimation process S1000.

As described above, the state estimation unit 130 estimates the state of the ICS2 by executing the state estimation process S1000 and presents the estimation result display screen 1300 showing the results to the user, so that the user can easily understand the state occurring in the ICS2 at each time. In addition, the estimation result display screen 1300 displays not only the latest estimation result but also estimation results at past points in time, so that the user can understand the chronological changes in the displayed progress and alarm rate, thereby enabling the user to accurately identify the state of the ICS2. In addition, the user can create a state estimation model 112 suitable for the ICS2 simply by inputting the asset and alert information of the ICS2 in a sequenced manner, thereby reducing the user's burden in monitoring the ICS2.

Figure 14 is a flowchart explaining the process performed by the state estimation model update unit 170 (hereinafter referred to as "state estimation model update process S1400"). Below, the state estimation model update process S1400 will be explained with reference to this figure.

In S1411, the state estimation model update unit 170 accumulates the state estimation result 113 by the state estimation unit 130.

In S1412, the state estimation model update unit 170 analyzes the trends in the progress and alarm occurrence based on the state estimation result 113.

In S1413, the state estimation model update unit 170 determines whether the trend of the alarm occurrence rate has decreased. If the trend of the alarm occurrence rate has not decreased (S1413: NO), the process returns to S1411. If the trend of the alarm occurrence rate has decreased (S1414: YES), the process proceeds to S1414.

Figures 15A and 15B are diagrams explaining the process performed by the state estimation model update unit 170 to analyze the trends in the progress and alarm occurrence rates.

Figure 15A is an example of a state estimation result 113. As shown in the figure, the state estimation result 113 is composed of multiple entries (records) for each alert column, which have the following items: alert column ID 1511, scenario 1512, progress level 1513, and alert level 1514.

The graph shown in FIG. 15B (hereinafter referred to as the "trend analysis graph 1520") is a graph in which values are plotted with the degree of progress on the X-axis and the alert level on the Y-axis. For example, if the progress level progresses while the alert level remains at "1" (plot group indicated by reference symbol 1521), the state estimation model update unit 170 determines that the scenario and the alert sequence match. On the other hand, if the alert level continues to take a value close to "0" as the progress level progresses (plot group indicated by reference symbol 1522), the state estimation model update unit 170 determines that a deviation has occurred between the scenario and the alert sequence. The state estimation model update unit 170 detects that the trend of the alert level has decreased in this way, for example, based on the trend analysis graph 1520.

Returning to FIG. 14, next, in S1414, the state estimation model update unit 170 identifies scenarios in which the trend of alarm occurrence is decreasing.

Next, the state estimation model update unit 170 replays the alert sequence and identifies areas of the scenario that need to be corrected (S1415).

Next, the state estimation model update unit 170 generates a scenario in which the identified correction points have been corrected (hereinafter referred to as the "corrected scenario") (S1416).

Next, the state estimation model update unit 170 uses the alert sequence to simulate the progress and alert occurrence rate in the revised scenario (S1417).

Figure 15C is an example of a user interface (hereinafter referred to as the "state estimation model update screen 1530") provided to the user when processing S1414 to S1417.

As shown in the figure, the state estimation model update screen 1530 is composed of a scenario list display area 1531, a pre-revision scenario display area 1532, and a post-revision scenario display area 1533.

The scenario list display area 1531 displays a list of scenarios that correspond to the case where the trend of the alarm occurrence rate is decreasing in the trend analysis graph 1520 (symbol 1522). The user checks the scenario list display area 1531 to understand the scenarios that are showing a decreasing trend in the alarm occurrence rate.

In the pre-modification scenario display area 1532, the alert sequence is reproduced and a simulation of the ignition of tokens is displayed. The user checks the pre-modification scenario display area 1532 and identifies a place 1541 that is defined in the scenario but has not actually ignited. For example, the user can use the operation menu that is displayed by placing the mouse pointer on place 1541 and right-clicking to delete the place and make a modification to connect the previous and next places.

The revised scenario display area 1533 displays the progress and alert probability of the revised scenario when the alert sequence is reproduced.

14, next, in S1418, the state estimation model update unit 170 receives an input from the user as to whether or not the revised scenario is acceptable. If an input is received from the user indicating that the revised scenario is unacceptable (S1418: NO), the process returns to S1415. If an input is received from the user indicating that the revised scenario is acceptable (S1418: YES), the process proceeds to S1419.

In S1419, the state estimation model update unit 170 updates the state estimation model 112 to the contents of the revised scenario. This completes the state estimation model update process S1400.

In this way, by executing the state estimation model update process S1400, the state analysis device 100 detects that the trend in the alarm rate has decreased, identifies the areas of the scenario that need to be corrected, corrects the scenario through dialogue with the user, and appropriately updates the scenario by simulating the progress and alarm rate in the corrected scenario. Therefore, for example, even a user who does not understand the detailed technical details of the state estimation model 112 can easily grasp that the trend in the alarm rate has decreased, identify the scenario in which the alarm rate has decreased, identify the areas of the scenario that need to be corrected, correct the scenario, and appropriately update the scenario by simulating the corrected scenario.

Next, we will provide an example of the state estimation model 112 and explain in detail how to identify failure scenarios and attack scenarios.

Figures 16A to 16C are examples of scenarios in which equipment fails (hereinafter referred to as "failure scenarios").

Fault scenario 1610 shown in FIG. 16A illustrates a case in which an abnormality progresses in a single device A. Starting from start S, when the transition "abnormal sound alert" is fired, the state transitions to place "wearing out". Also, when the transition "temperature rise alert" is fired, the state transitions to place "temperature rise". Next, when the transition "momentary stoppage alert" is fired a cumulative 10 times, the state transitions to place "momentary stoppage". Next, when the transition "maintenance alert" is fired, the state transitions to place "unavailable". Then, when the transition "abnormal response alert from device A" in device B is fired, the state of device A reaches the final fault G.

Failure scenario 1620 shown in FIG. 16B illustrates a case in which multiple abnormalities progress in the redundant system of ICS2, and illustrates a case in which device A provides redundant communication with communication devices a and b. Starting from start S, when the transition "communication device a alert" is fired, the state transitions to place "communication device a abnormality". Alternatively, when the transition "communication device b alert" is fired, the state transitions to place "communication device b abnormality". Next, when the transition "response abnormality alert from device A" is fired in device B, the state transitions to place "communication abnormality" in device A. Furthermore, when the transition "switch to device C alert" is fired in device B, the state of device A reaches the final failure G.

Failure scenario 1630 shown in FIG. 16C illustrates a case in which, among the components of ICS2, device A to device E, when device A becomes abnormal, the abnormality gradually propagates from device B to device E. Starting from start S, when a transition "abnormal alert" is fired in device A, the state transitions to place "device A abnormal state". Next, when a transition "abnormal alert" is fired in device B, the state transitions to place "device B abnormal state". Next, when a transition "abnormal alert" is fired in device C, the state transitions to place "device C abnormal state". Alternatively, when a transition "abnormal alert" is fired in device D, the state transitions to place "device D abnormal state". Furthermore, when a transition "abnormal alert" is fired in device E, the state transitions to place "device E abnormal state", resulting in a final failure G of the entire system.

By using the above failure scenarios as the state estimation model 112, the state of failure in ICS2 can be estimated based on the state analysis device 100 alert sequence.

Figures 17A and 17B are examples of scenarios in which a cyber attack occurs (hereinafter referred to as "attack scenarios").

Attack scenario 1710 shown in FIG. 17A shows a case where an attack called lateral movement of the cyber kill chain occurs from device A to device C that constitutes ICS2. Starting from start S, when a transition "network connection/disconnection alert" is fired in device A, the state transitions to the place "probed state" of device A. Alternatively, when a similar alert is fired in device B or device C, the state transitions to the place "probed state" for each device. Next, when a transition "CPU load alert" is fired in at least one of device A, device B, and device C, the state transitions to the place "intruded state". Furthermore, when a transition "mode change alert" is fired in at least one of device A, device B, and device C, the state transitions to the place "abnormal operation". Furthermore, when a transition "abnormal alert" is fired in at least one of device A, device B, and device C, the state transitions to the place "abnormal operation" of the final cyber attack.

Attack scenario 1720 shown in FIG. 17B illustrates a case in which device A is infected with ransomware and the hard disk (hereinafter referred to as "HDD") becomes unusable. Starting from start S, when a transition "program startup alert" is fired in device A, the state transitions to place "executed state". Next, when a transition "HDD load alert" is fired, the state transitions to place "HDD encryption state". When a transition "unable to start alert" is further fired, the state transitions to place "unavailable state". Furthermore, when a transition "abnormal response alert from device A" is fired in device B, the state reaches the final cyber attack success G.

Attack scenario 1730 shown in Figure 17C illustrates a case where a command and control attack known as a cyber kill chain is executed. When the transition "external connection/disconnection alert" is fired in the firewall, the state of any of device A, device B, and device C transitions to place "command received state". Next, when the transition "HDD load alert" is fired in any of device A, device B, and device C, the state of each device transitions to place "attack execution state". Furthermore, when the transition "abnormal alert" is fired in any of device A, device B, and device C, the state reaches the final cyber attack success G.

By using these attack scenarios as the state estimation model 112, the state analysis device 100 can estimate the state of ICS2 due to a cyber attack based on the alert sequence.

Although one embodiment of the present invention has been described above, it goes without saying that the present invention is not limited to the above embodiment and can be modified in various ways without departing from the spirit of the invention. For example, the above embodiment has been described in detail to clearly explain the present invention, and is not necessarily limited to having all of the configurations described. In addition, it is possible to add, delete, or replace part of the configuration of the above embodiment with other configurations.

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

Furthermore, the layout of the various functional units, various processing units, and various databases of each information processing device described above is merely an example. The layout of the various functional units, various processing units, and various databases can be changed to an optimal layout in terms of the performance, processing efficiency, communication efficiency, etc. of the hardware and software equipped in these devices.

In addition, the configuration (schema, etc.) of the database that stores the various types of data mentioned above can be flexibly changed from the perspective of efficient use of resources, improved processing efficiency, improved access efficiency, improved search efficiency, etc.

2 ICS (industrial control system), 5 communication network, 40 graph, 41 scenario X, 42 scenario Y, 50 place management table, 60 transition management table, 70 asset class table, 80 alert class table, 100 state analysis device, 110 storage unit, 111 alert string, 112 state estimation model, 113 state estimation result, 114 base model, 120 alert receiving unit, 130 state estimation unit, 140 estimation result output unit, 150 base model generation unit, 160 state estimation model generation unit, 170 state estimation model update unit, S600 state estimation model generation process, 700 base model setting screen, 800 state estimation model setting screen, 900 state estimation model setting screen, S1000 state estimation process, 1310 state estimation result, 1320 state estimation result, S1400
State estimation model update process, 1530 State estimation model update screen

Claims (15)

An information processing device that estimates a state of an industrial control system configured to have a plurality of assets,
A processor and a memory,
storing a state estimation model including information indicative of one or more scenarios of state transitions that may occur in the industrial control system;
By comparing an alert sequence, in which alerts issued from the assets are arranged in chronological order, with the scenario of the state estimation model, an index showing a commonality between the alert sequence and the scenario is obtained and output.
Condition analyzer. The state analyzer according to claim 1 ,
the indicator is at least one of a progress degree, which is an indicator indicating a degree of progress of the state transition, and an alert activation degree, which is an indicator indicating a degree to which the alert sequence is activated in accordance with the order of the scenario;
Condition analyzer. The state analyzer according to claim 2,
providing a user interface for setting the degree of progress in each state of the scenario;
Condition analyzer. The state analyzer according to claim 1 ,
presenting the index for each of the scenarios to a user via a user interface;
Condition analyzer. The state analyzer according to claim 4,
the state estimation model includes a plurality of the scenarios,
Sorting the scenarios according to their commonality with the alert sequence, or highlighting scenarios with a high commonality.
Condition analyzer. The state analyzer according to claim 1 ,
Information associating the assets with asset classes that are classifications of the assets;
Information associating the alert with an alert class, which is a classification of the alert; and
Information associating the scenario with the state transition, the asset class, and the alert class;
Remember,
The indicator is obtained by comparing the alert sequence with the scenario corresponding to a combination of an asset class to which the asset that issued the alert in the alert sequence belongs and an alert class to which the alert belongs.
Condition analyzer. The state analyzer according to claim 1 ,
A base model which is information serving as a template for the state estimation model is stored;
providing a user interface for editing the scenario by editing the base model;
Condition analyzer. The state analyzer according to claim 6,
The scenario is represented by a Petri net, and an asset class is associated with a place, and the asset class and the alert class are associated with a transition.
Condition analyzer. The state analyzer according to claim 1 ,
storing information correlating the alert sequence with the index determined for the alert sequence;
determining a degree of deviation between the information and the scenario in the state estimation model based on a trend of change in the index;
Condition analyzer. The state analyzer according to claim 9,
the indicators are a progress degree, which is an indicator showing a degree of progress of the state, and an alert occurrence degree, which is an indicator showing a degree to which an alert is occurring in accordance with an order defined in the scenario,
determining a degree of deviation based on a degree of change in the alarm rate relative to a change in the progress rate;
Condition analyzer. The state analyzer according to claim 9,
reproducing the change in the index by issuing each alert in the alert sequence in chronological order and tracing the scenario, and identifying the portion of the scenario where the deviation occurs based on the change in the index;
Condition analyzer. The state analyzer according to claim 11,
providing a user interface for presenting the reproduction and correcting the identified portion of the scenario where the deviation occurs;
Condition analyzer. The state analyzer according to claim 12,
issuing each alert in the alert sequence in chronological order and tracing the modified scenario to obtain changes in the indicators and present the changes to the user;
Shape analysis device. A method for estimating a state of an industrial control system having a plurality of assets, comprising:
An information processing device having a processor and a memory,
storing a state estimation model including information indicative of one or more scenarios of state transitions that may occur in the industrial control system;
A step of comparing an alert sequence, in which alerts issued from the assets are arranged in chronological order, with the scenario of the state estimation model, thereby obtaining and outputting an index indicating a commonality between the alert sequence and the scenario;
Execute the condition analysis method. The state analysis method according to claim 14,
The information processing device,
storing information in which the alert sequence and the index determined for the alert sequence are associated with each other;
determining a degree of deviation between the information and the scenario in the state estimation model based on a trend of change in the index;
The condition analysis method further comprises:

Images