Threat response method, program, and threat response system

Abstract

In a threat response method, when it is determined that there is an abnormality in a device being monitored, a playbook to restore the device from an abnormal state to a normal state is executed (S201-S209), and when the playbook is executed, among a first mode that maintains a current operation and a second mode that restricts the functions which the device can use, one mode is set as the operation mode for the device in accordance with the restoration characteristics related to the restoration of the device (S205, S206, S207), and the set operation mode is output (S208).

Description

Threat response method, program, and threat response system

[0001] The present disclosure relates to a threat response method, a program, and a threat response system.

[0002] Patent Document 1 discloses a response procedure generation device that generates a response procedure for an event related to an information system as a playbook.

[0003] Japanese Patent Application Laid-Open No. 2021-082083

[0004] The present disclosure provides a threat response method that can easily reduce the risks associated with the occurrence of abnormalities in devices from the time of a cyber attack until recovery.

[0005] In a threat response method according to one aspect of the present disclosure, when it is determined that an abnormality exists in a monitored device, a playbook is executed to restore the device from an abnormal state to a normal state, and when the playbook is executed, the operating mode of the device is determined to be one of a first mode that maintains the current operation and a second mode that restricts the available functions of the device, depending on the recovery characteristics of the device, and the determined operating mode is output.

[0006] A program according to one aspect of the present disclosure causes one or more processors to execute the threat response method.

[0007] According to one aspect of the present disclosure, a threat response system includes a processor and an output unit. When a monitored device is determined to have an abnormality, the processor executes a playbook for restoring the device from the abnormal state to a normal state. When the playbook is executed, the processor determines an operation mode of the device to one of a first mode that maintains the current operation and a second mode that limits available functions of the device, depending on a recovery characteristic of the device. The output unit outputs the operation mode determined by the processor.

[0008] The present disclosure has the advantage of making it easier to reduce the risks associated with the occurrence of abnormalities in equipment between the time of a cyber attack and the time of recovery.

[0009] FIG. 1 is a block diagram showing an example of an overall configuration including a threat response system according to an embodiment. FIG. 2 is a block diagram showing an example of a functional configuration of an SIEM according to an embodiment. FIG. 3 is a diagram showing an example of an operation log of a device. FIG. 4 is a diagram showing an example of a detection rule. FIG. 5 is a block diagram showing an example of a functional configuration of an SOAR according to an embodiment. FIG. 6 is a diagram showing an example of anomaly determination data. FIG. 7 is a diagram showing an example of a playbook. FIG. 8 is a diagram showing an example of functions included in a workflow. FIG. 9 is a diagram showing an example of recovery characteristics. FIG. 10 is a block diagram showing an example of a functional configuration of a device according to an embodiment. FIG. 11 is a sequence diagram showing an example of operation of an overall configuration including an SOAR according to an embodiment. FIG. 12 is a flowchart showing an example of operation of an SIEM according to an embodiment. FIG. 13 is a flowchart showing an example of operation of an SOAR according to an embodiment. FIG. 14 is a diagram showing an example of a monitoring screen displayed on a display of a monitoring PC according to an embodiment. FIG. 15 is a diagram showing an example of recovery characteristics in a first modified example. FIG. 16 is a flowchart showing an example of operation of an SOAR in the first modified example. FIG. 17 is a diagram showing an example of functions included in a workflow in a second modified example. FIG. 18 is a diagram showing an example of recovery characteristics in the second modified example. Fig. 19 is a flowchart showing an example of operation of SOAR in the second modified example. Fig. 20 is a diagram showing an example of restoration characteristics in the third modified example. Fig. 21 is a flowchart showing an example of operation of SOAR in the third modified example. Fig. 22 is a diagram showing an example of restoration characteristics in the fourth modified example. Fig. 23 is a flowchart showing an example of operation of SOAR in the fourth modified example.

[0010] (Knowledge forming the basis of the present disclosure) In recent years, SIEM (Security Information and Event Management) has become known, which monitors whether an abnormality caused by a cyber-attack on an Internet of Things (IoT) device has occurred by collecting and analyzing operation logs from the IoT device. Also, SOAR (Security Orchestration, Automation and Response) is known, which, when an abnormality caused by a cyber-attack on an IoT device is detected by SIEM, deals with the abnormality by executing a predefined playbook.

[0011] However, there is a problem in that, from the time SOAR executes the playbook and completes all workflows, that is, from the time an IoT device is subjected to a cyber-attack until it is restored, the IoT device remains in a state where it is at risk from the occurrence of an abnormality.

[0012] In view of the above, the present disclosure aims to provide a threat response method, etc. that can easily reduce the risks associated with the occurrence of abnormalities in equipment between the time of a cyber attack and recovery.

[0013] More specifically, in the threat response method according to the first aspect of the present disclosure, when it is determined that an abnormality exists in a monitored device, a playbook is executed to restore the device from an abnormal state to a normal state, and when the playbook is executed, the operating mode of the device is determined to be either a first mode that maintains the current operation or a second mode that limits the available functions of the device, depending on the recovery characteristics of the device, and the determined operating mode is output.

[0014] This makes it possible to reduce the risk to a device by restricting the functions that can be used by the device, for example, when it takes a long time for the device to recover after being subjected to a cyber-attack. This has the advantage of making it easier to reduce the risk associated with the occurrence of abnormalities in the device during the time from the cyber-attack until recovery.

[0015] Also, for example, in the threat response method according to the second aspect of the present disclosure, in the first aspect, in the second mode, only the minimum functions required for the device are available, and other functions are restricted.

[0016] This has the advantage that it is possible to limit the available functions of the equipment as much as possible, thereby making it easier to further reduce the risks associated with abnormalities that may occur in the equipment between the time of a cyber attack and the time of recovery.

[0017] Also, for example, in a threat response method according to a third aspect of the present disclosure, in the first or second aspect, the recovery characteristic indicates the recovery time required to recover the device, and if the recovery time exceeds a threshold, the operating mode is determined to be the second mode.

[0018] This has the advantage that the decision as to whether to restrict the available functions of the equipment on which the playbook is executed is made based on the recovery time of the equipment, making it easier to further reduce the risk associated with the occurrence of abnormalities in the equipment between the time of a cyber attack and recovery.

[0019] Also, for example, in a threat response method according to a fourth aspect of the present disclosure, in the first or second aspect, the recovery characteristics indicate one or more work conditions that affect the recovery work of the equipment, and if the number of work conditions that are satisfied among the one or more work conditions exceeds a threshold, the operating mode is determined to be the second mode.

[0020] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the equipment is made based on the number of operational conditions that affect the time required to recover the equipment on which the playbook is executed.

[0021] Also, for example, in the threat response method according to the fifth aspect of the present disclosure, in the fourth aspect, the one or more work conditions include at least one of the following: the location information of the equipment is unknown; the recovery work includes work at height; and the recovery work includes work that involves danger.

[0022] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the equipment is based on whether or not the work conditions that affect the time required to recover the equipment on which the playbook is executed are met.

[0023] Also, for example, in the threat response method according to the sixth aspect of the present disclosure, in the fourth or fifth aspect, one or more working conditions include the absence of a recovery procedure corresponding to an error code indicating that an abnormality has occurred in the equipment.

[0024] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the equipment is based on whether or not the work conditions that affect the time required to recover the equipment on which the playbook is executed are met.

[0025] Also, for example, in a threat response method relating to a seventh aspect of the present disclosure, in any one of the fourth to sixth aspects, one or more work conditions include the absence of any past cases of recovery work on the equipment.

[0026] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the equipment is based on whether or not the work conditions that affect the time required to recover the equipment on which the playbook is executed are met.

[0027] Also, for example, in a threat response method according to an eighth aspect of the present disclosure, in the third aspect, recovery time is predicted based on the execution time of each of one or more tasks included in a playbook.

