Incident response system and incident response method

Abstract

To provide an incident response system and an incident response method with which it is possible to generate and configure a processing workflow composed of a combination of an external system and processing components for responding to individual incidents in accordance with the type of risk.SOLUTION: Provided is an incident response system for responding to individual incidents, said system comprising: a playbook database that holds, for each type of risk, a processing workflow for responding to incidents in the risk, as a playbook; a playbook selection unit that acquires incident information that has occurred or is likely to occur, and extracts a playbook for responding to the incident from among the playbooks created for each type of risk; a workflow generation unit that generates a processing workflow for responding to individual incidents on the basis of the extracted playbook; and a workflow engine unit that outputs a process for an incident.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to an incident handling system and an incident handling method. [Background technology]

[0002] Electricity transmission and distribution companies that operate and manage various types of infrastructure, such as power grids, are highly concerned about three risks: natural disasters, equipment failures, and cyber attacks.Specifically, these risks include natural disasters that are becoming more severe due to global warming, multiple equipment failures due to the aging of power facilities, and sophisticated cyber attacks that do not only affect IT systems.New risks that have wide-ranging and widespread effects and require cross-departmental responses when such incidents occur have become apparent.

[0003] In order to deal efficiently and quickly with incidents caused by these new risks, a comprehensive and centralized risk management solution is required that effectively coordinates the multiple departments involved across the board and provides direction and supervision for them.

[0004] Among these, Patent Document 1, which concerns SOAR (Security Orchestration, Automation and Response), a comprehensive framework for responding to cyber-attacks, proposes to focus on cyber-attacks, turn countermeasures into workflows, standardize tasks, and quickly respond to incidents. In this case, a workflow consisting of procedures for responding to incidents that are expected to occur and processing scripts for API calls, etc., is defined in a playbook, realizing standardization of tasks and semi-automation of procedure execution. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] US2021-0306352 Summary of the Invention [Problem to be solved by the invention]

[0006] According to Patent Document 1, it is possible to achieve a certain degree of effectiveness against cyber attacks. However, in Patent Document 1, specific incidents of cyber attacks are dealt with based on a static and fixed workflow defined in a playbook, so it is not possible to predefine all of the workflows for dealing with individual incidents of a wide variety of risks other than cyber attacks.

[0007] This is because natural disasters include typhoons, floods, forest fires, etc., and the external systems that hold information on each risk incident, the location of that data, and the processing programs differ depending on the individual incident of each risk. Examples of processing programs include components and simulators.

[0008] Because there are so many types of risks and countermeasures for so many different situations, it is not possible to write a program using if-then rules and to predefine all the workflows required for each risk incident being considered.

[0009] As these new risks have wide-reaching and widespread impacts, there is a limit to how much they can be addressed with conventional point solutions that have been introduced for each business or department. Solutions that realize "quick recovery from damage" and "maintain achievement of business KPIs" are required to deal with these new risks.

[0010] In view of the above, the present invention aims to provide an incident handling system and an incident handling method that can generate and configure a processing workflow for dealing with individual incidents, consisting of a combination of external systems and each processing component, depending on the type of risk. [Means for solving the problem]

[0011] In view of the above, the present invention is an "incident response system that responds to individual incidents, characterized in having a playbook DB that holds processing workflows, which are response flows for incidents at risks, as playbooks for each type of risk, a playbook selection unit that acquires incident information that has occurred or is showing signs of occurring and extracts a playbook corresponding to the incident from the playbooks created for each type of risk, a workflow generation unit that generates a processing workflow corresponding to the individual incident based on the extracted playbook, and a workflow engine unit that outputs processing for the incident."

[0012] The present invention is also described as "an incident handling method for individual incidents, characterized in that a processing workflow, which is a response flow for incidents in risks, is held as a playbook for each type of risk, information on incidents that have occurred or are showing signs of occurring is acquired, the playbook corresponding to the incident is extracted from the playbooks created for each type of risk, a processing workflow corresponding to the individual incident is generated based on the extracted playbook, and processing for the incident is output." Effect of the Invention

[0013] According to the present invention, when an incident occurs, it is possible to deal with a wide variety of risks in a centralized and comprehensive manner that have wide-area and wide-ranging effects and are complicated to deal with, requiring a cross-departmental response. [Brief description of the drawings]

