WO2024047895A1 - インシデント対処システム並びにインシデント対処方法 - Google Patents

インシデント対処システム並びにインシデント対処方法 Download PDF

Info

Publication number
WO2024047895A1
WO2024047895A1 PCT/JP2023/004268 JP2023004268W WO2024047895A1 WO 2024047895 A1 WO2024047895 A1 WO 2024047895A1 JP 2023004268 W JP2023004268 W JP 2023004268W WO 2024047895 A1 WO2024047895 A1 WO 2024047895A1
Authority
WO
WIPO (PCT)
Prior art keywords
incident
processing
playbook
workflow
handling system
Prior art date
Application number
PCT/JP2023/004268
Other languages
English (en)
French (fr)
Inventor
博貴 森部
光一朗 飯島
徹 渡辺
一平 檜
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Publication of WO2024047895A1 publication Critical patent/WO2024047895A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0635—Risk analysis of enterprise or organisation activities

Definitions

  • the present invention relates to an incident handling system and an incident handling method.
  • Power transmission and distribution companies that operate and manage various types of infrastructure are highly concerned about the three risks of natural disasters, equipment failure, and cyber attacks. Specifically, these risks include natural disasters that are becoming more severe due to global warming, multiple equipment failures due to aging power equipment, and sophisticated cyber-attacks that do not have a limited impact on IT systems. When such an incident occurs, a new risk that affects a wide range of areas and areas is emerging, requiring a cross-departmental response.
  • Patent Document 1 related to SOAR (Security Orchestration, Automation and Response), which is a comprehensive framework for incident response to cyber attacks, focuses on cyber attacks and standardizes work by creating a workflow of countermeasures to speed up operations. It is proposed that appropriate incident handling be carried out.
  • SOAR Simple Object Access Management Entity
  • a workflow consisting of procedures for dealing with incidents that are expected to occur and processing scripts such as API calls is defined in the playbook, thereby realizing work standardization and semi-automation of procedure execution.
  • Patent Document 1 it is possible to achieve a certain degree of effectiveness against cyber attacks.
  • specific incidents of cyber attacks are dealt with based on a static and fixed workflow defined in a playbook, so individual incidents of a wide variety of risks other than cyber attacks are dealt with. Not all workflows can be defined in advance.
  • processing programs include components and simulators.
  • the present invention provides an incident handling system and an incident handling system that can generate and configure a processing workflow for dealing with individual incidents, consisting of a combination of an external system and each processing component, depending on the type of risk.
  • the purpose is to provide a coping method.
  • the present invention is an "incident handling system that responds to individual incidents, and a playbook that stores a processing workflow, which is a flow of handling incidents for risks, as a playbook for each type of risk.”
  • a DB a playbook selection section that acquires incident information that has occurred or has signs of occurrence, and extracts a playbook corresponding to the incident from playbooks created for each type of risk, and the extracted playbook.
  • An incident handling system characterized by having a workflow generation unit that generates a processing workflow corresponding to an individual incident based on the above, and a workflow engine unit that outputs processing for the incident.
  • a processing workflow that is an incident handling method that corresponds to an individual incident, which is a handling flow for an incident in a risk, is maintained as a playbook for each type of risk, and Obtain incident information with signs, extract the playbook corresponding to the incident from the playbooks created for each type of risk, and perform processing corresponding to each individual incident based on the extracted playbook.
  • An incident handling method characterized by generating a workflow and outputting a process for the incident.'''
  • FIG. 1 is a diagram showing processing functions of an incident handling system according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing the hardware configuration of a computer device.
  • 5 is a flowchart showing the processing contents executed by the calculation unit of the computer device. The figure which shows the processing content of the incident response system 1 at the time of a typhoon.
  • the incident handling system according to the embodiment of the present invention is realized using a computer device.
  • the incident handling system 1 according to the embodiment of the present invention shown in FIG. 1 shows processing contents executed by a calculation unit of a computer device as processing function blocks.
  • the following examples will be explained using examples of operating and managing power systems, but the application is not limited to power systems.
  • the incident handling system 1 in FIG. 1 deals with multiple risks such as natural disasters, equipment failures, and cyber attacks, and deals with individual incidents within the risks.
  • risk refers to a typhoon in the case of a natural disaster.
  • the incident refers to typhoon No. 15, for example.
  • the incident handling 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 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.
  • each risk scenario is categorized according to a standard processing workflow based on the response history I1 when an incident occurred in the past. Create a workflow.
  • processing step S2 a playbook is created in which the workflow for dealing with the risk incident is categorized into standard processing workflows and is stored in the playbook database DB.
  • FIG. 2 is a diagram illustrating the processing at the system construction preparation stage.
  • the specific contents of input P1 obtained from the outside at the system construction preparation stage, internal data P2 prepared in advance, processing contents P3, and output P4 at the system construction preparation stage are listed.
  • input P1 at the system construction preparation stage, the systems and applications used when dealing with incidents, which are manualized or tacit knowledge (known as know-how) for each type of risk, and the coordination procedures of manual processing. is the input.
  • a list of common components and input/output I/F specification information 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, an external system (final output (including IP addresses) and input/output I/F specification information.
  • This ensures connectivity between common components, data sources, and external systems (final output destinations), establishes a communication system that allows necessary information to be obtained immediately, and facilitates data sharing.
  • the engineer defines workflows categorized according to the standard processing workflow for each type of risk, and as shown in output P4, creates a playbook database DB for each type of risk. .
  • a specific example of a playbook will be described later with reference to FIG. 9, but input/output data and components are prepared for each step of the workflow.
  • the standard processing workflow has five stages.
  • the first step is to obtain and collect the necessary information depending on the type of risk from the appropriate external system.
  • the second stage is to understand the current situation or predict damage based on the information obtained and collected.
  • the third step is to generate the necessary countermeasure plans based on the current situation and predictions.
  • the fourth step is to verify and evaluate in advance whether the generated response plan is appropriate and executable, and whether the proposed response will cause any unforeseen impacts.
  • the fifth step is to execute instructions based on the verified and evaluated plan. Processing is performed according to the flow of such a workflow.
  • This workflow is created for each risk of natural disasters, equipment failures, and cyber attacks, and is called a standard processing workflow because it can be operated as a standard based on common past incident cases.
  • the standard processing workflow should be used as a reference, but the workflow should be optimized according to individual circumstances. Therefore, in the preparation stage, for each type of risk, a playbook is created in advance that describes the incident response workflow of the risk, which consists of a combination of external systems and each processing component, in a standard processing workflow. I'll keep it. In other words, it has a patterned template based on the mold.
  • the processing at the actual response stage when an incident occurs first includes processing step S3 of the incident response system 1.
  • the incident handling system 1 first acquires incident occurrence information I2 from the external system G1. Note that the information may also be incident sign information. Thereafter, the incident handling system 1 refers to the playbook database DB and selects a playbook corresponding to the risk from among the plurality of risks according to the risk corresponding to the incident occurrence information.
  • the risk is a natural disaster
  • the incident is the occurrence of a typhoon.
  • the external system G1 is a weather prediction server such as the Japan Meteorological Agency.
  • a workflow for the typhoon that has occurred this time is generated.
  • the power transmission and distribution company that operates and manages the power system will be responsible for the damage that the power transmission and distribution company owns in response to the approach and passage of the typhoon, as well as damage that occurred or is expected to occur after the typhoon approaches and passes.
  • This is a workflow for formulating asset management regarding how to utilize and respond to assets.
  • Assets refer to, for example, infrastructure equipment and personnel who manage the infrastructure.
  • the following stages are set for each risk: information gathering stage, prediction stage, plan generation stage, verification evaluation stage, and instruction stage, and the things to be done at each stage are organized for each risk.
  • Priority goals are goals that infrastructure providers should prioritize. For example, KPI.
  • Examples of each processing component include a plan generation and a verification simulator.
  • the processing conditions include setting conditions and calculation conditions of the incident handling system.
  • the incident handling system 1 executes the workflow for the current case while referring to the generated workflow in the workflow engine 2, and externally outputs asset management suitable for the current incident.
  • the workflow engine 2 has, for example, a prediction component 21, a plan generation component 22, and a simulator component 23, and acquires the assets that can be used for the current incident countermeasure and their details from the external system G2, Finally, available assets and their distribution details (where, what, how much to put in) are given to the external system G3 as an instruction output O.
  • these components 21, 22, and 23 are provided for each risk type, and the corresponding components 21, 22, and 23 are appropriately selected and used according to the risk. Note that in this example, only processing steps S6, S7, and S8 refer to components 21, 22, and 23, but this may refer to components including processing steps S5 and S9. .
  • the external systems G2 and G3 are a system EAM (Enterprise Asset Management) that manages business assets or a system FSM (Field Service Management) that manages workers.
  • EAM Enterprise Asset Management
  • FSM Field Service Management
  • assets the equipment and workers managed by EAM and FSM are sometimes collectively referred to as assets.
  • internal data R2 it has a playbook database DB created in the preliminary preparation stage.
  • processing step S5 in FIG. 1 necessary information is acquired and collected from appropriate external systems G1 and G2 depending on the type of risk.
  • the information to be acquired and collected is weather information such as the course of the current typhoon and the size of the typhoon, or the assets and contents that can be currently invested in countermeasures against this typhoon, or It is good to include a wide range of information, such as what conditions caused damage and where damage occurred in past typhoons.
  • processing step S6 from the acquired/collected information, the natural disaster (typhoon) prediction component 21 is referred to to understand the current situation or predict the damage in the current typhoon case.
  • processing step S7 a necessary countermeasure plan is generated based on the current situation understanding and prediction with reference to the natural disaster (typhoon) plan generation component 22. This means that countermeasures have been established using currently available equipment and human resources.
  • processing step S8 with reference to the natural disaster (typhoon) simulator component 23, it is verified and evaluated in advance whether the generated countermeasure plan is appropriate and executable, and whether the countermeasure will cause unexpected impacts. do.
  • processing step S9 instructions are executed based on the verified and evaluated plan.
  • the processing mechanism at the actual response stage when an incident occurs can be summarized as a standard process consisting of a data acquisition and collection stage, a prediction stage, a plan generation stage, a verification evaluation stage, and an instruction stage.
  • a play that includes the processing block as a workflow and describes a processing workflow that generates a response to an incident of the risk, which is composed of a combination of an external system and each processing component for each type of risk, and categorizes it according to a standard processing workflow. It can be said that it has a function to generate a workflow ( combination of processing blocks) corresponding to an individual incident based on a book and a playbook.
  • the processing components in the workflow or the processing conditions of each processing component can be switched.
  • 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 the hardware configuration is to be shown, it is preferable to use the configuration as shown in FIG. 4.
  • the computer device 1 is internally provided with a playbook database DB and an output database DB0 as storage units, and has a plurality of components 22 and 23 and a workflow engine 2. It also has the functions of incident detection, playbook selection, and workflow generation.
  • a playbook editor 11 and a graphical user interface 12 are connected via a front-end server 13 mainly for playbook editing. 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.
  • FIG. 1 shows the processing contents executed by the calculation section of the computer device as processing function blocks
  • FIG. 5 describes a flowchart showing the processing contents executed by the calculation section of the computer device.
  • processing step S11 an incident is detected.
  • information is determined by notification of the occurrence of an event from a predefined connection destination or by securing communication (polling).
  • processing step S12 a corresponding playbook is selected depending on the connection destination/notification content.
  • the individual incident information is made referenceable by specifying Typhoon No. 15/date and time from the GUI side, and obtaining the connection destination server (Japan Meteorological Agency) specification.
  • processing step S14 it is confirmed that the prerequisites/constraints or priority goals (KPI) at the time of workflow generation are set, and if they have been set, the KPI, constraints, and setting information are referred to in processing step S15. do. Thereafter, an individual incident response workflow is generated in processing step S16, and the workflow is executed in processing step S17 and subsequent steps.
  • KPI prerequisites/constraints or priority goals
  • Example 2 the processing contents of the incident handling system 1 during a typhoon will be explained as a specific example.
  • the current typhoon status such as the course of the approaching typhoon, wind speed, wind direction, and rainfall is obtained from the weather prediction server of the external system G1.
  • a process is performed to detect an incident and select a playbook, and by referring to a playbook database DB for each type of risk, in processing step S4, a response workflow is created from a typhoon playbook among natural disasters. generate.
  • FIG. 7 is a diagram showing an example of a power system operated and managed by a power transmission and distribution company, in which power is supplied from a power plant to each consumer via a power transmission and distribution line via a substation.
  • the scope of management is determined for each business base A, B, and C of the power transmission and distribution company, and workers at each business base A, B, and C usually manage transmission within their own scope of management.
  • We manage and maintain equipment for power distribution equipment (utility poles, pole-mounted transformers, etc.).
  • this time's typhoon TW0 is expected to pass through the power system area operated and managed by the relevant power transmission and distribution company.
  • the predicted range of movement is within the range of angle ⁇ , it is predicted that it is most likely to move in the direction of TW1, which is the direction of the area managed by sales offices B and C.
  • processing step S6 which is the prediction stage of the incident handling system 1 in FIG. 6, damage to the power distribution equipment is predicted.
  • the prediction result is that, for example, the damage to power equipment will be greater in the direction of TW1, where the typhoon is expected to have the highest probability of moving in the future.
  • processing step S7 which is the planning stage of the incident handling system 1 in FIG. 6, a resource allocation plan is generated for the assets held by the power transmission and distribution company.
  • the result of this plan is that it is difficult for sales offices B and C to respond within the scope of their self-managed assets, and they require asset support from sales office A as support from other sales offices.
  • processing step S8 which is the verification stage of the incident handling system 1 in FIG. Verify the gender, etc.
  • circumstances such as the need for standby at sales office A for response are also taken into consideration.
  • These instructions include material placement instructions, which are instructions for arranging materials and workers, work (transportation) instructions, or work instructions, which are instructions for arranging workers.
  • FIG. 8 organizes examples of input In and output Out between components in FIG.
  • the component in processing step S5 in data acquisition/collection can be configured such that when acquiring and accumulating data from an external system, the prediction component directly acquires it from the external system without the data acquisition/collection component. be.
  • the output Out is each information provided by the weather prediction server, EAM, and FSM.
  • the components in processing step S6 in the prediction are the wind speed prediction at each point, wind direction prediction at each point, rainfall forecast at each point, etc. for each typhoon course prediction from the weather prediction server for input In, and the equipment types (utility poles, steel towers) from the EAM. etc.), obtain information on equipment installation locations, etc. Further, as the output Out, a utility pole damage (collapse) prediction, a steel tower damage prediction, etc. are given as equipment damage prediction.
  • the components in processing step S7 in plan generation are, in terms of input In, equipment damage prediction, utility pole damage prediction, tower damage prediction, EAM, FSM, worker information (worker ID, current location, qualifications, assigned task status), material information. (Material ID, material type, specifications, current location, assigned task status, etc.). Regarding the output Out, it is worker/material information (worker ID/material ID, placement location, placement date and time, etc.) as a worker/material placement plan.
  • the component in processing step S8 in the verification evaluation is worker/material information (worker ID/material ID, placement location, placement date and time, etc.) as a worker/material placement plan regarding the input In.
  • the plan verification result is OK/NG.
  • the component in processing step S9 for instructions is that the plan verification result is OK/NG for input In, and for output Out, worker/material information (worker ID/material ID, placement location, date and time of placement, etc.).
  • Example 2 the case of a typhoon was illustrated, but it goes without saying that similar incident countermeasures can be implemented for other risks by appropriately adjusting the input and processing contents to suit the risks.
  • 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 evaluation stage (S8), and the execution stage, and the horizontal axis describes the component t1 and input at each stage.
  • Data t2, output data t3, special notes t4, setting information t5, etc. are illustrated.
  • py is the name of the component used in the collection stage, predict.
  • py is the name of the component used in the prediction stage
  • Plan_generator is the name of the component used in the planning stage
  • workforce_simulator1 and workforce_simulator2 are the names of the components used in the verification stage
  • ⁇ Workorder py is the name of the component used in the execution stage.
  • Example 1 The basic concept described in Example 1 can be summarized and explained using the example of a typhoon with reference to FIG. 6 as follows.
  • a playbook corresponding to typhoon pre-positioning is defined.
  • This playbook describes a template workflow for executing typhoon pre-positioning, which consists of components that predict damage, generate a deployment plan for workers and materials based on the damage prediction, and verify the generated plan. ing.
  • the workflow generation processing block acquires information corresponding to individual incidents from the weather information server and external systems such as EAM and FSM that manage workers and materials based on the playbook, including data exchange. Generate a workflow.
  • the generated workflow is sequentially executed by a workflow engine (orchestrator), and finally, instructions are issued to EAM and FSM to realize the operational process of typhoon pre-positioning.
  • the damage prediction component predicts damage to power distribution equipment using various weather-related data such as wind direction, wind speed, and cumulative rainfall.
  • the resource allocation plan formulation component formulates a plan for moving and pre-arranging resources such as workers and materials from which base to which base based on damage prediction.
  • the verification component uses a simulator to evaluate and verify the feasibility and validity of the developed plan.
  • the components included in the processing workflow generated from the playbook may change depending on the given KPI, etc.
  • the simulators that perform verification and evaluation there may be simulators that have different judgment viewpoints (weighting), such as one that verifies whether the plan has sufficient resources, and another that verifies it from a cost perspective.

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

リスクの種類に応じて、外部システムと各処理コンポーネントの組合せからなる、個別のインシデントに対処するための処理ワークフローを生成・構成することができるインシデント対処システム並びにインシデント対処方法を提供する。個別のインシデントに対応するインシデント対処システムであって、リスクにおけるインシデントへの対処フローである処理ワークフローを、各リスクの種類ごとに、プレイブックとして保持するプレイブックＤＢと、発生したまたは発生予兆のあるインシデント情報を取得し、各リスクの種類ごとに作成されたプレイブックの中から、インシデントに対応するプレイブックを抽出するプレイブック選択部と、抽出したプレイブックを基に、個別のインシデントに対応した処理ワークフローを生成するワークフロー生成部と、インシデントに対する処理を出力するワークフローエンジン部と、を有することを特徴とするインシデント対処システム。

Description

インシデント対処システム並びにインシデント対処方法
　本発明は、インシデント対処システム並びにインシデント対処方法に関する。
　各種のインフラとして例えば電力系統を運用・管理する送配電事業者は、自然災害、設備故障、サイバー攻撃の３つのリスクに対し関心が高い。これらのリスクは、具体的には、地球温暖化に伴い激甚化している自然災害や、電力設備の高経年化等に伴う多重機器故障、ＩＴシステム内に影響が留まらない高度化したサイバー攻撃などといったものであり、係るインシデント発生時に、部署横断的に対処が必要とされるような、広域・広範に影響が及ぶ新しいリスクが顕在化している。
　このような新しいリスクによるインシデントに対し、効率的、かつ、迅速に対処するためには、関係する複数の部署を横断的、かつ、効果的に連携させるとともに、それを指揮・監督する、包括的かつ一元的なリスクマネジメントのソリューションが必要である。
　このうち、サイバー攻撃に対するインシデント対処の包括的なフレームワークであるＳＯＡＲ（Ｓｅｃｕｒｉｔｙ　Ｏｒｃｈｅｓｔｒａｔｉｏｎ、　Ａｕｔｏｍａｔｉｏｎ　ａｎｄ　Ｒｅｓｐｏｎｓｅ）に関する特許文献１では、サイバー攻撃に特化し、その対処策をワークフロー化して作業を標準化し、迅速なインシデント対処を行うことを提案している。ここでは、プレイブック内に、発生が想定されるインシデントへの対処手順や、ＡＰＩ呼出し等の処理スクリプトから成るワークフローを定義し、作業標準化、手順実行の半自動化を実現している。
ＵＳ２０２１－０３０６３５２
　特許文献１によれば、サイバー攻撃に対して一定程度の効果を奏することができる。しかしながら特許文献１では、サイバー攻撃の特定インシデントに対し、プレイブックに定義された、静的・固定的なワークフローに基づき対処が行われるため、サイバー攻撃以外の多種多様なリスクの個別のインシデントの対処ワークフロー全てを事前に定義することができない。
　なぜなら、自然災害といっても台風、洪水、山火事等があり、これらリスクの個別のインシデントによって、それぞれのリスクのインシデントの情報を備える外部システム及びそのデータの所在、処理プログラムが異なるためである。処理プログラムとしては、例えば、コンポーネントやシミュレータなどが挙げられる。
　多数のリスクの種類と多数の状況に応じた対策があるため、プログラムをｉｆ－ｔｈｅｎルールで書くことができず、考慮するリスクのインシデントに応じた各ワークフローを、事前に全て定義することができないということである。
　このように、これらの新しいリスクは、影響が広域・広範に及ぶため、業務や部署毎に導入が進んだ、従来のポイントソリューションでは対応に限界がある。係る新しいリスクに対して、”被害からの迅速回復”、”事業ＫＰＩ達成の維持”を実現するソリューションが求められる。
　以上のことから本発明においては、リスクの種類に応じて、外部システムと各処理コンポーネントの組合せからなる、個別のインシデントに対処するための処理ワークフローを生成・構成することができるインシデント対処システム並びにインシデント対処方法を提供することを目的とする。
　以上のことから本発明においては、「個別のインシデントに対応するインシデント対処システムであって、リスクにおけるインシデントへの対処フローである処理ワークフローを、各リスクの種類ごとに、プレイブックとして保持するプレイブックＤＢと、発生したまたは発生予兆のあるインシデント情報を取得し、各リスクの種類ごとに作成されたプレイブックの中から、インシデントに対応するプレイブックを抽出するプレイブック選択部と、抽出したプレイブックを基に、個別のインシデントに対応した処理ワークフローを生成するワークフロー生成部と、インシデントに対する処理を出力するワークフローエンジン部と、を有することを特徴とするインシデント対処システム」としたものである。
　また本発明においては、「個別のインシデントに対応するインシデント対処方法であって、リスクにおけるインシデントへの対処フローである処理ワークフローを、各リスクの種類ごとに、プレイブックとして保持し、発生したまたは発生予兆のあるインシデント情報を取得し、各リスクの種類ごとに作成されたプレイブックの中から、インシデントに対応する前記プレイブックを抽出し、抽出したプレイブックを基に、個別のインシデントに対応した処理ワークフローを生成し、インシデントに対する処理を出力することを特徴とするインシデント対処方法」としたものである。
　本発明によれば、インシデント発生時に、部署横断的に対処が必要とされるような、広域・広範に影響が及ぶ、対処が複雑化している多種多様なリスクに、一元的、かつ、包括的に対処できる。
本発明の実施例に係るインシデント対処システムの処理機能を示す図。 システム構築準備段階での処理を整理して示した図。 インシデント発生時の実対応段階での処理を整理して示した図。 計算機装置のハードウェア的な構成を示す図。 計算機装置の演算部が実行する処理内容を示すフローチャート。 台風の時のインシデント対処システム１の処理内容を示す図。 送配電事業者が運用・管理する電力系統の一例を示す図。 各コンポーネントにおける入力Ｉｎと出力Ｏｕｔの関係を整理した図。 台風に対するプレイブック例を示す図。
　以下、本発明の実施例について、図面を用いて説明する。
　本発明の実施例に係るインシデント対処システムは、計算機装置を用いて実現される。
図１に示した本発明の実施例に係るインシデント対処システム１は、計算機装置の演算部が実行する処理内容を処理機能ブロックとして示したものである。なお、以下の事例は電力系統を運用・管理する事例で説明するが、適用対象は電力系統に限らない。
　図１のインシデント対処システム１は、自然災害、設備故障、サイバー攻撃などの複数リスクに対応し、リスク内の個別インシデントに対処する。リスクとは、例えば、自然災害であれば台風のことを示す。インシデントとは、例えば、台風１５号のことを示す。
　インシデント対処システム１は、外部から各種の入力Ｉ（Ｉ１、Ｉ２、Ｉ３）を取得し、内部処理の結果、指示出力Ｏを出力する。ここでの処理内容は、システム構築準備段階での処理と、インシデント発生時の実対応段階での処理により構成される。まず、システム構築準備段階での処理について説明する。
　図１においてシステム構築準備段階での処理である処理ステップＳ１では、リスクシナリオとして、過去に経験されたインシデント発生時の対処履歴Ｉ１を基に、リスクシナリオ毎に標準処理ワークフローに沿って類型化したワークフローを作成する。処理ステップＳ２では、当該リスクのインシデントへの対処ワークフローを、標準処理ワークフローに類型化して記述するプレイブックを策定し、プレイブックデータベースＤＢに格納する。
　図２は、システム構築準備段階での処理を整理して示した図である。システム構築準備段階で外部から得る入力Ｐ１、予め備えている内部データＰ２、処理内容Ｐ３、システム構築準備段階での出力Ｐ４の具体的な内容を列挙している。入力Ｐ１に示すように、システム構築準備段階においては、リスクの種類ごとにマニュアル化された、もしくは暗黙知の（ノウハウ化された）インシデント対処時に利用するシステムやアプリケーション、及び人手による処理の連携手順をインプットとする。
　予め備えている内部データＰ２に示すように、例えば、共通コンポーネントのリストと入出力Ｉ／Ｆ仕様情報、データソースのリスト（含むＩＰアドレス）と入出力Ｉ／Ｆ仕様情報、外部システム（最終出力先）のリスト（含むＩＰアドレス）と入出力Ｉ／Ｆ仕様情報などを保有しておく。これにより、共通コンポーネント、データソース、外部システム（最終出力先）の間の接続関係が確保され、必要な情報が即時に入手可能な連絡体制を構築し、データ共有が図られる。
　処理内容Ｐ３に示すように、エンジニアにより、リスクの種類ごとに、標準処理ワークフローに沿って類型化したワークフローを定義し、出力Ｐ４に示すように、リスクの種類ごとのプレイブックデータベースＤＢを作成する。プレイブックの具体事例について図９を参照して後述するが、入出力データとコンポーネントが、ワークフローの段階ごとに準備される。
　システム構築準備段階では、過去事例から得られるインシデント対処における標準処理ワークフローを定めている。標準処理ワークフローは、５段階有する。第１段階は、リスクの種類に応じて必要な情報を適切な外部システムから取得・収集する。第２段階は、取得・収集した情報から、現状把握、もしくは、被害を予測する。第３段階は、現状把握や予測を基に、必要な対処計画案を生成する。第４段階は、生成した対処計画案が、適切で実行可能か、また、その対処により不測の影響が発生しないかを事前に検証・評価する。
第５段階は、検証・評価した計画案に基づき、指示を実行する。このようなワークフローの流れに沿って処理する。
　このワークフローは、自然災害、設備故障、サイバー攻撃のリスク毎に作成されており、一般的な過去のインシデント事例に基づいて標準的に運用可能なものであることから標準処理ワークフローと称している。
　これに対し、現実のインシデント場面では、標準処理ワークフローを参考にしつつも、個別事情に応じた最適化ワークフローとされるべきである。このため準備段階では、リスクの種類ごとに、外部システムと各処理コンポーネントの組合せからなる、当該リスクのインシデントへの対処ワークフローを、標準処理ワークフローに類型化して記述するプレイブックを予め作成し、備えておく。つまり、型に基づきパターン化した雛形を備えている。
　次に、インシデント発生時の実対応段階での処理について説明する。
　インシデント発生時の実対応段階での処理では、まず、インシデント対処システム１の処理ステップＳ３が挙げられる。インシデント対処システム１は、初めに、外部システムＧ１からのインシデント発生情報Ｉ２を取得する。なお、インシデント発生予兆情報であっても良い。その後、インシデント対処システム１は、プレイブックデータベースＤＢを参照して複数リスクの中からインシデント発生情報に対応するリスクに応じて、このリスクに対応するプレイブックを選択する。本事例では、リスクは自然災害であり、インシデントは台風の発生であるものとする。なお、台風の場合に、外部システムＧ１は気象庁などの気象予測サーバである。
　次に、処理ステップＳ４において、今回発生した台風におけるワークフローを生成する。これは例えば、今回発生した台風に対して、電力系統を運用・管理する送配電事業者が、台風の接近と通過及びその後について発生した或は予想される被害に対して送配電事業者が保有する資産をどのように活用して対応するかについての、資産運用を策定するワークフローである。資産とは、例えば、インフラ設備やインフラを管理する人員のことを示す。このワークフローでは、リスク毎に、情報収集段階、予測段階、計画生成段階、検証評価段階、指示段階の各段階を設定し、各段階で行うべきことをリスク毎に整理したものである。
　なお、ワークフロー生成時に、前提条件もしくは優先目標を与えると、ワークフロー中の処理コンポーネント、もしくは、各処理コンポーネントの処理条件が切替わるものとされる。優先目標とは、インフラ事業者が優先すべき目標のことである。例えば、ＫＰＩである。各処理コンポーネントは、例えば、計画生成や検証シミュレータなどが挙げられる。処理条件とは、インシデント対処システムの設定条件や演算条件などが含まれる。
　その後に、インシデント対処システム１は、ワークフローエンジン２において、生成されたワークフローを参照しながら、今回事例でのワークフローを実行し、今回のインシデントに適した資産運用を外部出力する。
　このため、ワークフローエンジン２は、例えば予測コンポーネント２１と、計画生成コンポーネント２２と、シミュレータコンポーネント２３の各コンポーネントを保有し、外部システムＧ２から今回のインシデント対策に投入可能な資産とその内訳を取得し、最終的に外部システムＧ３に利用可能な資産とその配分内訳（どこに何をどれだけ投入）を指示出力Ｏとして与える。なおこれらのコンポーネント２１、２２、２３は、リスク種別ごとに設けられており、適宜リスクに応じて対応するコンポーネント２１、２２、２３が選択され、使用される。なおこの事例では、処理ステップＳ６、Ｓ７、Ｓ８のみがコンポーネント２１、２２、２３を参照する事例で示したが、これは処理ステップＳ５、Ｓ９も含めてコンポーネントを参照するというものであってもよい。
　なお外部システムＧ２、Ｇ３とは経営アセットを管理するシステムＥＡＭ（Ｅｎｔｅｒｐｒｉｓｅ　Ａｓｓｅｔ　Ｍａｎａｇｅｍｅｎｔ）或は、作業者を管理するシステムＦＳＭ（Ｆｉｅｌｄ　Ｓｅｒｖｉｃｅ　Ｍａｎａｇｅｍｅｎｔ）である。ここでは、ＥＡＭ、ＦＳＭにより管理される設備や作業者を総称して資産ということがある。
　図３は、インシデント発生時の実対応段階での処理を整理して示した図である。実対応段階Ｒで外部から得る入力Ｒ１、予め備えている内部データＲ２、処理内容Ｒ３、最終的な準備段階での出力（＝実対応段階の入力）Ｒ４の具体的な内容を列挙している。これによれば実対応段階においては、入力Ｒ１に示すように画面経由のパラメータや、（（選べる場合）選択したデータソース、個別インシデントの対処方針（効率性重視、安全性重視等）など）を入力する。
　また予め備えている内部データＲ２に示すように、事前準備段階で作成したプレイブックデータベースＤＢを保有している。また処理内容Ｒ３に示すように、ワークフロー生成において個別のインシデントに対応した、共通コンポーネント構成と、コンポーネント間のデータ入出力定義を定義し、出力（＝実対応段階の出力）Ｒ４に示すように、実行可能な処理ワークフローを出力する。
　図１の処理ステップＳ５では、リスクの種類に応じて、必要な情報を適切な外部システムＧ１、Ｇ２から取得・収集する。取得・収集される情報は、台風の場合に今回の台風の進路、台風の大きさなどの気象情報であり、あるいはこの台風の対策のために現在投入可能な資産とその内容であり、或は過去の複数の台風事例の場合にどういう前提条件下でどういう場所に被害が生じたかといった、広範な情報を含んでいるのがよい。
　処理ステップＳ６では、取得・収集した情報から、自然災害（台風）の予測コンポーネント２１を参照して今回の台風事例における現状把握、もしくは、被害を予測する。処理ステップＳ７では、自然災害（台風）の計画生成コンポーネント２２を参照して現状把握や予測を基に、必要な対処計画案を生成する。これは、現在活用可能な設備的、人的な資産を用いた対応策を定めたことである。処理ステップＳ８では、自然災害（台風）のシミュレータコンポーネント２３を参照して、生成した対処計画案が、適切で実行可能か、また、その対処により不測の影響が発生しないかを事前に検証・評価する。処理ステップＳ９では、検証・評価した計画案に基づき、指示を実行する。
　インシデント発生時の実対応段階での処理のための機構は、これを整理して述べると、処理プロセスを、データ取得収集段階、予測段階、計画生成段階、検証評価段階、指示段階からなる標準処理ワークフローとして当該処理ブロックを備え、リスクの種類ごとに、外部システムと各処理コンポーネントの組合せからなる、当該リスクのインシデントへの対処を生成する処理ワークフローを、標準処理ワークフローに沿い類型化して記述するプレイブックと、プレイブックを基に、個別のインシデントに対応したワークフロー（＝処理ブロック群の組合せ）を生成する機能を備えたものということができる。
　さらには、ワークフロー生成時に、前提条件もしくは優先目標を与えると、ワークフロー中の処理コンポーネント、もしくは、各処理コンポーネントの処理条件が切り替わるようにしたものということができる。
　実施例１の図１では、計算機装置の演算部が実行する処理内容を処理機能ブロックとして示しているが、ハードウェア的な構成を示すならば図４の構成のようにすることが望ましい。
　この場合に計算機装置１は、その内部に記憶部としてプレイブックデータベースＤＢと出力データベースＤＢ０を備え、複数のコンポーネント２２、２３と、ワークフローエンジン２とを有する。また、インシデント検知、プレイブック選択、ワークフロー生成の機能を有する。
　また、主にプレイブック編集のためにフロントエンドサーバ１３を介してプレイブックエディタ１１、グラフィカルユーザインターフェイス１２を接続する。さらに、データアクセスアダプタ１４、ソースデータベース１５を介して、或は直接外部データソースＧ１、Ｇ２、Ｇ３と接続されている。
　図１は計算機装置の演算部が実行する処理内容を処理機能ブロックとして示しているが、図５では、計算機装置の演算部が実行する処理内容を示すフローチャートについて説明する。
　まず処理ステップＳ１１では、インシデント検知する。ここでは、あらかじめ定義した接続先からイベントが発生したことの通知であるとか、通信確保（ポーリング）により把握を行う。処理ステップＳ１２では、接続先／通知内容に応じて対応プレイブックを選択する。
　処理ステップＳ１３では、ＧＵＩ側等から、台風１５号／日時を指定し、また接続先サーバ（気象庁）指定を取得することで、個別インシデント情報を参照可能な状態とする。
　処理ステップＳ１４では、ワークフロー生成時の前提・制約条件もしくは優先目標（ＫＰＩ）が設定されていることの確認を行い、設定されている場合には処理ステップＳ１５において、ＫＰＩ、制約・設定情報を参照する。その後、処理ステップＳ１６において個別インシデント対応ワークフローを生成し、処理ステップＳ１７以降においてワークフローを実行する。
　本発明の上記処理により、インシデント発生時に、部署横断的に対処が必要とされるような、広域・広範に影響が及ぶ、対処が複雑化している多種多様なリスクに、一元的、かつ、包括的に対処できる。
　実施例２では、具体事例として台風の時のインシデント対処システム１の処理内容について説明する。まず図６の台風の時のインシデント対処システム１では、外部システムＧ１の気象予測サーバから現在発生して接近中の台風の進路、風速、風向、雨量他の台風状況を入手する。
　これに対して、インシデントを検知してプレイブックを選択する処理を行い、リスクの種類ごとのプレイブックデータベースＤＢを参照して、処理ステップＳ４では自然災害の中の台風のプレイブックから、対処ワークフローを生成する。
　図７は、送配電事業者が運用・管理する電力系統の一例を示す図であり、発電所から変電所を経由して各需要家までの間を送配電線により電力供給している。係る電力系統の管理は、送配電事業者の営業拠点Ａ、Ｂ、Ｃごとに管理範囲が定められており、各営業拠点Ａ、Ｂ、Ｃの作業員は通常は自己の管理範囲内における送配電設備（電柱や柱上変圧器など）の機器管理、整備を行っている。
　然るに今回の台風ＴＷ０は、当該送配電事業者が運用・管理する電力系統区域を通過すると予想されている。かつその進行予想範囲は角度θの範囲内であるが、ＴＷ１の方向に進む可能性が最も高いと予想され、これは営業拠点Ｂ、Ｃが管理する区域の方向である。
　係る状況において、図６のインシデント対処システム１の予測段階である処理ステップＳ６では電力流通設備被害を予測する。この予測結果は、例えば台風が今後進む可能性が最も高いと予想されるＴＷ１の方向で電力設備の被害が大きくなるというものである。
　次に、図６のインシデント対処システム１の計画段階である処理ステップＳ７では当該送配電事業者が保有する資産について、リソース配置計画を生成する。この計画結果は、営業拠点Ｂ、Ｃは自己管理する資産の範囲内での対応が困難であり、他営業拠点からの応援として営業拠点Ａからの資産の援助を必要とするというものである。
　最後に、図６のインシデント対処システム１の検証段階である処理ステップＳ８では、然らば実際に他営業拠点からの応援として営業拠点Ａからの資産の援助が可能か否か、あるいは移動の効率性はどうかなどを検証する。ここでは営業拠点Ａにおける対応のための待機も必要になるなどの事情も考慮される。
　最終的に、上記検証結果に応じた指示出力Ｏが外部システムＧ３に与えられる。これらの指示は資材と作業員の配置、作業（運搬）指示である資材配置指示であり、あるいは作業員の配置指示である作業指示といったものである。
　図７について以上述べたように、ここではインシデント対処システム１による台風の事前配置のフローを示している。インシデント対処システム１による台風の事前配置では、台風が来る前に、台風による電力流通設備等の被害予測を行い（図７中（０））、作業員や資材を適切な拠点に配置する事前配置計画を策定する（図７中（１））。この事前配置計画が適切かシミュレータ等で検証し（図７中（２））、作業員や資材を管理するＥＡＭやＦＳＭ等の外部システムに指示を行い、適切な時点で「事前配置」を実行する。
　図８は、図１におけるコンポーネント間の入力Ｉｎと出力Ｏｕｔの事例を整理したものである。まずデータ取得・収集における処理ステップＳ５におけるコンポーネントは、外部システムからデータ取得し蓄積する場合に、データ取得・収集コンポーネント無しに、直接、予測コンポーネントが、外部システムから取得する構成とすることも可能である。
出力Ｏｕｔとしては、気象予測サーバ、ＥＡＭ、ＦＳＭが備える各情報である。
　予測における処理ステップＳ６におけるコンポーネントは、入力Ｉｎについて気象予測サーバから台風進路予測ごとの各地点の風速予測、各地点の風向予測、各地点の雨量予測等であり、ＥＡＭから設備種類（電柱、鉄塔他）、設備設置場所等の情報を得る。また出力Ｏｕｔとしては、設備被害予測として、電柱被害（倒壊）予測、鉄塔被害予測等を与える。
　計画生成における処理ステップＳ７におけるコンポーネントは、入力Ｉｎに関して設備被害予測では、電柱被害予測、鉄塔被害予測、ＥＡＭ、ＦＳＭでは作業員情報（作業員ＩＤ、現所在、資格、割当タスク状況）、資材情報（資材ＩＤ、資材種類、諸元、現所在、割当タスク状況等）である。また出力Ｏｕｔに関して、作業員・資材配置計画として、作業員／資財情報（作業員ＩＤ／資財ＩＤ、配置場所、配置日時等）である。
　検証評価における処理ステップＳ８におけるコンポーネントは、入力Ｉｎに関して作業員・資材配置計画として、作業員／資財情報（作業員ＩＤ／資財ＩＤ、配置場所、配置日時等）である。また出力Ｏｕｔに関して、計画検証結果がＯＫ／ＮＧである。
　指示における処理ステップＳ９におけるコンポーネントは、入力Ｉｎに関して計画検証結果がＯＫ／ＮＧであり、また出力Ｏｕｔに関して、作業員・資材配置指示について作業員／資財情報（作業員ＩＤ／資財ＩＤ、配置場所、配置日時等）である。
　実施例２では台風の場合を例示したが、同様のことは、他のリスクに対しても適宜リスクに合わせた入力や処理内容にすることで、インシデント対策が実現可能であることは言うまでもない。
　図９は、台風に対するプレイブック例を示す図である。縦軸にデータ取得収集段階（Ｓ５）、予測段階（Ｓ６）、計画生成段階（Ｓ７）、検証評価段階（Ｓ８）、実行段階を記述し、かつ横軸にこれら各段階でのコンポーネントｔ１、入力データｔ２、出力データｔ３、特記事項ｔ４、設定情報ｔ５などを例示している。
　なおＣｏｌｌｅｃｔ＿ｔｙｐｈｏｏｎ＿気象庁．ｐｙおよびＣｏｌｌｅｃｔ＿ｔｙｐｈｏｏｎ＿ＮＡＡ．ｐｙは収集段階で使用するコンポーネントの名称、ｐｒｅｄｉｃｔ．ｐｙは、予測段階で使用するコンポーネントの名称、Ｐｌａｎ＿ｇｅｎｅｒａｔｏｒは計画段階で使用するコンポーネントの名称、ｗｏｒｋｆｏｒｃｅ＿ｓｉｍｕｌａｔｏｒ１およびｗｏｒｋｆｏｒｃｅ＿ｓｉｍｕｌａｔｏｒ２は検証段階で使用するコンポーネントの名称、→Ｗｏｒｋｏｒｄｅｒ．ｐｙは実行段階で使用するコンポーネントの名称である。
　これにより、生成されるワークフローの生成例としては、Ｃｏｌｌｅｃｔ＿ｔｙｐｈｏｏｎ＿気象庁．ｐｙ→ｐｒｅｄｉｃｔ．ｐｙ→Ｐｌａｎ＿ｇｅｎｅｒａｔｏｒ→ｏｒｋｆｏｒｃｅ＿ｓｉｍｕｌａｔｏｒ２→Ｗｏｒｋｏｒｄｅｒ．ｐｙの順に実行されるものとされる。なお、同様のものが他のリスクに対しても同様の考え方で設定されている。
　実施例１で述べた基本的な考え方を、図６を参照して台風の事例で整理して述べるならば、以下のようである。ここではまず、台風の事前配置の概念検証段階において、台風の事前配置に対応するプレイブックを定義する。
　このプレイブックには、被害予測や、被害予測に基づく作業員や資材の配置計画の生成、生成した計画の検証を行うコンポーネントから成る、台風の事前配置を実行するためのワークフローの雛形が記述されている。
　ワークフロー生成の処理ブロックにより、プレイブックを基に、個別インシデントに対応した情報を、気象情報サーバや、作業員や資材を管理するＥＡＭやＦＳＭなどの外部システムから取得し、データの受け渡しも含めたワークフローを生成する。
　生成したワークフローを、ワークフローエンジン（オーケストレーター）により順次実行し、最後は、ＥＡＭやＦＳＭに対し指示を発行することで、台風の事前配置のオペレーショナルプロセスを実現する。
　被害予測コンポ―ネントでは、風向・風速や累積雨量等の各種気象関連データより、電力流通設備の被害予測を行う。
　リソース割当計画策定コンポーネントでは、被害予測を基に、作業員や資材といったリソースを、どの拠点からどの拠点へ移動させ事前配置するかの計画を策定する。
　検証コンポーネントでは、シミュレータを用い、策定した計画の実現性や妥当性の評価・検証を行う。
　検証の結果、問題無ければ、作業員や資材を管理するＥＡＭやＦＳＭ等の外部システムにワークオーダなどとして指示を行い、適切な時点で「事前配置」を実行する。
　なお、プレイブックから生成される処理ワークフローに含まれるコンポーネントは、与えられたＫＰＩ等によって変わる場合がある。例えば、検証・評価を行うシミュレータについて、リソースに余裕を持った計画になっているかという観点で検証するもの、コスト観点で検証するものなど、判断の観点（重みづけ）が異なるものが考えられる。
　なお、指定された場所によって、コンポーネントが切り替わるケースが考えられ、例えば場所が違う場合に、電力系統に対する被害予測だけではなく、都市部、工業地帯、郊外、田舎といった地域特性に応じて重要視する点が異なる。コンテキストによっても、コンポーネントが変わる。
　例えば、事前配置の計画の算出ロジックが異なることが想定されるため、計画策定のコンポーネントが、エリアによって、切り替わるなど。電柱がたくさん倒れそうなところに手厚く事前配置することが良いケースと、電柱があまり倒れないことが予想される場所でも、重要エリアであれば手厚く事前配置する、などである。
１：インシデント対処システム、２：ワークフローエンジン、２１：予測コンポーネント、２２：計画生成コンポーネント、２３：シミュレータコンポーネント、ＤＢ：プレイブックデータベース、Ｇ１、Ｇ２、Ｇ３：外部システム

Claims (13)

  1. 　個別のインシデントに対応するインシデント対処システムであって、
    　リスクにおけるインシデントへの対処フローである処理ワークフローを、各リスクの種類ごとに、プレイブックとして保持するプレイブックＤＢと、
    　発生したまたは発生予兆のあるインシデント情報を取得し、各リスクの種類ごとに作成された前記プレイブックの中から、前記インシデントに対応する前記プレイブックを抽出するプレイブック選択部と、
    　抽出した前記プレイブックを基に、個別のインシデントに対応した処理ワークフローを生成するワークフロー生成部と、
    　前記インシデントに対する処理を出力するワークフローエンジン部と、を有することを特徴とするインシデント対処システム。
  2. 　請求項１に記載のインシデント対処システムであって、
    　前記ワークフローエンジン部は、
    　発生した又は発生予兆のあるインシデント情報を取得し、被害状況を予測し、被害状況とインシデントの種類に基づいて、前記インシデントに対応する前記プレイブックを抽出する現状把握/予測部と、
    　抽出した前記プレイブックを基に、個別のインシデントに対応した処理ワークフローを生成し、前記処理ワークフローにより対処計画案を作成し、生成した対処計画案が実行可能かどうかを評価する計画生成/評価部と、
    　前記評価に基づいて、前記インシデントに対する対処計画案を出力する指示/実行部と、を有することを特徴とするインシデント対処システム。
  3. 　請求項１に記載のインシデント対処システムであって、
    　前記プレイブックは、リスクにおける優先目標の重み付け情報であることを特徴とするインシデント対処システム。
  4. 　請求項１に記載のインシデント対処システムであって、
    　前記ワークフローエンジン部は、処理ワークフローにおける個々の処理プロセスを処理する処理ブロックとして保持することを特徴とするインシデント対処システム。
  5. 　請求項１に記載のインシデント対処システムであって、
    　前記処理ワークフローは、各インシデントに対する予測段階、計画段階、検証評価段階を含むことを特徴とするインシデント対処システム。
  6. 　請求項５に記載のインシデント対処システムであって、
    　前記処理ワークフローは、さらにデータ収集段階、指示段階を含むことを特徴とするインシデント対処システム。
  7. 　請求項１に記載のインシデント対処システムであって、
    　前記ワークフロー生成部は、個別のインシデントに対応した処理ワークフローを生成するにあたり、前記処理ワークフローにおける個々の処理プロセスで使用する前提条件もしくは優先目標を変更することを特徴とするインシデント対処システム。
  8. 　請求項４に記載のインシデント対処システムであって、
    　前記ワークフロー生成部は、個別のインシデントに対応した処理ワークフローを生成するにあたり、前記処理ブロックにおける処理条件を変更することを特徴とするインシデント対処システム。
  9. 　請求項１に記載のインシデント対処システムであって、
    　リスクの種類ごとに、当該リスクのインシデントへの対処を生成する処理ワークフローを、標準処理ワークフローに沿い類型化して記述するプレイブックを予め作成してプレイブックＤＢに保有するにあたり、過去に生じた複数のインシデントの事例を参照して作成しておくことを特徴とするインシデント対処システム。
  10. 　個別のインシデントに対応するインシデント対処方法であって、
    　リスクにおけるインシデントへの対処フローである処理ワークフローを、各リスクの種類ごとに、プレイブックとして保持し、
    　発生したまたは発生予兆のあるインシデント情報を取得し、各リスクの種類ごとに作成された前記プレイブックの中から、前記インシデントに対応する前記プレイブックを抽出し、
    　抽出した前記プレイブックを基に、個別のインシデントに対応した処理ワークフローを生成し、
    　前記インシデントに対する処理を出力することを特徴とするインシデント対処方法。
  11. 　請求項１０に記載のインシデント対処方法であって、
    　前記インシデントに対する処理を出力するために、
    　発生した又は発生予兆のあるインシデント情報を取得し、被害状況を予測し、被害状況とインシデントの種類に基づいて、前記インシデントに対応する前記プレイブックを抽出し、
    　抽出した前記プレイブックを基に、個別のインシデントに対応した処理ワークフローを生成し、前記処理ワークフローにより対処計画案を作成し、生成した対処計画案が実行可能かどうかを評価し、
    　前記評価に基づいて、前記インシデントに対する対処計画案を出力することを特徴とするインシデント対処方法。
  12. 　請求項１０に記載のインシデント対処方法であって、
    　前記プレイブックは、リスクにおける優先目標の重み付け情報であることを特徴とするインシデント対処方法。
  13. 　請求項１０に記載のインシデント対処方法であって、
    　個別のインシデントに対応した処理ワークフローを生成するにあたり、前記処理ワークフローにおける個々の処理プロセスで使用する前提条件もしくは優先目標を変更することを特徴とするインシデント対処方法。
PCT/JP2023/004268 2022-09-01 2023-02-08 インシデント対処システム並びにインシデント対処方法 WO2024047895A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022139130A JP2024034697A (ja) 2022-09-01 2022-09-01 インシデント対処システム並びにインシデント対処方法
JP2022-139130 2022-09-01

Publications (1)

Publication Number Publication Date
WO2024047895A1 true WO2024047895A1 (ja) 2024-03-07

Family

ID=90099097

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/004268 WO2024047895A1 (ja) 2022-09-01 2023-02-08 インシデント対処システム並びにインシデント対処方法

Country Status (2)

Country Link
JP (1) JP2024034697A (ja)
WO (1) WO2024047895A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09171529A (ja) * 1995-12-20 1997-06-30 Fujitsu Ltd 動的計画管理装置及び動的計画管理方法
WO2020090513A1 (ja) * 2018-11-02 2020-05-07 日本電信電話株式会社 監視保守方法、監視保守装置及び監視保守プログラム
JP2022069949A (ja) * 2020-10-26 2022-05-12 株式会社日立製作所 優先度判定装置、優先度判定方法及び優先度判定システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09171529A (ja) * 1995-12-20 1997-06-30 Fujitsu Ltd 動的計画管理装置及び動的計画管理方法
WO2020090513A1 (ja) * 2018-11-02 2020-05-07 日本電信電話株式会社 監視保守方法、監視保守装置及び監視保守プログラム
JP2022069949A (ja) * 2020-10-26 2022-05-12 株式会社日立製作所 優先度判定装置、優先度判定方法及び優先度判定システム

Also Published As

Publication number Publication date
JP2024034697A (ja) 2024-03-13

Similar Documents

Publication Publication Date Title
Fang et al. Optimum post-disruption restoration under uncertainty for enhancing critical infrastructure resilience
Nurre et al. Restoring infrastructure systems: An integrated network design and scheduling (INDS) problem
Mendonça et al. Factors underlying organizational resilience: The case of electric power restoration in New York City after 11 September 2001
Vera-Baquero et al. Business process improvement by means of Big Data based Decision Support Systems: a case study on Call Centers
Backman et al. IoT-based interoperability framework for asset and fleet management
Li et al. Designing an agent-based model of SMEs to assess flood response strategies and resilience
Brüning et al. Collaborative recovery from supply chain disruptions: characteristics and enablers
Pinta Disaster recovery planning as part of business continuity management
WO2024047895A1 (ja) インシデント対処システム並びにインシデント対処方法
Kodaka et al. Industrial area business continuity management exercise: An experimental validation for flood in Thailand
Romano et al. Facing the “during” phase in crisis management: An incremental adaptive launching process
Antonio et al. Operational risk and supply chain risk management
Zheng et al. Cycle time reduction in assembly and test manufacturing factories: A KPI driven methodology
Patil et al. Efficiency of Internet of Things (IoT)-Enabled Systems in Reducing Construction Cost
Gunawan et al. Improving digital forensic readiness in DevOps context: Lessons Learned from XYZ Company
Tadano et al. Road repair sequencing for disaster victim evacuation
Ghernouti-Hélie et al. A multi-stage methodology for ensuring appropriate security culture and governance
Johnson et al. Risk Description Augmenting a Business Process Model
Gotcheva et al. 2.2 Management principles and safety culture in complex projects (MAPS)
Esquivel-Vargas et al. BACRank: ranking building automation and control system components by business continuity impact
Houthuysen Deployment and Operation of a Business-Wide EMS
Sharkey et al. Interdependent network restoration: Modeling restoration interdependencies and evaluating the value of information-sharing
Blackburn Critical Infrastructure Assessments for Local Governments: An Examination of New Tools and Methodology Created for Local Authorities
Andreasik The Architecture of the Intelligent Case-Based Reasoning Recommender System (CBR RS) Recommending Preventive/Corrective Procedures in the Occupational Health and Safety Management System in an Enterprise
Wong et al. Effective e-Government process monitoring and interoperation: A case study on the removal of unauthorized building works in Hong Kong

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23859669

Country of ref document: EP

Kind code of ref document: A1