[0028] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the device is based on the time required for tasks that affect the time required to recover the device on which the playbook is executed.

[0029] Also, for example, in the threat response method according to the ninth aspect of the present disclosure, in the eighth aspect, the one or more tasks include an approval process by an analyst who analyzes an abnormality in the equipment.

[0030] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the device is based on whether or not the task that affects the time required to recover the device on which the playbook is executed is fulfilled.

[0031] Also, for example, in the threat response method according to the tenth aspect of the present disclosure, in the eighth or ninth aspect, the one or more tasks include offline work on the device.

[0032] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the device is based on whether or not the task that affects the time required to recover the device on which the playbook is executed is fulfilled.

[0033] Also, for example, in a threat response method relating to an eleventh aspect of the present disclosure, in any one of the eighth to tenth aspects, one or more tasks include an approval process by a user of the device or an action by the user on the device.

[0034] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the device is based on whether or not the task that affects the time required to recover the device on which the playbook is executed is fulfilled.

[0035] Also, for example, in the threat response method according to the twelfth aspect of the present disclosure, in the first or second aspect, the recovery characteristics indicate the magnitude of risk posed by the equipment in an abnormal state, and if the magnitude of the risk exceeds a threshold, the operating mode is determined to be the second mode.

[0036] This has the advantage that whether or not to restrict the functions available to the device on which the playbook is executed is determined based on the level of risk posed by the device, making it less likely that excessive function restrictions will be imposed.

[0037] Also, for example, in a threat response method according to a thirteenth aspect of the present disclosure, in the first or second aspect, the recovery characteristics indicate one or more risk conditions possessed by equipment in an abnormal state, and if the number of the one or more risk conditions that satisfy the risk conditions exceeds a threshold, the operating mode is determined to be the second mode.

[0038] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the device is based on the number of risk conditions met by the device on which the playbook is executed.

[0039] Also, for example, in the threat response method according to the fourteenth aspect of the present disclosure, in the thirteenth aspect, the one or more risk conditions include the device having no backup function.

[0040] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the device is based on whether or not the risk conditions that affect the recovery of the device on which the playbook is executed are met.

[0041] Also, for example, in the threat response method according to the fifteenth aspect of the present disclosure, in the thirteenth or fourteenth aspect, the one or more risk conditions include the user of the device having used the device within a specified period of time from the occurrence of the abnormality.

[0042] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the device is based on whether or not the risk conditions that affect the recovery of the device on which the playbook is executed are met.

[0043] Also, for example, in a threat response method relating to a sixteenth aspect of the present disclosure, in any one of the thirteenth to fifteenth aspects, one or more risk conditions include the device being linked to other devices.

[0044] This has the advantage that excessive function restrictions are less likely to be imposed, since the decision as to whether to restrict the available functions of the device is based on whether or not the risk conditions that affect the recovery of the device on which the playbook is executed are met.

[0045] Also, for example, in a threat response method according to a seventeenth aspect of the present disclosure, in any one of the first to sixteenth aspects, the determined operating mode is output by notifying an analyst who analyzes the abnormality in the equipment.

[0046] This has the advantage that the analyst checks before restricting the available functions of the device, making it easier to prevent the available functions of the device from being restricted to an unnecessary extent.

[0047] Also, for example, in a threat response method relating to an 18th aspect of the present disclosure, in any one of the 1st to 16th aspects, an instruction to operate in the determined operating mode is output by being sent to the device.

[0048] This has the advantage that an instruction to operate in the determined operation mode is sent to the device, so that the device can automatically restrict available functions in accordance with the instruction.

[0049] Also, for example, a program according to a nineteenth aspect of the present disclosure causes one or more processors to execute a threat response method according to any one of the first to eighteenth aspects.

[0050] This makes it possible to reduce the risk to a device by restricting the functions that can be used by the device, for example, when it takes a long time for the device to recover after being subjected to a cyber-attack. This has the advantage of making it easier to reduce the risk associated with the occurrence of abnormalities in the device during the time from the cyber-attack until recovery.

[0051] Also, for example, a threat response system according to a twentieth aspect of the present disclosure includes a processing unit and an output unit. When the processing unit determines that a monitored device has an abnormality, it executes a playbook for restoring the device from the abnormal state to a normal state, and when executing the playbook, it determines an operation mode of the device to either a first mode that maintains the current operation or a second mode that limits available functions of the device, depending on recovery characteristics related to the recovery of the device. The output unit outputs the operation mode determined by the processing unit.

[0052] This makes it possible to reduce the risk to a device by restricting the functions that can be used by the device, for example, when it takes a long time for the device to recover after being subjected to a cyber-attack. This has the advantage of making it easier to reduce the risk associated with the occurrence of abnormalities in the device during the time from the cyber-attack until recovery.

[0053] Furthermore, these comprehensive or specific aspects may be realized in a system, an apparatus, a method, an integrated circuit, a computer program, or a non-transitory recording medium such as a computer-readable CD-ROM, or may be realized in any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium.

[0054] Hereinafter, embodiments will be described in detail with reference to the drawings. Note that the embodiments described below are all comprehensive or specific examples. The numerical values, shapes, materials, components, component placement and connection configurations, steps, or step order shown in the following embodiments are merely examples and are not intended to limit the present disclosure. Furthermore, among the components in the following embodiments, components not recited in independent claims will be described as optional components. Note that each figure is a schematic diagram and is not necessarily an exact illustration. Furthermore, in each figure, substantially identical components are assigned the same reference numerals, and duplicated descriptions may be omitted or simplified.

[0055] In the following description, "above the threshold" means including the threshold, i.e., equal to or greater than the threshold. In the following description, "below the threshold" means not including the threshold, i.e., less than the threshold. Note that "above the threshold" does not necessarily have to include the threshold. In this case, "below the threshold" means equal to or less than the threshold.

[0056] (Embodiment) [1. Configuration] A threat response system according to an embodiment will be described below. The threat response system is a system used to monitor whether or not there are any abnormalities due to cyber attacks on devices connected to a network, such as IoT devices. Fig. 1 is a diagram showing an example of the overall configuration including the threat response system according to an embodiment. As shown in Fig. 1, in the embodiment, a threat response system 2 is realized by a SOAR 2 included in an SOC (Security Operation Center) 100.

[0057] The SOC 100 is an organization that monitors, in real time, threats to information systems owned by, for example, individuals or companies. In the embodiment, the SOC 100 monitors, in real time, threats posed by cyberattacks to one or more devices 4 owned by a user P2 in a facility 200 such as a residential facility, an office, or a public facility. In the embodiment, the facility 200 is a residential facility such as a detached house or an apartment building, and the user P2 is a resident of the residential facility.

[0058] In the embodiment, the one or more devices 4 are all IoT devices that are configured to be able to link with other devices via an external network N1 (here, the Internet). More specifically, in the embodiment, the one or more devices 4 include an air conditioner (referred to as "air conditioner" in FIG. 1) 4A, a water heater 4B, and a gas stove 4C.

[0059] In the embodiment, the SOC 100 is equipped with a SIEM 1, a threat response system (SOAR) 2, and a monitoring PC (Personal Computer) 3 used by an analyst P1. That is, in the embodiment, the SIEM 1 and the SOAR 2 are operated on-premises. Note that the SIEM 1 and the SOAR 2 may be configured as a server device or the like and operated using cloud computing technology.

[0060] Analyst P1 is an operator who uses the monitoring PC 3 and analyzes abnormalities in the device 4 using the monitoring PC 3. Specifically, analyst P1 analyzes trends in abnormalities that have occurred in the device 4 and identifies the content of cyber attacks and their impact on the device 4 by checking the results of the abnormality determination for the device 4 by SIEM1. Furthermore, when SOAR2 executes a function that requires an approval process among one or more functions included in a playbook executed by SOAR2, analyst P1 determines whether or not the function may actually be executed. Details of the playbook and one or more functions included in the playbook will be described later.