[0014] [Figure 1] FIG. 2 is a diagram showing a processing function of the incident response system according to the embodiment of the present invention. [Diagram 2] A diagram showing the process in the preparation stage of system construction. [Diagram 3]A diagram showing the process that is carried out at the actual response stage when an incident occurs. [Figure 4] FIG. 2 is a diagram showing the hardware configuration of a computer device. [Diagram 5] 4 is a flowchart showing the process executed by a calculation unit of the computer device. [Figure 6] FIG. 2 is a diagram showing the processing contents of the incident response system 1 during a typhoon. [Figure 7] A diagram showing an example of a power grid operated and managed by a power transmission and distribution company. [Figure 8] A diagram summarizing the relationship between the input (In) and output (Out) of each component. [Figure 9] A diagram showing an example of a playbook for typhoons. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Hereinafter, embodiments of the present invention will be described with reference to the drawings. EXAMPLES

[0016] An incident response system according to an embodiment of the present invention is realized by using a computer device. An incident response system 1 according to an embodiment of the present invention shown in Fig. 1 is shown as a processing function block showing the processing contents executed by the calculation unit of the computer device. Note that, although the following example will be described as an example of operating and managing a power system, the application is not limited to power systems.

[0017] The incident response system 1 in Fig. 1 responds to multiple risks such as natural disasters, equipment failures, and cyber attacks, and responds to individual incidents within the risks. A risk is, for example, a typhoon in the case of a natural disaster. An incident is, for example, Typhoon No. 15.

[0018] The incident response system 1 acquires various inputs I (I1, I2, I3) from the outside, and outputs an instruction output O as a result of internal processing. The processing content here consists of processing at the system construction preparation stage and processing at the actual response stage when an incident occurs. First, the processing at the system construction preparation stage will be explained.

[0019] In Fig. 1, in processing step S1, which is the process in the system construction preparation stage, a workflow categorized according to a standard processing workflow is created for each risk scenario based on the response history I1 at the time of incident occurrence experienced in the past. In processing step S2, a playbook is created that describes the response workflow for the risk incident by categorizing it into a standard processing workflow, and is stored in the playbook database DB.

[0020] Figure 2 is a diagram showing the process in the system construction preparation stage. It lists the specific contents of input P1 obtained from outside in the system construction preparation stage, internal data P2 prepared in advance, processing contents P3, and output P4 in the system construction preparation stage. As shown in input P1, in the system construction preparation stage, the inputs are the systems and applications used when dealing with incidents, which are documented in manuals for each type of risk, or tacit knowledge (know-how), and the linkage procedures for manual processing.

[0021] As shown in the prepared internal data P2, for example, a list of common components and input / output I / F specification information, a list of data sources (including IP addresses) and input / output I / F specification information, a list of external systems (final output destinations) (including IP addresses) and input / output I / F specification information are stored. This ensures the connection relationships between the common components, data sources, and external systems (final output destinations), builds a communication system that allows required information to be obtained immediately, and facilitates data sharing.

[0022] As shown in processing content P3, engineers define a workflow categorized according to the standard processing workflow for each type of risk, and create a playbook database DB for each type of risk, as shown in output P4. A specific example of a playbook will be described later with reference to Fig. 9, and input / output data and components are prepared for each stage of the workflow.

[0023] In the system construction preparation stage, a standard processing workflow for dealing with incidents obtained from past cases is defined. The standard processing workflow has five stages. In the first stage, the necessary information is obtained and collected from appropriate external systems according to the type of risk. In the second stage, the current situation is grasped or damage is predicted from the obtained and collected information. In the third stage, the necessary response plan is generated based on the current situation understanding and prediction. In the fourth stage, the generated response plan is verified and evaluated in advance to see if it is appropriate and feasible, and whether the response will cause any unforeseen impacts. In the fifth stage, instructions are carried out based on the verified and evaluated plan. Processing is carried out according to the flow of this workflow.

[0024] This workflow has been created for each risk, such as natural disasters, equipment failures, and cyber attacks, and is known as a standard processing workflow because it can be operated as a standard based on typical past incident cases.

[0025] In contrast, in a real incident, the standard processing workflow should be used as a reference, but the workflow should be optimized according to the individual circumstances. For this reason, in the preparation stage, for each type of risk, a response workflow for the risk incident consisting of a combination of external systems and each processing component should be created. Flow Processing A playbook that describes the workflow by categorizing it into a standard processing workflow is created and prepared in advance. In other words, a template that is patterned based on the type is prepared.

[0026] Next, the process at the actual response stage when an incident occurs will be described.