[0061] 2 is a block diagram showing an example of the functional configuration of the SIEM 1 according to the embodiment. The SIEM 1 includes a processor and a memory, and realizes its functions by the processor executing a program stored in the memory. As shown in FIG. 2, the SIEM 1 includes a log collection unit 11, an anomaly detection unit 12, an external function linkage unit 13, a communication unit 14, a log storage unit 15, and a detection rule storage unit 16.

[0062] The log collection unit 11 collects operation logs transmitted from each of the one or more monitored devices 4 via the external network N1. In this embodiment, the log collection unit 11 collects the operation log of the air conditioner 4A, the operation log of the water heater 4B, and the operation log of the gas stove 4C. The log collection unit 11 stores the collected operation logs of each device 4 in the log storage unit 15.

[0063] Fig. 3 is a diagram showing an example of the operation log of device 4. In Fig. 3, the "Time Stamp" column indicates time information at the time when an operation of device 4 was performed, "Device ID (Identifier)" indicates an ID for identifying device 4, the "Device Type" column indicates the type of device 4, and the "Operation Log" column indicates the content of the operation of device 4. For example, in the example shown in Fig. 3, the log collection unit 11 has collected an operation log indicating that device 4, whose device ID is "DA00001" and whose device type is "air conditioner," performed heating operation with a set temperature of 37 degrees Celsius at 18:00 on April 1, 2024.

[0064] The anomaly detection unit 12 executes an anomaly detection process to determine whether or not an anomaly has occurred in each of the one or more devices 4, based on the operation logs of each of the one or more monitored devices 4 collected by the log collection unit 11. Here, an anomaly occurring in the device 4 means, for example, that the device 4 has been subjected to a cyber-attack, causing the device 4 to perform an operation that would not be possible under normal circumstances.

[0065] Specifically, the anomaly detection unit 12 refers to the detection rules stored in the detection rule storage unit 16, and if the operation log of the device 4 satisfies the detection rule, it determines that an abnormality has occurred in the device 4. Then, the anomaly detection unit 12 transmits abnormality determination data indicating that an abnormality has occurred in the device 4 to SOAR2. On the other hand, if the operation log of the device 4 does not satisfy the detection rule, the anomaly detection unit 12 determines that the device 4 is normal. In this case, the anomaly detection unit 12 does not transmit the abnormality determination data to SOAR2.

[0066] Fig. 4 is a diagram showing an example of a detection rule. In Fig. 4, the "Rule ID" column indicates an ID for identifying the detection rule, the "Device Type" column indicates the type of device 4, and the "Alert Generation Condition" column indicates the condition for SIEM 1 to generate an alert, i.e., the condition for determining that an abnormality has occurred in device 4. For example, in the example shown in Fig. 4, if device 4 is an air conditioner and its operation log satisfies the detection rule that "the temperature setting is 35 degrees Celsius or higher," the abnormality detection unit 12 determines that an abnormality has occurred in device 4.

[0067] 3, the log collection unit 11 collects an operation log indicating that device 4, whose device ID is "DA00001" and whose device type is "air conditioner," performed heating operation with the temperature set to 37 degrees Celsius at 18:00 on April 1, 2024. Since this operation log satisfies the detection rule that "the temperature setting is 35 degrees Celsius or higher," the anomaly detection unit 12 determines that an anomaly has occurred in device 4.

[0068] The external function linking unit 13 links with external functions other than the SIEM 1. Specifically, the external function linking unit 13 notifies the SOAR 2 that an abnormality has occurred in any one of the one or more devices 4 to be monitored, for example, by transmitting abnormality determination data to the SOAR 2. Furthermore, the external function linking unit 13 notifies the analyst P1 that an abnormality has occurred in any one of the one or more devices 4 to be monitored, for example, by transmitting abnormality determination data to the monitoring PC 3.

[0069] The communication unit 14 is a communication interface that performs wired or wireless communication with each of one or more devices 4 in the facility 200 via the external network N1. The communication unit 14 is also a communication interface that performs wired or wireless communication with the SOAR 2 in the SOC 100.

[0070] The log storage unit 15 is realized by an appropriate storage device, for example, a magnetic storage device such as a hard disk drive (HDD) or a semiconductor memory such as a solid state drive (SSD). The log storage unit 15 stores information indicating the contents of the operation logs collected by the log collection unit 11.

[0071] The detection rule storage unit 16 is realized by an appropriate storage device, such as a magnetic storage device such as an HDD, or a semiconductor memory such as an SSD, etc. The detection rule storage unit 16 stores information indicating the contents of the detection rules.

[0072] In the embodiment, the log storage unit 15 and the detection rule storage unit 16 are stored in separate storage devices, but this is not limiting. For example, the log storage unit 15 and the detection rule storage unit 16 may be implemented in a single storage device.

[0073] 5 is a block diagram showing an example of a functional configuration of a threat response system (SOAR) 2 according to an embodiment. The SOAR 2 includes a processor and a memory, and realizes its functions by the processor executing a program stored in the memory. As shown in FIG. 5, the SOAR 2 includes an abnormality determination data collection unit 21, a playbook execution unit 22, an external function linkage unit 23, a communication unit 24, an abnormality determination data storage unit 25, a playbook storage unit 26, a function storage unit 27, and a recovery characteristic storage unit 28.

[0074] The abnormality determination data collecting unit 21 collects the abnormality determination data transmitted from the SIEM 1. The abnormality determination data collecting unit 21 stores the collected abnormality determination data in the abnormality determination data storage unit 25.

[0075] FIG. 6 is a diagram illustrating an example of anomaly determination data. In FIG. 6 , the column “Timestamp at the time of anomaly detection execution” indicates the time information at which SIEM 1 determines that an anomaly has occurred in device 4 during the anomaly detection process, and the column “Rule ID” indicates the ID of the detection rule applied to device 4 in which an anomaly has been determined to have occurred. Also, in FIG. 6 , the column “Device Type” indicates the type of device 4 in which an anomaly has been determined to have occurred, the column “Device ID” indicates the ID of device 4 in which an anomaly has been determined to have occurred, and the column “Anomalous Detection Result” indicates the determination result of the anomaly detection process. For example, in the example illustrated in FIG. 6 , the anomaly determination data collector 21 collects anomaly determination data indicating that device 4, whose device ID is “DA00001” and whose device type is “air conditioner,” was determined to have occurred an anomaly at 14:20 on April 9, 2024, based on the detection rule whose rule ID is “RA00001” (specifically, the detection rule stating that “the temperature setting is 35 degrees Celsius or higher”).

[0076] When the abnormality determination data collection unit 21 collects abnormality determination data, the playbook execution unit 22 executes a playbook corresponding to the device 4 in which an abnormality has been determined to have occurred by referring to the playbook stored in the playbook storage unit 26. In other words, when it is determined that an abnormality exists in the monitored device 4, the playbook execution unit (processing unit) 22 executes a playbook for returning the device 4 from an abnormal state to a normal state. In the embodiment, when executing a playbook, the playbook execution unit 22 executes one or more functions included in the workflow of the playbook in a predetermined order by referring to each function stored in the function storage unit 27.

[0077] FIG. 7 is a diagram showing an example of a playbook. In FIG. 7, the "Playbook ID" column represents an ID for identifying the playbook, the "Trigger" column represents the trigger that causes the playbook execution unit 22 to execute the playbook, and the "Workflow" column represents the content of one or more functions that are executed sequentially in the workflow of the playbook. For example, in the example shown in FIG. 7, the playbook execution unit 22 executes each function included in the workflow in the order of "fB," "fA," and "fC" in response to a trigger of "obtaining abnormality determination data for rule ID: RA00001," that is, a trigger that determines that an abnormality has occurred in device 4, whose device ID is "DA00001" and whose device type is "air conditioner," based on a detection rule that "the temperature setting is 35 degrees Celsius or higher."

[0078] A workflow may branch along the way. For example, in a playbook that executes the functions included in the workflow in the order of "fB," "fA," "fC," and "fD," it may be possible to execute the function "fE" instead of the function "fD" after the execution of the function "fC," depending on the execution result of the function "fC."

[0079] FIG. 8 is a diagram illustrating an example of a function included in a workflow. In FIG. 8, the "Function ID" column represents an ID for identifying the function, the "Function Content" column represents the content executed by the function, the "Input Information" column represents the information used to execute the function, and the "Output Information" column represents the information acquired by executing the function. For example, in the example shown in FIG. 8, when executing the function "fA," the playbook execution unit 22 sends an operation mode (described later) switching command to the device ID of the device 4 targeted for playbook execution. Furthermore, when executing the function "fB," the playbook execution unit 22 specifies the device ID of the device 4 targeted for playbook execution and requests the SIEM 1 for a past operation log of the device 4 (i.e., the device that detected an abnormality). In this case, the playbook execution unit 22 acquires the log information of the device 4, i.e., the past operation log of the device 4, from the SIEM 1. Furthermore, when executing the function "fC," the playbook execution unit 22 notifies the monitoring PC 3 (i.e., the analyst P1 of the SOC 100) of the content detected in the anomaly detection process. In addition, when the playbook execution unit 22 executes the function "fD", it sends a control command to the device ID of the device 4 that is the target of the playbook execution, instructing it to perform initialization during free time.

[0080] Here, when executing a playbook, the playbook execution unit (processing unit) 22 refers to the recovery characteristics stored in the recovery characteristic memory unit 28, and determines the operating mode of the device 4 to be either the first mode or the second mode depending on the recovery characteristics related to the recovery of the device 4 that is the target of the playbook execution.

[0081] The first mode is a mode in which the current operation of the device 4 on which the playbook is executed is maintained, and is also called the normal mode. When the device 4 on which the playbook is executed operates in the first mode, all functions of the device 4 are basically available.

[0082] The second mode is a mode that limits the available functions of the device 4 on which the playbook is executed, and is also called a degenerate mode. When the device 4 on which the playbook is executed operates in the second mode, the use of some of the functions of the device 4 is limited.

[0083] In the embodiment, in the second mode, only the minimum functions required for the device 4 on which the playbook is executed are available, and other functions are restricted. Here, the minimum functions required for the device 4 include functions specific to the device 4 and the device 4's communication function with the SOC 100 (SIEM1 and SOAR2). For example, if the device 4 is an air conditioner and the device 4 operates in the second mode, basic functions of the air conditioner, such as cooling operation, heating operation, and temperature setting, and the communication function with the SOC 100 are not restricted. On the other hand, in this case, functions for linking with external devices, including an information processing terminal such as a smartphone owned by the user P2, are restricted. Note that the communication function with the SOC 100 may be restricted until the workflow is completed when communication with the SOC 100 is no longer required during the execution of the playbook.

[0084] FIG. 9 is a diagram showing an example of recovery characteristics. In FIG. 9 , the column "Device Type" indicates the type of device 4, and the column "Recovery Characteristics" indicates the contents of the recovery characteristics. In the embodiment, the recovery characteristics indicate the recovery time required to recover the device 4. Specifically, in the example shown in FIG. 9 , for device 4 whose device type is an air conditioner, the time required from executing a playbook to recovery, in other words, from executing a playbook to returning to a normal state, is 32 hours.

[0085] Then, if the recovery time exceeds a threshold (here, the first threshold), the playbook execution unit 22 determines the operating mode of the device 4 that is the target of playbook execution to be the second mode. On the other hand, if the recovery time is below the threshold, the playbook execution unit 22 determines the operating mode of the device 4 that is the target of playbook execution to be the first mode. The first threshold is, for example, 5 hours. Therefore, in the example shown in FIG. 9, if the device 4 whose device type is an air conditioner is the target of playbook execution, the playbook execution unit 22, by referring to the recovery characteristics, determines that the recovery time is 32 hours, which exceeds the first threshold, and therefore determines the operating mode of the device 4 to be the second mode.

[0086] The external function linking unit 23 links with external functions other than SOAR 2. Specifically, the external function linking unit 23 notifies the analyst P1 of the progress of measures taken on the device 4 that is the target of the playbook execution, for example, by transmitting the progress of the playbook to the monitoring PC 3.

[0087] The communication unit 24 is a communication interface that performs wired or wireless communication with each of one or more devices 4 in the facility 200 via the external network N1. The communication unit 14 is also a communication interface that performs wired or wireless communication with the SIEM 1 in the SOC 100.

[0088] The communication unit (output unit) 24 outputs the operation mode determined by the playbook execution unit (processing unit) 22. In an embodiment, the communication unit 24 outputs an instruction for operation in the operation mode determined by the playbook execution unit 22 by transmitting it to the device 4 that is the target of playbook execution. Specifically, the communication unit 24 transmits an operation mode switching command to the device 4 that is the target of playbook execution. As a result, the device 4 that receives the operation mode switching command switches its own operation mode from the first mode to the second mode. Note that the communication unit 24 may transmit the operation mode switching command to the device 4, including information on which functions of the device 4 are to be restricted.

[0089] The communication unit (output unit) 24 may notify the analyst P1 of the operating mode determined by the playbook execution unit 22. In this case, when the analyst P1 approves that the device 4 that is the target of playbook execution will operate in the second mode, the communication unit 24 may send an operating mode switching command to the device 4 that is the target of playbook execution.

[0090] The abnormality determination data storage unit 25 is realized by an appropriate storage device, such as a magnetic storage device such as an HDD, or a semiconductor memory such as an SSD, etc. The abnormality determination data storage unit 25 stores information indicating the contents of the abnormality determination data.

[0091] The playbook storage unit 26 is realized by an appropriate storage device, for example, a magnetic storage device such as an HDD, or a semiconductor memory such as an SSD. The playbook storage unit 26 stores information indicating the contents of the playbook.

[0092] The function storage unit 27 is realized by an appropriate storage device, such as a magnetic storage device such as an HDD, or a semiconductor memory such as an SSD, etc. The function storage unit 27 stores information indicating the content of each function included in the workflow.

[0093] The restoration characteristic storage unit 28 is realized by an appropriate storage device, such as a magnetic storage device such as an HDD, or a semiconductor memory such as an SSD, etc. The restoration characteristic storage unit 28 stores information indicating the contents of the restoration characteristic.

[0094] In the embodiment, the abnormality determination data storage unit 25, the playbook storage unit 26, the function storage unit 27, and the restoration characteristic storage unit 28 are stored in separate storage devices, but this is not limiting. For example, the abnormality determination data storage unit 25, the playbook storage unit 26, the function storage unit 27, and the restoration characteristic storage unit 28 may be realized by a single storage device.

[0095] 10 is a block diagram showing an example of the functional configuration of device 4 according to an embodiment. Device 4 includes a processor and a memory, and the processor executes a program stored in the memory to realize its functions. As shown in FIG. 10, device 4 includes a function execution unit 41, a device linkage unit 42, a communication unit 43, an operation mode storage unit 44, and an operation log storage unit 45.

[0096] The function execution unit 41 executes various functions of the device 4. When the function execution unit 41 operates in the first operation mode, it can basically execute all functions. Furthermore, when the function execution unit 41 operates in the second operation mode upon receiving an operation mode switching command from the SOAR 2, it can execute functions other than those restricted in the second mode.