[0027] In the actual response stage when an incident occurs, the first step is processing step S3 of the incident handling system 1. The incident handling system 1 first acquires incident occurrence information I2 from the external system G1. This may be incident occurrence prediction information. The incident handling system 1 then refers to the playbook database DB and selects a playbook corresponding to a risk from among multiple risks according to the risk corresponding to the incident occurrence information. In this example, the risk is a natural disaster and the incident is the occurrence of a typhoon. In the case of a typhoon, the external system G1 is a weather forecast server such as the Japan Meteorological Agency.

[0028] Next, in processing step S4, a workflow for the recently occurring typhoon is generated. This is, for example, a workflow for formulating asset management for how the power transmission and distribution business operator who operates and manages the power system should utilize the assets owned by the power transmission and distribution business operator to respond to the approach and passage of the typhoon and damage that has occurred or is expected to occur thereafter. Assets refer to, for example, infrastructure facilities and personnel who manage the infrastructure. In this workflow, the following stages are set for each risk: information gathering stage, prediction stage, plan generation stage, verification and evaluation stage, and instruction stage, and the actions to be taken at each stage are organized for each risk.

[0029] When a prerequisite or priority goal is given at the time of generating a workflow, the processing components in the workflow or the processing conditions of each processing component are switched. A priority goal is a goal that an infrastructure operator should prioritize. For example, a KPI. Examples of each processing component include a plan generation and a verification simulator. Processing conditions include setting conditions and calculation conditions of an incident response system.

[0030] Thereafter, the incident response system 1 executes the workflow for the current case while referring to the generated workflow in the workflow engine 2, and outputs to the outside an asset management appropriate for the current incident.

[0031] For this reason, the workflow engine 2 has, for example, a prediction component 21, a plan generation component 22, and a simulator component 23, acquires assets that can be deployed in the current incident countermeasure and their details from the external system G2, and finally provides the available assets and their allocation details (where, what, and how much to deploy) to the external system G3 as instruction output O. Note that these components 21, 22, and 23 are provided for each risk type, and the corresponding components 21, 22, and 23 are selected and used appropriately depending on the risk. Note that in this example, only the processing steps S6, S7, and S8 refer to the components 21, 22, and 23, but this may also be the case where processing steps S5 and S9 also refer to the components.

[0032] The external systems G2 and G3 are the EAM (Enterprise Asset Management) system that manages business assets, and the FSM (Field Service Management) system that manages workers. Here, the equipment and workers managed by EAM and FSM are sometimes collectively referred to as assets.

[0033] Figure 3 is a diagram showing the process in the actual response stage when an incident occurs. It lists the specific contents of the input R1 obtained from outside in the actual response stage R, the internal data R2 prepared in advance, the processing contents R3, and the output in the final preparation stage (= input for the actual response stage) R4. According to this, in the actual response stage, parameters via the screen as shown in input R1, (Select In that case) Selected data source, policy for dealing with individual incidents (emphasis on efficiency, emphasis on safety, etc.) etc. Enter.

[0034] As shown in the prepared internal data R2, the playbook database DB created in the advance preparation stage is held. As shown in the processing content R3, the workflow generation defines the common component configuration and data input / output definition between components corresponding to individual incidents, and outputs an executable processing workflow as shown in the output (= output of the actual response stage) R4.

[0035] In processing step S5 in Fig. 1, the necessary information is acquired and collected from the appropriate external systems G1 and G2 depending on the type of risk. The acquired and collected information should include a wide range of information, such as meteorological information such as the typhoon's course and size in the case of a typhoon, assets that can be deployed to deal with the typhoon and their details, or locations where damage occurred under what preconditions in the case of multiple past typhoons.

[0036] In process step S6, the natural disaster (typhoon) prediction component 21 is referenced to grasp the current situation or predict damage in the current typhoon case from the acquired and collected information. In process step S7, the natural disaster (typhoon) plan generation component 22 is referenced to generate a necessary response plan based on the current situation grasp and prediction. This is to determine response measures using currently available equipment and human assets. In process step S8, the natural disaster (typhoon) simulator component 23 is referenced to verify and evaluate in advance whether the generated response plan is appropriate and executable, and whether the response will not cause unforeseen effects. In process step S9, instructions are executed based on the verified and evaluated plan.

[0037] The mechanism for handling the actual response stage when an incident occurs can be summarized as follows: The handling process is a standard processing workflow consisting of a data acquisition and collection stage, a prediction stage, a plan generation stage, a verification and evaluation stage, and an instruction stage. The processing block is a combination of external systems and each processing component for each type of risk. It's a flowIt has a playbook that describes processing workflows by categorizing them according to standard processing workflows, and a function that generates workflows (= combinations of processing blocks) corresponding to individual incidents based on the playbook.

[0038] Furthermore, when a precondition or a priority goal is given at the time of generating a workflow, the processing components in the workflow or the processing conditions of each processing component are switched.

[0039] In FIG. 1 of the first embodiment, the processing contents executed by the arithmetic unit of the computer device are shown as processing function blocks, but if a hardware configuration is shown, it is preferable to use the configuration shown in FIG.

[0040] In this case computer equipment has a playbook database DB and an output database DB0 as a storage unit therein, and has a plurality of components 22 and 23, and a workflow engine 2. It also has functions of incident detection, playbook selection, and workflow generation.

[0041] Also, mainly for playbook editing, a playbook editor 11 and a graphical user interface 12 are connected via a front-end server 13. Furthermore, it is connected to external data sources G1, G2, and G3 via a data access adapter 14 and a source database 15 or directly.

[0042] While FIG. 1 shows the process contents executed by the arithmetic unit of the computer device as processing function blocks, FIG. 5 will be described using a flowchart showing the process contents executed by the arithmetic unit of the computer device.

[0043] First, in processing step S11, an incident is detected. Here, the incident is detected by a notification that an event has occurred from a predefined connection destination or by ensuring communication (polling). In processing step S12, a corresponding playbook is selected according to the connection destination / notification content.

[0044] In processing step S13, Typhoon No. 15 / date and time are designated from the GUI side, etc., and a connection destination server (Japan Meteorological Agency) is designated, thereby making it possible to refer to individual incident information.

[0045] In process step S14, it is confirmed whether prerequisites, constraints, or key performance indicators (KPIs) have been set when the workflow was generated, and if they have been set, the KPIs, constraints, and setting information are referenced in process step S15. After that, in process step S16, an individual incident response workflow is generated, and the workflow is executed in process step S17 and thereafter.

[0046] The above-described processing of the present invention makes it possible to deal in a centralized and comprehensive manner with a wide variety of risks that have wide-area and wide-ranging effects and are complicated to deal with, requiring cross-departmental responses when an incident occurs. EXAMPLES

[0047] In the second embodiment, the process of the incident response system 1 during a typhoon will be described as a specific example. First, the incident response system 1 during a typhoon in Fig. 6 obtains the course, wind speed, wind direction, rainfall, and other typhoon conditions of the currently occurring and approaching typhoon from the weather forecast server of the external system G1.

[0048] In response to this, a process is performed to detect an incident and select a playbook, and the playbook database DB for each type of risk is referenced. In processing step S4, a response workflow is generated from the playbook for typhoons, which are natural disasters.

[0049] Figure 7 shows an example of a power system operated and managed by a power transmission and distribution company, where power is supplied from power plants via substations to each consumer via power transmission and distribution lines. The management scope of this power system is determined for each of the power transmission and distribution company's sales offices A, B, and C, and workers at each of these offices usually manage and maintain the power transmission and distribution equipment (such as utility poles and pole-mounted transformers) within their own management scope.

[0050] However, this typhoon TW0 is predicted to pass through the power grid area operated and managed by the power transmission and distribution company. The predicted range of its progress is within the angle θ, but it is most likely to move in the direction of TW1, which is the direction of the area managed by sales bases B and C.

[0051] In such a situation, damage to power distribution facilities is predicted in processing step S6, which is the prediction stage of the incident response system 1 in Fig. 6. The prediction result is that, for example, damage to power facilities will be greater in the direction of TW1, which is predicted to be the most likely direction for the typhoon to move in the future.

[0052] Next, in processing step S7, which is the planning stage of the incident response system 1 in Fig. 6, a resource allocation plan is generated for the assets owned by the power transmission and distribution company. The result of this plan is that sales offices B and C have difficulty responding within the scope of their own managed assets, and require asset assistance from sales office A as support from other sales offices.

[0053] Finally, in processing step S8, which is the verification stage of the incident response system 1 in Fig. 6, it is verified whether or not it is actually possible to provide assets from sales base A as support from other sales bases, and how efficient the movement would be. Here, circumstances such as the need to wait for a response at sales base A are also taken into consideration.

[0054] Finally, an instruction output O according to the above verification result is provided to the external system G3. These instructions are material allocation instructions, which are instructions for allocating materials and workers, or work (transport) instructions, or work instructions, which are instructions for allocating workers.