[0097] The device linking unit 42 links with external functions other than the device 4. Specifically, the device linking unit 42 links with an information processing terminal such as a smartphone owned by the user P2 or another device 4 by communicating with the device 4 via the communication unit 43. For example, when the device linking unit 42 receives a remote operation from the user P2 on the smartphone, the device linking unit 42 causes the function executing unit 41 to execute a function corresponding to the remote operation.

[0098] The communication unit 43 also serves as a communication interface that performs wired or wireless communication with each of the SIEM1 and SOAR2 in the SOC100 via the external network N1.

[0099] The operation mode storage unit 44 is realized by an appropriate storage device such as a semiconductor memory such as a flash memory, etc. The operation mode storage unit 44 stores information indicating the content of the first mode and information indicating the content of the second mode.

[0100] The operation log storage unit 45 is realized by an appropriate storage device such as a semiconductor memory such as a flash memory. The operation log storage unit 45 stores the operation log of the device 4.

[0101] In the embodiment, the operation mode storage unit 44 and the operation log storage unit 45 are stored in separate storage devices, but this is not limiting. For example, the operation mode storage unit 44 and the operation log storage unit 45 may be implemented in a single storage device.

[0102] [2. Operation] An example of operation of the SOAR (threat response system) 2 according to the embodiment will be described below. An overview of the operation of the entire configuration including the SOAR 2 according to the embodiment will be described with reference to Fig. 11. Fig. 11 is a sequence diagram showing an example of operation of the entire configuration including the SOAR 2 according to the embodiment. In the example shown in Fig. 11, there is one device 4 to be monitored, but there may be multiple devices 4 to be monitored.

[0103] The device 4 periodically transmits an operation log to the SIEM 1 (S1). Note that when step S1 is executed, the device 4 is assumed to be not under a cyber-attack. After collecting the operation log from the device 4, the SIEM 1 executes an anomaly detection process (S2). Here, since the device 4 is not under a cyber-attack, the SIEM 1 determines that the device 4 is normal (S3).

[0104] It is assumed that an attacker (third party) then launches a cyber attack against device 4 and illegally seizes control authority over device 4 (S4). By illegally controlling device 4, the attacker causes device 4 to perform abnormal operations that would not be possible under normal circumstances. Device 4 then transmits an operation log of the abnormal operations to SIEM 1 (S5).

[0105] When SIEM1 collects the operation log from device 4, it executes an anomaly detection process (S6). Here, since device 4 is subjected to a cyber-attack and is performing abnormal operation, SIEM1 determines that an abnormality has occurred in device 4 (S7). SIEM1 then transmits anomaly determination data to SOAR2 (S8). When SOAR2 collects the anomaly determination data, it executes the playbook corresponding to device 4 indicated by the anomaly determination data (S9). Thereafter, when recovery work based on the playbook is completed, device 4 returns from the abnormal state to a normal state.

[0106] FIG. 12 is a flowchart showing an example of the operation of the SIEM 1 according to the embodiment. After collecting an operation log from the device 4, the SIEM 1 executes the operation shown in FIG. 12 . First, the SIEM 1 determines whether the operation log of the device 4 satisfies the detection rule (S101). If the operation log of the device 4 does not satisfy the detection rule (S101: NO), the SIEM 1 determines that the device 4 is normal (S102). On the other hand, if the operation log of the device 4 satisfies the detection rule (S101: YES), the SIEM 1 determines that an abnormality has occurred in the device 4 (S103). Then, the SIEM 1 transmits the abnormality determination data to the SOAR 2 (S104).

[0107] 13 is a flowchart showing an example of the operation of SOAR2 according to the embodiment. When SOAR2 collects anomaly determination data from SIEM1, it executes the operation shown in FIG. 13. First, SOAR2 selects a playbook corresponding to the device 4 in which an anomaly has been determined to have occurred, i.e., a playbook to be executed (S201). Next, SOAR2 sequentially selects one or more functions included in the workflow indicated by the selected playbook (S202). When executing step S202 for the first time, SOAR2 selects the first function in the workflow.

[0108] If the function selected in step S202 is not a function for sending an instruction to switch the operation mode, i.e., a function for switching the operation mode (S203: NO), SOAR2 executes the selected function (S208). If not all of the workflows have been executed (S209: NO), SOAR2 returns to step S202 and executes the processes from step S202 onward.

[0109] On the other hand, if the function selected in step S202 is the operation mode switching function (S203: YES), SOAR2 obtains the recovery time of the device 4 by referring to the recovery characteristics of the device type of the device 4 that is the target of the playbook execution (S204).

[0110] Then, if the recovery time exceeds the first threshold (S205: YES), SOAR2 decides to switch the operation mode of the device 4 to the second mode (S206), and executes the selected function (S208). Here, SOAR2 sends an operation mode switching command to the device 4. On the other hand, if the recovery time is below the first threshold (S205: NO), SOAR2 decides to maintain the operation mode of the device 4 in the first mode (S207), and executes the selected function (S208). Here, SOAR2 does not send an operation mode switching command to the device 4.

[0111] Thereafter, until all of the workflows have been executed (S209: NO), SOAR2 repeats the processes of steps S202 to S208. Then, when all of the workflows have been executed (S209: YES), SOAR2 ends the playbook execution process.

[0112] Figure 14 is a diagram showing an example of a monitoring screen displayed on the display of the monitoring PC 3 according to an embodiment. In the example shown in Figure 14, the execution status of a playbook is displayed as a monitoring screen on the display of the monitoring PC 3. In Figure 14, the "Playbook ID" column represents the ID of the currently executing playbook, the "Workflow Completion Rate" column represents the percentage of all functions of the workflow indicated by the playbook that have been completed, and the "Timestamp" column represents the time information at the start of execution of the playbook. Also in Figure 14, the "Device Type" column represents the type of device 4 on which the playbook is to be executed, the "Device ID" column represents the ID of the device 4 on which the playbook is to be executed, the "Recovery Characteristics" column represents the recovery time of the device 4 on which the playbook is to be executed, and the "Device Execution Content" column represents the operating mode of the device 4 on which the playbook is to be executed.

[0113] For example, if the "Device Execution Content" is "Changing to Second Mode," the device 4 is operating in the second mode. Also, for example, if the "Device Execution Content" is "Cancel Second Mode," the device 4 is operating in the first mode. Analyst P1 can grasp the current status of the playbook execution by looking at the monitoring screen.

[0114] The "cancellation of the second mode" of the device 4, i.e., the transition of the device 4 from the second mode to the first mode, may be performed by SOAR2 sending an operating mode switching command to the device 4 when the workflow completion rate reaches 100%, or may be performed as a function included in the workflow. Also, SOAR2 may transition the device 4 from the second mode to the first mode during the execution of the playbook in response to a response from user P2 to the execution of the playbook.

[0115] [3. Advantages] Advantages of the threat response system (threat response method) according to the embodiment are described below. As described above, when executing a playbook, the threat response system (SOAR) 2 according to the embodiment determines the operating mode of the device 4 as either the first mode or the second mode, depending on the recovery characteristics of the device 4 on which the playbook is executed. In other words, it determines whether to restrict the available functions of the device 4. Therefore, for example, if it takes a long time for the device 4 to recover from a cyberattack, the risk to the device 4 can be reduced by restricting the available functions of the device 4. As a specific example, restricting the device 4's communication function with an external device can reduce the risk of the device 4 being attacked by the external device. As such, the threat response system 2 according to the embodiment has the advantage of easily reducing the risk associated with the occurrence of an abnormality in the device 4 between the time of a cyberattack and the time of recovery.

[0116] [4. Other Embodiments] Although the embodiments have been described above, the present disclosure is not limited to the above-described embodiments. Modifications of the embodiments are listed below. The first to fourth modifications listed below may be implemented in any suitable combination.