[0055] As described above about Figure 7, this shows the flow of typhoon pre-deployment by the incident response system 1. In typhoon pre-deployment by the incident response system 1, before the typhoon arrives, damage to power distribution facilities and the like that will be caused by the typhoon is predicted ((0) in Figure 7), and a pre-deployment plan is formulated to deploy workers and materials at appropriate bases ((1) in Figure 7). The appropriateness of this pre-deployment plan is verified using a simulator or the like ((2) in Figure 7), and instructions are given to external systems such as EAM and FSM that manage the workers and materials, and "pre-deployment" is carried out at the appropriate time.

[0056] Figure 8 summarizes examples of inputs In and outputs Out between components in Figure 1. First, in the processing step S5 of data acquisition and collection, when data is acquired and stored from an external system, it is possible to configure the prediction component to acquire data directly from the external system without the data acquisition and collection component. The output Out is information provided by the weather forecast server, EAM, and FSM.

[0057] The components in the processing step S6 in the prediction are wind speed predictions, wind direction predictions, and rainfall predictions for each point for each typhoon path prediction from the weather forecast server for the input In, and obtain information on the equipment type (electric pole, steel tower, etc.) and equipment installation location from the EAM. Also, for the output Out, electric pole damage (collapse) predictions, steel tower damage predictions, etc. are given as equipment damage predictions.

[0058] The components in processing step S7 in plan generation are, for input In, utility pole damage prediction and tower damage prediction for facility damage prediction, and for EAM and FSM, worker information (worker ID, current location, qualification, assigned task status) and material information (material ID, material type, specifications, current location, assigned task status, etc.), and for output Out, worker / material allocation plan, worker / material information (worker ID / material ID, allocation location, allocation date and time, etc.).

[0059] The components in processing step S8 in the verification evaluation are worker / resource information (worker ID / resource ID, location, date and time of deployment, etc.) as a worker / resource deployment plan for input In, and the plan verification result is OK / NG for output Out.

[0060] The components in the processing step S9 for instructions are the plan verification result OK / NG for the input In, and the output Out is worker / resource information (worker ID / resource ID, location, date and time of deployment, etc.) for worker / resource deployment instructions.

[0061] In the second embodiment, the case of a typhoon is used as an example, but it goes without saying that similar incident countermeasures can be realized for other risks by appropriately adjusting the input and processing content according to the risk.

[0062] Fig. 9 is a diagram showing an example of a playbook for a typhoon. The vertical axis describes the data acquisition and collection stage (S5), the prediction stage (S6), the plan generation stage (S7), the verification and evaluation stage (S8), and the execution stage, and the horizontal axis shows examples of components t1, input data t2, output data t3, special notes t4, setting information t5, etc. at each stage.

[0063] Collect_typhoon_JMA.py and Collect_typhoon_NAA.py are the names of the components used in the collection phase, predict.py is the name of the component used in the prediction phase, Plan_generator is the name of the component used in the planning phase, workforce_simulator1 and workforce_simulator2 are the names of the components used in the validation phase, Workorder.py is the name of the component to be used in the execution phase.

[0064] As a result, the generated workflow is as follows: Collect_typhoon_JMA.py → predict.py → Plan_generator → wThe order of execution is orkforce_simulator2 → Workorder.py. Note that similar things are set for other risks with the same idea.

[0065] The basic concept described in the first embodiment can be summarized as follows using a typhoon example with reference to Fig. 6. First, in the concept verification stage of typhoon pre-deployment, a playbook corresponding to typhoon pre-deployment is defined.

[0066] The playbook describes a prototype workflow for performing typhoon pre-positioning, which consists of components for predicting damage, generating a deployment plan for workers and materials based on the damage prediction, and verifying the generated plan.

[0067] The workflow generation processing block uses playbooks to obtain information corresponding to individual incidents from external systems such as weather information servers and EAM and FSM that manage workers and materials, and generates a workflow that includes the transfer of data.

[0068] The generated workflows are executed sequentially by the workflow engine (orchestrator), and finally, instructions are issued to the EAM and FSM to realize the operational process of typhoon pre-positioning.

[0069] The damage prediction component predicts damage to power distribution facilities based on various meteorological data such as wind direction, wind speed, and accumulated rainfall.

[0070] The resource allocation planning component draws up a plan for pre-positioning and moving resources such as workers and materials from one base to another based on damage predictions.

[0071] The verification component uses a simulator to evaluate and verify the feasibility and validity of the formulated plan.