[0117] (First Modification) SOAR (Threat Response System) 2 of the first modification differs from SOAR 2 according to the embodiment in that the recovery characteristics indicate one or more work conditions that affect the recovery work of the device 4. SOAR 2 of the first modification also differs from SOAR 2 according to the embodiment in that when the number of work conditions that are satisfied among the one or more work conditions exceeds a threshold (here, a second threshold), the operation mode of the device 4 that is the target of playbook execution is determined to be the second mode.

[0118] FIG. 15 is a diagram illustrating an example of recovery characteristics in the first modified example. The example illustrated in FIG. 15 differs from the recovery characteristics in the embodiment (see FIG. 9 ) in that the “Recovery Characteristics” column indicates the presence or absence of one or more work conditions (here, five work conditions). Specifically, in the example illustrated in FIG. 15 , the recovery characteristics indicate the presence or absence of the work condition “the recovery work includes work involving danger,” “the recovery work includes work at height,” “location information is unknown (i.e., the location of the device 4 targeted for playbook execution is unknown),” “there is no past case of recovery work,” and “there is no recovery procedure corresponding to the error code.” Fulfilling any of these work conditions increases the time required to recover the device 4.

[0119] In this way, the one or more work conditions may include at least one of the following: the location information of the equipment 4 is unknown; the recovery work includes work at height; and the recovery work includes work involving danger. The one or more work conditions may also include the absence of a recovery procedure corresponding to an error code indicating that an abnormality has occurred in the equipment 4. The one or more work conditions may also include the absence of any past cases of recovery work for the equipment 4. In the first modified example, the recovery characteristics indicate all of these work conditions.

[0120] In the example shown in Figure 15, device 4, whose device type is a water heater and whose device ID is "DB00001," does not satisfy any of the work conditions (in other words, the number of work conditions satisfied is zero), so it takes a short time to recover. On the other hand, device 4, whose device type is a water heater and whose device ID is "DB00002," satisfies three work conditions, so it takes a long time to recover. In this way, even if devices 4 are of the same device type, the number of work conditions satisfied can vary.

[0121] Then, if the number of satisfying the work conditions exceeds a threshold (here, the second threshold), the playbook execution unit 22 determines the operating mode of the device 4 that is the target of playbook execution to be the second mode. On the other hand, if the number of satisfying the work conditions is below the threshold, the playbook execution unit 22 determines the operating mode of the device 4 that is the target of playbook execution to be the first mode. The second threshold is, for example, 1. Therefore, in the example shown in FIG. 15, if the device 4 that is the device type of an air conditioner and has the device ID "DA00001" is the target of playbook execution, the playbook execution unit 22 determines by referring to the recovery characteristics that the number of satisfying the work conditions is 2, which exceeds the second threshold, and therefore determines the operating mode of the device 4 to be the second mode.

[0122] 16 is a flowchart showing an example of the operation of SOAR2 in the first modified example. When SOAR2 collects abnormality determination data from SIEM1, it executes the operation shown in FIG. 16. First, SOAR2 selects a playbook corresponding to the device 4 in which an abnormality has been determined to have occurred, i.e., a playbook to be executed (S301). Next, SOAR2 sequentially selects one or more functions included in the workflow indicated by the selected playbook (S302). When executing step S302 for the first time, SOAR2 selects the first function in the workflow.

[0123] If the function selected in step S302 is not a function for sending an instruction to switch the operation mode, i.e., a function for switching the operation mode (S303: NO), SOAR2 executes the selected function (S308). If the entire workflow has not been executed (S309: NO), SOAR2 returns to step S302 and executes the processes from step S302 onward.

[0124] On the other hand, if the function selected in step S302 is the operation mode switching function (S303: YES), SOAR2 obtains one or more operation conditions of the device 4 by referring to the recovery characteristics of the device type of the device 4 to be executed by the playbook (S304).

[0125] Then, if the number of times the work condition is satisfied exceeds the second threshold (S305: YES), SOAR2 decides to switch the operation mode of the device 4 to the second mode (S306) and executes the selected function (S308). Here, SOAR2 sends an operation mode switching command to the device 4. On the other hand, if the number of times the work condition is satisfied is below the second threshold (S305: NO), SOAR2 decides to maintain the operation mode of the device 4 in the first mode (S307) and executes the selected function (S308). Here, SOAR2 does not send an operation mode switching command to the device 4.

[0126] Thereafter, until all of the workflows have been executed (S309: NO), SOAR2 repeats the processes of steps S302 to S308. Then, when all of the workflows have been executed (S309: YES), SOAR2 ends the playbook execution process.

[0127] As described above, in the first variant, whether or not to restrict the available functions of the device 4 is determined based on the number of work conditions that are met that affect the time required to recover the device 4 that is the target of the playbook execution, which has the advantage that excessive function restrictions are less likely to be imposed.

[0128] (Second Modification) A SOAR (Threat Response System) 2 of a second modification differs from the SOAR 2 according to the embodiment in that the recovery time is predicted based on the execution time of each of one or more tasks included in a playbook.

[0129] FIG. 17 is a diagram showing an example of functions included in a workflow in the second modified example. The example shown in FIG. 17 differs from the functions included in the workflow in the embodiment (see FIG. 10 ) in that each function includes information indicating the presence or absence of one or more tasks (three tasks in this example). Specifically, in the example shown in FIG. 17 , each function indicates the presence or absence of a task called "analyst approval process," a task called "user approval process," and a task called "offline work (i.e., work performed at the installation site of device 4)." The fulfillment of any of these tasks is a condition that increases the time required to restore device 4.

[0130] In this way, one or more tasks may include an approval process by an analyst P1 who analyzes an abnormality in the equipment 4. One or more tasks may also include offline work on the equipment 4. One or more tasks may also include an approval process by a user P2 of the equipment 4. Although not shown here, one or more tasks may also include work by the user P2 on the equipment 4. In the second variant, the playbook includes all of these tasks except for the work by the user P2 on the equipment 4.

[0131] 18 is a diagram showing an example of recovery characteristics in the second modified example. The example shown in FIG. 18 differs from the recovery characteristics in the embodiment (see FIG. 9 ) in that the "Recovery Characteristics" column indicates the time required for each of one or more tasks (three tasks in this example). Specifically, in the example shown in FIG. 18 , the recovery characteristics indicate the time required for a task called "Analyst Approval Process," the time required for a task called "User Approval Process," and the time required for a task called "Offline Work."

[0132] In the example shown in FIG. 18, when the workflow of device 4, whose device type is an air conditioner, includes a task called "analyst approval process," the task takes one hour.

[0133] In the second variant, when the playbook execution unit 22 executes the function "fA," i.e., the function of sending an operating mode switching command, it acquires the current execution time, i.e., the time required from the start of the playbook to the execution of the function. The playbook execution unit 22 also predicts the time required to complete the workflow from the current time based on the tasks of each remaining function included in the workflow. Specifically, the playbook execution unit 22 calculates the time required to complete one or more tasks executed by each remaining function by referring to each function included in the workflow shown in FIG. 17 and the recovery characteristics shown in FIG. 18. The playbook execution unit 22 then predicts the time required to complete the workflow, in other words, the recovery time, by adding the current execution time to the calculated time.

[0134] Then, as in the embodiment, if the predicted recovery time exceeds a threshold (here, the third threshold), the playbook execution unit 22 determines the operation mode of the device 4 on which the playbook is to be executed to be the second mode. On the other hand, if the predicted recovery time is below the threshold, the playbook execution unit 22 determines the operation mode of the device 4 on which the playbook is to be executed to be the first mode. The third threshold is, for example, 5 hours, the same as the first threshold.