[0072] If the verification reveals no problems, instructions are sent as work orders to external systems such as EAM and FSM that manage workers and materials, and "pre-placement" is performed at the appropriate time.

[0073] The components included in the processing workflow generated from the playbook may change depending on the given KPIs, etc. For example, there may be simulators for verification and evaluation that have different judgment perspectives (weightings), such as one that verifies whether the plan has sufficient resources and another that verifies from the perspective of costs.

[0074] In addition, there may be cases where components change depending on the specified location. For example, when the location is different, not only the damage prediction to the power grid but also the points that are emphasized differ depending on the regional characteristics such as urban areas, industrial areas, suburban areas, and rural areas. Components also change depending on the context.

[0075] For example, because it is expected that the calculation logic for pre-placement plans will differ, the components of the plan formulation will switch depending on the area. There are cases where it is good to pre-place utility poles in places where many poles are likely to fall, and cases where it is good to pre-place utility poles in important areas even if it is expected that few poles will fall. [Explanation of symbols]

[0076] 1: Incident response system 2: Workflow engine 21: Prediction component 22: Plan generation component 23: Simulator component DB: Playbook Database G1, G2, G3: External Systems

Claims

1. An incident response system for responding to individual incidents, A playbook DB that holds a processing workflow, which is a flow for dealing with incidents in risks, as a playbook for each type of risk; A playbook selection unit that acquires incident information that has occurred or is predictive of an occurrence, and extracts the playbook corresponding to the incident from the playbooks created for each type of risk; A workflow generation unit that generates a processing workflow corresponding to an individual incident based on the extracted playbook; a workflow engine unit that outputs a process for the incident, The workflow engine unit includes: A current situation grasping / prediction unit that acquires incident information that has occurred or is expected to occur, predicts a damage situation, and extracts the playbook corresponding to the incident based on the damage situation and the type of the incident; A plan generation / evaluation unit that generates a processing workflow corresponding to an individual incident based on the extracted playbook, creates a countermeasure plan by the processing workflow, and evaluates whether the generated countermeasure plan is executable; and an instruction / execution unit that outputs a proposed response plan for the incident based on the evaluation.

2. The incident response system according to claim 1, An incident response system, wherein the playbook is weighting information of priority goals based on risk.

3. The incident response system according to claim 1, The workflow engine unit holds individual processing processes in a processing workflow as processing blocks for processing the individual processing processes.

4. The incident response system according to claim 1, The incident handling system, wherein the processing workflow includes a prediction stage, a planning stage, and a verification and evaluation stage for each incident.

5. An incident response system as claimed in claim 4, The incident response system, wherein the processing workflow further includes a data collection stage and an instruction stage.

6. The incident response system according to claim 1, An incident response system characterized in that the workflow generation unit changes prerequisites or priority goals used in individual processing processes in the processing workflow when generating a processing workflow corresponding to an individual incident.

7. An incident response system as claimed in claim 3, The workflow generation unit changes processing conditions in the processing blocks when generating a processing workflow corresponding to an individual incident.

8. The incident response system according to claim 1, An incident response system characterized in that a playbook is created in advance for each type of risk, describing the processing workflow, which is the flow for dealing with incidents related to that risk, by categorizing it in accordance with a standard processing workflow and storing the playbook in a playbook database, with the playbook being created by referencing multiple examples of incidents that have occurred in the past.

9. An incident handling method for responding to an individual incident, the method being executed by a calculation unit of a computer device, comprising: The process workflow for dealing with risk incidents is stored as a playbook for each type of risk. Acquire incident information that has occurred or is predicting an occurrence, and extract the playbook corresponding to the incident from the playbooks created for each type of risk; Based on the extracted playbook, a processing workflow corresponding to each individual incident is generated; Outputting a process for the incident; To output a process for the incident, Acquire incident information that has occurred or is expected to occur, predict a damage situation, and extract the playbook corresponding to the incident based on the damage situation and the type of the incident; Based on the extracted playbook, a processing workflow corresponding to each individual incident is generated, a countermeasure plan is created using the processing workflow, and the generated countermeasure plan is evaluated for feasibility; An incident handling method, comprising: outputting a proposed response plan for the incident based on the evaluation.

10. The incident handling method according to claim 9, The incident handling method, wherein the playbook is weighting information of priority goals in terms of risk.

11. The incident handling method according to claim 9, 1. An incident handling method, comprising the steps of: generating a processing workflow corresponding to an individual incident; changing a prerequisite or a priority goal used in each processing process in the processing workflow;

Images