[0135] 19 is a flowchart showing an example of the operation of SOAR2 in the second modified example. When SOAR2 collects abnormality determination data from SIEM1, it executes the operation shown in FIG. 19. First, SOAR2 selects a playbook corresponding to the device 4 in which an abnormality has been determined to have occurred, i.e., a playbook to be executed (S401). Next, SOAR2 sequentially selects one or more functions included in the workflow indicated by the selected playbook (S402). When executing step S402 for the first time, SOAR2 selects the first function in the workflow.

[0136] If the function selected in step S402 is not a function for sending an operation mode switching command, i.e., an operation mode switching function (S403: NO), SOAR2 executes the selected function (S409). If not all workflows have been executed (S410: NO), SOAR2 returns to step S402 and executes the processes from step S402 onward.

[0137] On the other hand, if the function selected in step S402 is the operation mode switching function (S403: YES), SOAR2 acquires the current execution time (S404), as already described. Then, SOAR2 predicts the time required to complete the workflow (i.e., the recovery time), as already described (S405).

[0138] If the predicted time for completing the workflow exceeds the third threshold (S406: YES), SOAR2 decides to switch the operation mode of the device 4 to the second mode (S407) and executes the selected function (S409). Here, SOAR2 sends an operation mode switching command to the device 4. On the other hand, if the predicted time for completing the workflow is below the third threshold (S406: NO), SOAR2 decides to maintain the operation mode of the device 4 in the first mode (S408) and executes the selected function (S409). Here, SOAR2 does not send an operation mode switching command to the device 4.

[0139] Thereafter, until all of the workflows have been executed (S410: NO), SOAR2 repeats the processes of steps S402 to S409. Then, when all of the workflows have been executed (S410: YES), SOAR2 ends the playbook execution process.

[0140] As described above, in the second variant, whether or not to restrict the available functions of the device 4 is determined based on the time required for tasks that affect the time required to recover the device 4 on which the playbook is executed, which has the advantage that excessive function restrictions are less likely to be imposed.

[0141] (Third Modification) The SOAR (Threat Response System) 2 of the third modification differs from the SOAR 2 according to the embodiment in that the recovery characteristics indicate the magnitude of the risk of the device 4 in an abnormal state. The SOAR 2 of the third modification also differs from the SOAR 2 according to the embodiment in that when the magnitude of the risk exceeds a threshold (here, medium), the operation mode of the device 4 that is the target of playbook execution is determined to be the second mode.

[0142] FIG. 20 is a diagram showing an example of restoration characteristics in the third modified example. The example shown in FIG. 20 differs from the restoration characteristics in the embodiment (see FIG. 9 ) in that the "Restoration Characteristics" column indicates the magnitude of the risk of restoration work. Specifically, in the example shown in FIG. 20 , the risk of restoration work for device 4, whose device type is an air conditioner, is "high." In the third modified example, the risk of restoration work is divided into three levels: "high," "medium," and "low," with the magnitude of the risk decreasing in this order.

[0143] Then, if the magnitude of the risk exceeds a threshold (here, medium), the playbook execution unit 22 determines the operating mode of the device 4 that is the target of playbook execution to be the second mode. On the other hand, if the magnitude of the risk is below the threshold, the playbook execution unit 22 determines the operating mode of the device 4 that is the target of playbook execution to be the first mode. Therefore, in the example shown in Figure 20, if the device 4 whose device type is an air conditioner is the target of playbook execution, the playbook execution unit 22 determines by referring to the recovery characteristics that the magnitude of the risk is "large" and exceeds the threshold, and therefore determines the operating mode of the device 4 to be the second mode.

[0144] 21 is a flowchart showing an example of the operation of SOAR2 in the third modified example. When SOAR2 collects abnormality determination data from SIEM1, it executes the operation shown in FIG. 21. First, SOAR2 selects a playbook corresponding to the device 4 in which an abnormality has been determined to have occurred, i.e., a playbook to be executed (S501). Next, SOAR2 sequentially selects one or more functions included in the workflow indicated by the selected playbook (S502). When executing step S502 for the first time, SOAR2 selects the first function in the workflow.

[0145] If the function selected in step S502 is not a function for sending an operation mode switching command, i.e., an operation mode switching function (S503: NO), SOAR2 executes the selected function (S508). If not all workflows have been executed (S509: NO), SOAR2 returns to step S502 and executes the processes from step S502 onward.

[0146] On the other hand, if the function selected in step S502 is the operation mode switching function (S503: YES), SOAR2 obtains the magnitude of risk of the device 4 by referring to the recovery characteristics of the device type of the device 4 that is the target of the playbook execution (S504).

[0147] If the magnitude of the risk is "high," that is, if the magnitude of the risk exceeds the threshold (S505: YES), SOAR2 decides to switch the operation mode of the device 4 to the second mode (S506) and executes the selected function (S508). Here, SOAR2 sends an operation mode switching command to the device 4. On the other hand, if the magnitude of the risk is below the threshold (S505: NO), SOAR2 decides to maintain the operation mode of the device 4 in the first mode (S507) and executes the selected function (S508). Here, SOAR2 does not send an operation mode switching command to the device 4.

[0148] Thereafter, until all of the workflows have been executed (S509: NO), SOAR2 repeats the processes of steps S502 to S508. Then, when all of the workflows have been executed (S509: YES), SOAR2 ends the playbook execution process.

[0149] As described above, in the third variant, whether or not to restrict the available functions of the device 4 on which the playbook is to be executed is determined based on the level of risk posed by the device 4, which has the advantage of making it less likely that excessive functional restrictions will be imposed.

[0150] (Fourth Modification) The SOAR (Threat Response System) 2 of the fourth modification differs from the SOAR 2 of the embodiment in that the recovery characteristics indicate one or more risk conditions possessed by the device in an abnormal state. Furthermore, the SOAR 2 of the fourth modification differs from the SOAR 2 of the embodiment in that when the number of satisfying risk conditions among the one or more risk conditions exceeds a threshold (here, the fourth threshold), the operation mode of the device 4 that is the target of playbook execution is determined to be the second mode.

[0151] FIG. 22 is a diagram showing an example of recovery characteristics in the fourth modified example. The example shown in FIG. 22 differs from the recovery characteristics in the embodiment (see FIG. 9 ) in that the “Recovery Characteristics” column indicates the presence or absence of one or more risk conditions (here, three risk conditions). Specifically, in the example shown in FIG. 22 , the recovery characteristics indicate the presence or absence of the risk condition of “no backup (i.e., device 4 does not have a backup function),” the risk condition of “used by a user within a specified period,” and the risk condition of “linked with other devices.” Each of these risk conditions, when satisfied, increases the risk posed by device 4.

[0152] In this way, the one or more risk conditions may include the device 4 having no backup function. Also, the one or more risk conditions may include the user P2 of the device 4 having used the device 4 within a predetermined period of time since the occurrence of the abnormality. Also, the one or more risk conditions may include the device 4 being linked to another device. In the fourth modified example, the recovery characteristics indicate all of these risk conditions.

[0153] In the example shown in Figure 22, device 4, whose device type is a water heater and whose device ID is "DB00001", does not satisfy any risk conditions (in other words, the number of risk conditions satisfied is zero), and therefore device 4 poses a low risk. On the other hand, device 4, whose device type is a water heater and whose device ID is "DB00002", satisfies only one risk condition, and therefore device 4 poses a high risk. In this way, even if devices are of the same device type, the number of risk conditions satisfied may differ depending on the device 4.

[0154] Then, if the number of times the risk condition is satisfied exceeds a threshold (here, the fourth threshold), the playbook execution unit 22 determines the operating mode of the device 4 that is the target of playbook execution to be the second mode. On the other hand, if the number of times the risk condition is satisfied is below the threshold, the playbook execution unit 22 determines the operating mode of the device 4 that is the target of playbook execution to be the first mode. The fourth threshold is, for example, 1. Therefore, in the example shown in FIG. 22, if the device 4 that is the target of playbook execution is an air conditioner and has a device ID of "DA00001", the playbook execution unit 22 determines the operating mode of the device 4 to be the second mode by referring to the recovery characteristics, because the number of times the risk condition is satisfied is 2, which exceeds the fourth threshold.

[0155] 23 is a flowchart showing an example of the operation of SOAR2 in the fourth modified example. When SOAR2 collects abnormality determination data from SIEM1, it executes the operation shown in FIG. 23. First, SOAR2 selects a playbook corresponding to the device 4 in which an abnormality has been determined to have occurred, i.e., a playbook to be executed (S601). Next, SOAR2 sequentially selects one or more functions included in the workflow indicated by the selected playbook (S602). When executing step S602 for the first time, SOAR2 selects the first function in the workflow.

[0156] If the function selected in step S602 is not a function for sending an instruction to switch the operation mode, i.e., a function for switching the operation mode (S603: NO), SOAR2 executes the selected function (S608). If the entire workflow has not been executed (S609: NO), SOAR2 returns to step S602 and executes the processes from step S602 onward.

[0157] On the other hand, if the function selected in step S602 is the operation mode switching function (S603: YES), SOAR2 obtains one or more risk conditions of the device 4 by referring to the recovery characteristics of the device type of the device 4 that is the target of the playbook execution (S604).

[0158] Then, if the number of items that satisfy the risk condition exceeds the fourth threshold (S605: YES), SOAR2 decides to switch the operation mode of the device 4 to the second mode (S606) and executes the selected function (S608). Here, SOAR2 sends an operation mode switching command to the device 4. On the other hand, if the number of items that satisfy the work condition is below the second threshold (S605: NO), SOAR2 decides to maintain the operation mode of the device 4 in the first mode (S607) and executes the selected function (S608). Here, SOAR2 does not send an operation mode switching command to the device 4.

[0159] Thereafter, until all of the workflows have been executed (S609: NO), SOAR2 repeats the processes of steps S602 to S608. Then, when all of the workflows have been executed (S609: YES), SOAR2 ends the playbook execution process.

[0160] As described above, in the fourth variant, whether or not to restrict the available functions of the device 4 is determined based on the number of risk conditions that the device 4 that is the target of the playbook execution has, which has the advantage that excessive function restrictions are less likely to be imposed.

[0161] (Other Modifications) In the above-described embodiment, the processing performed by a specific processing unit may be performed by another processing unit. The order of multiple processing operations may be changed, or multiple processing operations may be performed in parallel.

[0162] In the above-described embodiments, each component may be realized by executing a software program suitable for that component, or by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.

[0163] Furthermore, each component may be realized by hardware. For example, each component may be a circuit (or integrated circuit). These circuits may form a single circuit as a whole, or each may be a separate circuit. Furthermore, each of these circuits may be a general-purpose circuit or a dedicated circuit.

[0164] Furthermore, the general or specific aspects of the present disclosure may be realized as an apparatus, a method, an integrated circuit, a computer program, or a computer-readable recording medium such as a CD-ROM, etc. Furthermore, the general or specific aspects of the present disclosure may be realized as any combination of an apparatus, a method, an integrated circuit, a computer program, and a recording medium.

[0165] For example, the present disclosure may be realized as a threat response method executed by a computer, or as a program for causing a computer to execute the threat response method. The present disclosure may also be realized as a computer-readable non-transitory recording medium on which such a program is recorded.

[0166] In addition, this disclosure also includes forms obtained by applying various modifications to the embodiments that a person skilled in the art would think of, or forms realized by arbitrarily combining the components and functions of the embodiments within the scope that does not deviate from the intent of this disclosure.

[0167] The present disclosure is useful for monitoring whether or not a device is at risk of a cyberattack.

[0168] 1 SIEM 11 Log collection unit 12 Anomaly detection unit 13 External function linkage unit 14 Communication unit 15 Log storage unit 16 Detection rule storage unit 2 SOAR (Threat Response System) 21 Anomaly determination data collection unit 22 Playbook execution unit (processing unit) 23 External function linkage unit 24 Communication unit (output unit) 25 Anomaly determination data storage unit 26 Playbook storage unit 27 Function storage unit 28 Recovery characteristic storage unit 3 Monitoring PC 4 Device 41 Function execution unit 42 Device linkage unit 43 Communication unit 44 Operation mode storage unit 45 Operation log storage unit 4A Air conditioner 4B Water heater 4C Gas stove 5 Network device 100 SOC 200 Facility N1 External network P1 Analyst P2 User

Claims

1. A threat response method comprising: when a monitored device is determined to have an abnormality, executing a playbook for restoring the device from an abnormal state to a normal state; determining, when executing the playbook, the operating mode of the device to either a first mode that maintains the current operation or a second mode that limits the available functions of the device, depending on the recovery characteristics of the device; and outputting the determined operating mode.

2. The threat response method according to claim 1, wherein in the second mode, only the minimum functions required for the device are available, and other functions are restricted.

3. The threat response method according to claim 1, wherein the recovery characteristic indicates a recovery time required for recovery of the device, and when the recovery time exceeds a threshold, the operating mode is determined to be the second mode.

4. The threat response method described in claim 1, wherein the recovery characteristics indicate one or more work conditions that affect the recovery work of the device, and when the number of satisfied work conditions among the one or more work conditions exceeds a threshold, the operating mode is determined to be the second mode.

5. The threat response method described in claim 4, wherein the one or more work conditions include at least one of the following: location information of the equipment is unknown; the recovery work includes work at height; and the recovery work includes work involving danger.

6. The threat response method according to claim 4, wherein the one or more operation conditions include the absence of a recovery procedure corresponding to an error code indicating that the abnormality has occurred in the device.

7. The threat response method according to claim 4, wherein the one or more operation conditions include the absence of any past instances of the restoration operation on the device.

8. The threat response method according to claim 3, wherein the recovery time is predicted based on the execution time of each of one or more tasks included in the playbook.

9. The threat response method according to claim 8, wherein the one or more tasks include an approval process by an analyst who analyzes the anomaly in the device.

10. The threat response method according to claim 8, wherein the one or more tasks include offline work on the device.

11. The threat response method according to claim 8, wherein the one or more tasks include an approval process by a user of the device or an action by the user on the device.

12. The threat response method described in claim 1, wherein the recovery characteristics indicate the magnitude of risk posed by the equipment in the abnormal state, and when the magnitude of the risk exceeds a threshold, the operating mode is determined to be the second mode.

13. The threat response method described in claim 1, wherein the recovery characteristics indicate one or more risk conditions possessed by the device in the abnormal state, and when the number of the one or more risk conditions that are satisfied exceeds a threshold, the operating mode is determined to be the second mode.

14. The threat response method according to claim 13, wherein the one or more risk conditions include the device having no backup function.

15. The threat response method according to claim 13, wherein the one or more risk conditions include a condition that a user of the device has used the device within a predetermined period of time since the occurrence of the abnormality.

16. The threat response method according to claim 13, wherein the one or more risk conditions include the device being in communication with other devices.

17. The threat response method according to any one of claims 1 to 16, wherein the determined operating mode is output by notifying an analyst who analyzes the abnormality in the device.

18. A threat response method according to any one of claims 1 to 16, wherein an instruction to operate in the determined operation mode is output by being transmitted to the device.

19. A program causing one or more processors to execute the threat response method according to any one of claims 1 to 16.

20. A threat response system comprising a processing unit and an output unit, wherein the processing unit, when it is determined that a monitored device has an abnormality, executes a playbook for restoring the device from an abnormal state to a normal state, and when executing the playbook, determines the operating mode of the device to either a first mode that maintains the current operation or a second mode that limits the available functions of the device, depending on recovery characteristics regarding the recovery of the device, and the output unit outputs the operating mode determined by the processing unit.

Images