異常検知装置、監視制御システム、異常検知方法、プログラムおよび記録媒体
【課題】 重要インフラストラクチャ等における制御システムをセキュリティ保護すること。
【解決手段】本発明の異常検知装置１５０は、制御ネットワーク１３０内で発生したイベント情報を受信して、制御システム１０２を含むリソース（１１０，１２０など）およびプロセス間の依存関係を維持する構成管理データベース１７０に照会し、イベント情報に関わるリソースが属するグループを識別する識別部１５２と、異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部１６０と、１以上のポリシを適用する上で必要となるグループ関連情報を取得してイベント情報に付加する付加部１５６と、１以上のポリシに対しイベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する決定部１５８とを含み、制御ネットワーク１３０の異常を検知する。
【解決手段】本発明の異常検知装置１５０は、制御ネットワーク１３０内で発生したイベント情報を受信して、制御システム１０２を含むリソース（１１０，１２０など）およびプロセス間の依存関係を維持する構成管理データベース１７０に照会し、イベント情報に関わるリソースが属するグループを識別する識別部１５２と、異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部１６０と、１以上のポリシを適用する上で必要となるグループ関連情報を取得してイベント情報に付加する付加部１５６と、１以上のポリシに対しイベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する決定部１５８とを含み、制御ネットワーク１３０の異常を検知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報セキュリティ技術に関し、より詳細には、重要インフラストラクチャ等における制御システムをセキュリティ保護するための異常検知装置、監視制御システム、異常検知方法、プログラムおよび記録媒体に関する。
【背景技術】
【０００２】
現代社会は、電力、ガス、水道、鉄道、金融、プラント、パイプラインなど様々なインフラストラクチャの上に成り立っている。上述のような社会的に重要なインフラストラクチャの制御システムは、その機能が停止すれば、社会経済に大きな影響を及ぼすおそれがあるため、旧来、外部から隔離され、仕様も公開されないクローズド・システムでの稼働を前提として設計され、運用されてきた。ところが、近年、接続性、生産性の向上、経営判断の効率化などの経営面からの要請により、上述のような旧来システムから、オープン・システムに移行しつつある。制御システムの専用製品や独自の構造は、汎用製品やＴＣＰ／ＩＰ等の標準プロトコルに置き換えられ始め、ネットワークを介した制御システム間の連携、情報処理システムとの連携も進んでいる。
【０００３】
しかしながら、オープン化が進むにつれ、制御システムは、汎用製品に存在する脆弱性、不正アクセス、情報漏洩、ウィルス、ワームなど、情報処理システムで発生している様々な脅威に晒される。上述のような重要なインフラストラクチャは、万が一攻撃を受けた場合、その影響が大規模かつ広範囲となる。また、産業制御システム（Industrial Control System）は、プラントやパイプラインにおけるポンプ、バルブなどアクチュエータを制御しているため、その誤作動は、ときには人的被害や環境破壊をもたらす。したがって、制御システムのオープン化に伴い、このような脅威から制御システムを保護するための高度なセキュリティを実現することが望ましい。また、万が一上述のような脅威が疑われる事態が発生した場合は、その異常を迅速に検知して適切な対策を講じることが望ましい。
【０００４】
上記脆弱性、不正アクセス等は、情報処理システムにおいても既に発生している問題であることから、情報処理システムで適用されているセキュリティ技術を導入することも、ある程度有用であるとも考えられる。情報処理システムにおけるセキュリティ技術としては、例えば、特許第４５２１４５６号公報（特許文献１）は、被管理情報処理装置の動作をコントロールするためのセキュリティ・ポリシを被管理情報処理装置に配布する情報処理装置を開示する。また、特開２００７−２７４０２７号公報（特許文献２）は、遠隔操作による回復サービスを容易に導入可能なリモートオペレーションシステムを開示する。しかしながら、産業制御システムは、情報処理システムとは異なる性質があり、情報処理システムで行われているセキュリティ技術を適用するだけでは充分ではない場合があった。上述のような脅威が疑われる異常を、迅速に検知して対策を講じることができない場合があった。
【０００５】
ところで、近年、ＩＴサービスにおいて、管理対象のコンポーネントに関する情報を一元的に管理し、必要なときに必要な情報を提供することを目的として、構成管理データベース（ＣＭＤＢ：Configuration Management Database）が注目されている。ＣＭＤＢは、サービス管理の対象となるハードウェア、ソフトウェア等のリソース、ドキュメント、インシデント履歴情報、さらには人的資源を含めて各構成要素を構成アイテム（ＣＩ；Configuration Item）として維持管理し、把握できるように支援するものである（特許文献３，特許文献４）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特許４５２１４５６号公報
【特許文献２】特開２００７−２７４０２７号公報
【特許文献３】特開２００９−２４５０２９号公報
【特許文献４】特開平９−６９０８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、上記従来の制御システムにおける問題点を鑑みてなされたものであり、本発明は、上述した構成管理データベースを利用し、制御システムにおけるデバイス、機材、センサ、アクチュエータなどの構成要素間の依存関係を考慮し、構成要素間でネットワークを流れるデータ・トラフィックから、異常が疑われる振る舞いを検知し、迅速に対策アクションを起こすことができる、異常検知装置、監視制御システム、異常検知方法、プログラムおよび記録媒体を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、上記従来技術の課題を解決するために、以下の特徴を有する異常検知装置および該異常検知装置を含む監視制御システムを提供する。本発明の異常検知装置は、制御ネットワーク内で発生したイベント情報を受信して、制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別する。異常検知装置は、異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部を参照して、１以上のポリシを読み出す。異常検知装置は、１以上のポリシを適用する上で必要となるグループに関連する情報を取得し、イベント情報に付加し、情報の豊富化を行う。そして、異常検知装置は、１以上のポリシに対しイベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する。
【０００９】
上記構成管理データベースは、プロセスおよびリソースを構成アイテムとして維持し、プロセス間、リソース間、プロセスおよびリソース間の関係により依存関係をも記述することができる。上記取得されるグループに関連する情報は、上記構成管理データベースまたはプロセス管理システムなどの外部システムから取得されるグループに属するプロセスの状況情報、上記グループに属するプロセスの属性情報および上記グループに属するリソースの属性情報またはこれらの少なくとも１つの情報を含むことができる。上記条件は、グループに関連する情報を条件式に含むことができる。
【発明の効果】
【００１０】
上記構成によれば、上述した構成管理データベースを利用することで、制御ネットワークにおけるプロセス、リソース間の依存関係を考慮して制御ネットワーク内の現在の状況を解析し、リソース・グループ全体の振る舞いとして異常の疑われる状況をも好適に検知し、さらに適切な対策アクションおよび該アクションを実施させる対象を決定することができる。したがって、アクチュエータ等のリソース単独の動きからは容易に判別し得ない異常を好適に検知することが可能となり、ひいては、産業制御システムのオープン化に伴うセキュリティ低下を好適に防止することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態による産業システムの概略構成を示す図。
【図２】構成管理データベースと連携した異常検知に基づく監視制御処理で使用されるデータを説明する図。
【図３】構成管理データベース内に構築される構成アイテム間の関係を模式的に表した図。
【図４】構築された構成管理データベースのデータ構造を例示する図。
【図５】プロセス管理システムが管理するプロセスに関するデータ構造を例示する図。
【図６】本発明の実施形態による解析エンジンが実行する、異常検知処理を示すフローチャート。
【図７】セキュリティ・ポリシのデータ構造を例示する図。
【図８】他のセキュリティ・ポリシのデータ構造を例示する図。
【図９】他のセキュリティ・ポリシのデータ構造を例示する図。
【図１０】他のセキュリティ・ポリシのデータ構造を例示する図。
【図１１】さらに他のセキュリティ・ポリシのデータ構造を例示する図。
【発明を実施するための形態】
【００１２】
以下、本発明について実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。以下に説明する実施形態では、１以上の制御システムを含む制御ネットワークの異常を検知する異常検知装置、および監視制御システムとして、制御ネットワークの異常を検知する解析エンジン、および上記解析エンジンとセキュリティ・ゲートウェイとを含む産業システムを例として説明する。
【００１３】
以下、図１を参照して、本発明の実施形態による産業システムの全体構成について説明する。図１は、本発明の実施形態による産業システムの概略構成を示す図である。図１に示す産業システム１００は、制御ネットワーク１３０に接続される、制御システム１０２、コンソール・システム１０４、保守システム１０６、分析システム１０８、機材１１０およびデバイス１２０を含む。産業システム１００は、例えば、農業、金融、化学、商業施設、ダム、防衛産業基盤、緊急サービス、エネルギー、政府施設、情報技術、原子炉、物流、公共衛生、通信、輸送、水道、重要製造業などにおけるシステムである。
【００１４】
制御システム１０２は、機材１１０およびデバイス１２０のシステム監視、プロセス制御を行うシステムであり、例えば、地理的に分散した制御対象を遠隔集中監視し、制御データの収集を行うＳＣＡＤＡ（Supervisory Control And Data Acquisition）、分散制御システム（ＤＣＳ：Distributed Control System）などのホストコンピュータをいう。制御システム１０２には、その他、プログラマブル・ロジック・コントローラ（ＰＬＣ）や遠隔監視制御装置（ＲＴＵ）を含めてもよい。コンソール・システム１０４は、対象システムのデータをオペレータに提示し、オペレータがシステムを監視し制御できるようにするＨＭＩ（ヒューマン・マシン・インタフェース）である。保守システム１０６は、機材１１０およびデバイス１２０等を遠隔的に保守点検を行うためのシステムである。分析システム１０８は、センサ端末からゲートウェイを通して集計したデータに対して相関モデル等を適用し、統計的な解析に基づいて異常を検出する分析システムである。
【００１５】
機材１１０およびデバイス１２０は、共に、センサ１１２，１２２やアクチュエータ１１４，１２４などのフィールド機器にセンサバスを介して接続するセンサ端末である。なお、機材１１０およびデバイス１２０の分類は、任意であり、産業システム１００の運用者が適宜決定すればよい。説明する実施形態では、機材１１０は、主として、単独で機能する装置をいうものとし、デバイス１２０は、主として他の機材１１０を装備することが可能な装置をいうものとする。上記センサ１１２，１２２としては、特に限定されるものではないが、温度センサ、湿度センサ、流量計、水位計、照度計、電力計、人感知センサなどの種々の計測器を挙げることができる。上記アクチュエータ１１４，１２４としては、特に限定されるものではないが、バルブ、コンプレッサ、その他モータや能動的に機能する装置を挙げることができる。
【００１６】
制御ネットワーク１３０は、特に限定されるものではないが、フィールド・ネットワーク、コントロール・ネットワーク、制御情報ネットワークを含み、制御ネットワーク１３０上には、各種信号やデータが伝送される。本発明の実施形態による産業システム１００では、制御ネットワーク１３０には、さらに、１以上のセキュリティ・ゲートウェイ１４０が接続される。セキュリティ・ゲートウェイ１４０は、制御ネットワーク１３０のトラフィックを監視しており、異常を検知するため制御ネットワーク１３０内で発生したイベントを拾い上げる。セキュリティ・ゲートウェイ１４０は、解析エンジン１５０に接続されており、拾い上げたイベントに関する信号およびデータを適宜フォーマット変換し、詳細な解析を行わせるため解析エンジン１５０に渡す。
【００１７】
解析エンジン１５０は、受け取ったイベント情報を解析して、制御ネットワーク１３０内で発生した異常の検知を試みる。産業制御システム（ＩＣＳ）では、制御ネットワーク１３０内の機材、デバイス、センサ、アクチュエータ等の個別要素の動作を監視しても、制御ネットワーク１３０内で発生する異常を発見することが難しい場合がある。例えば、あるアクチュエータが、使用されておらず、またその使用の計画さえないにもかかわらず、動作している場合は、不正侵入等何らかの異常を疑うべきである。しかしながら、アクチュエータ自体が通常の動作範囲で動いている限り、アクチュエータの動きからは、その不穏な動きを異常として検知することは難しい。つまり、制御システムでは、一般的な情報処理システムと異なり、その異常を正しく検知するためには、上記デバイス、機材、センサ、アクチュエータ等のリソース間の依存関係を把握した上で、リソース間を流れるデータ・トラフィックから異常の疑いのあるイベントを拾い上げる必要がある。
【００１８】
そこで、本発明の実施形態による産業システム１００では、解析エンジン１５０は、構成管理データベース（ＣＭＤＢ）１７０と連携して、機材、デバイス、センサ、アクチュエータ等の依存関係を考慮した上でイベント情報を解析する。イベント解析の結果、異常が疑われる場合には、解析エンジン１５０は、推奨される対策アクションを決定し、セキュリティ・ゲートウェイ１４０に通知し、セキュリティ・ゲートウェイ１４０に対策アクションを実行させる。
【００１９】
以下、ＣＭＤＢ１７０と連携した異常検知に基づく監視制御の構成について、より詳細に説明する。セキュリティ・ゲートウェイ１４０は、より詳細には、監視部１４２を含み構成される。監視部１４２は、制御ネットワーク１３０内を伝送するセンサデータやセンサ信号、アクチュエータに対する操作コマンドや制御信号などのトラフィックを監視し、所定フォーマットのイベント情報を生成し、解析エンジン１５０に渡す。制御ネットワーク１３０では、多種多様な形式でデータおよび信号が伝送されることが想定されるため、監視部１４２は、種々のデータ形式から統一的なデータ形式へ変換するフォーマット変換器としての機能を備えることが好ましい。
【００２０】
好適な実施形態では、監視部１４２は、多種多様な形式で表現されたデータおよび信号から、送信元を識別する送信元ＩＤ（IDentifier）と、宛先を識別する宛先ＩＤと、イベントのタイプを識別するイベントタイプと、上記センサデータや操作指令であるイベントデータとを含む所定形式のイベント情報を生成することができる。イベントタイプとは、センサデータであるか、操作命令であるかなど、イベントの型を表す。イベントデータは、一般には、センサ１１２，１２２からの出力であれば、センサデータを含み、アクチュエータ１１４，１２４に対する操作命令であれば、そのコマンドおよびその引数を含む。
【００２１】
解析エンジン１５０は、より詳細には、グループ識別部１５２と、イベント解析部１５４とを含み構成される。グループ識別部１５２は、セキュリティ・ゲートウェイ１４０の監視部１４２からイベント情報を受け取り、ＣＭＤＢ１７０に照会を行う。ＣＭＤＢ１７０は、構成アイテム（ＣＩ；Configuration Item）とその重要な属性の詳細を維持し、さらに構成アイテム間の関係を管理することで、管理対象に関する情報の統合された構成管理を実現する。構成アイテム（ＣＩ）は、ＣＭＤＢ１７０内の情報を管理するための基本単位であり、本発明の実施形態においては、構成アイテムは、主としてプロセスおよびリソースに分類される。
【００２２】
上記構成アイテムのうちの「リソース」（以下、「リソース」の構成アイテムをリソースＣＩという。）は、上記制御システム、機材、デバイス、センサ、アクチュエータ、ネットワーク機器、コンソール・システム、保守システム、分析システムなどの構成要素、その他フロアやビルディングなどの施設や設備を含むことができる。上記構成アイテムのうちの「プロセス」（以下、プロセスの構成アイテムをプロセスＣＩという。）は、上記リソースを使用するか、または使用する計画がある（以下、使用計画を含め「使用する」という。）処理または作業を意味する。プロセスの粒度は、特に限定されるものではなく、プロジェクト管理システムにおけるプロジェクトを構成するサブプロジェクト、ワークフロー管理システムにおけるワークフローを構成する工程のように、プロセスが他のプロセスを含む関係にあってもよい。プロセスとしては、定期点検、通常の製造工程、インシデント対応、緊急対応などを挙げることができる。
【００２３】
グループ識別部１５２は、上記イベント情報に含まれる送信元ＩＤおよび宛先ＩＤを用いて、ＣＭＤＢ１７０に照会し、当該イベント情報に関わる送信元または宛先のリソースが属するリソース・グループを識別するグループＩＤを取得し、上記イベント情報に付す。ここで、リソース・グループとは、リソースを使用するプロセス、該プロセスが使用する他のリソースなど、ＣＭＤＢ１７０内に定義される依存関係を辿ることでグループ化されるリソース群をいう。なお、ＣＭＤＢ１７０内でリソース・グループが管理されていない実施形態では、上記グループＩＤに代えて、グループに属するリソースのＩＤリストを用いても良い。いずれの場合も、グループを識別する情報（以下、グループＩＤおよびリソースのＩＤリストをまとめてグループ識別情報と参照する。）がイベント情報に付される。グループ識別情報が付されたイベント情報（以下、グループ識別済みイベント情報という。）は、グループ識別部１５２からイベント解析部１５４へ渡される。
【００２４】
イベント解析部１５４は、上記グループ識別済みイベント情報をグループ識別部１５２から受け取り、このグループ識別済みイベント情報に含まれる情報を使用して、所与のセキュリティ・ポリシに従いマッチング処理およびアクション決定処理を実行する。イベント解析部１５４は、より詳細には、情報付加部１５６と、アクション決定部１５８とを含む。上記セキュリティ・ポリシは、制御ネットワーク１３０において異常を疑うべき状況を規定するマッチング条件と、その疑われる異常に対抗するための１以上の対策アクションとを対応付けるユーザ定義データである。上記セキュリティ・ポリシは、上記マッチング条件を記述するマッチング記述部と、それに対応付けられる１以上の対策アクションを記述するアクション記述部とを含み、１以上のセキュリティ・ポリシがセキュリティ・ポリシ記憶部１６０に管理される。マッチング条件は、好適には、送信元および宛先リソースの依存関係に関連した条件を含むことができる。
【００２５】
情報付加部１５６は、マッチング記述部の評価のために必要な情報がある場合、外部システムに対し問い合わせを行い、グループ識別済みイベント情報をさらに豊富化（enrichment）させることができる。ここで豊富化のため付加される情報としては、グループに関連する種々の情報（以下、グループ関連情報と参照する。）、例えばグループ内の各リソースの属性情報、グループ内のプロセスの属性情報や状況情報を挙げることができる。情報付加部１５６は、また、対策アクションを決定する際に実施対象を選択するために必要な情報がある場合、外部システムに問い合わせを行い、対策アクション決定の際に必要な情報を付加し、グループ識別済みイベント情報を豊富化させることができる。
【００２６】
上述した外部システムとしては、上記ＣＭＤＢ１７０、プロセス管理システム１８０、その他、資産管理システム、ヒストリアン、プロジェクト管理システム、スケジューラなどの種々のシステムを採用することができる。なお、図１には、プロセス管理システム１８０が例示されている。プロセス管理システム１８０は、産業システム１００におけるプロセス定義の実体を管理し、プロセスのリアルタイムなステータスを管理する。ＣＭＤＢ１７０においても、プロセスが構成アイテムとして管理することができるが、動的に変化するステータス値は、プロセス管理に特化したプロセス管理システム１８０で管理される方がより好ましい。このため、説明する実施形態では、プロセス管理システム１８０がプロセス定義の実体を管理し、その実体定義に応じてＣＭＤＢ１７０内にプロセスＣＩが定義される構成をとる。
【００２７】
アクション決定部１５８は、上記セキュリティ・ポリシに対し、上記グループ識別済みイベント情報を適用して、推奨される対策アクションを導出する。本発明の実施形態によるアクション決定部１５８は、好ましくは、豊富化されたグループ識別済みイベント情報に含まれる依存関係を表す情報を使用して、依存関係を考慮した上で対策アクションを導出することができる。アクション決定部１５８は、より具体的には、上記セキュリティ・ポリシのマッチング記述部を評価し、記述されたマッチング条件に合致するポリシが見つかれば、その条件に対応するアクション記述部を読み出し、１以上の対策アクションを決定する。
【００２８】
上記マッチング条件は、特に限定されるものではないが、イベント情報の送信元リソースに関連するプロセスに対する条件式、イベント情報の宛先リソースに関連するプロセスに対する条件式、イベント情報の送信元リソースおよび宛先リソースに関連する両プロセスに対する条件式、イベント情報のイベントタイプに対する条件式、またはイベント情報のイベントデータに対する条件式を含むことができる。また、上記条件式は、許容される状況の範囲やアクションの範囲を規定するリソース属性情報やプロセス状況情報を引用する形式を採用することができる。
【００２９】
アクション決定部１５８は、また、対策アクションの決定に先立って、上記グループ識別済みイベント情報を用いて、対策アクションの実施対象となるリソースを選択する処理を行うことができる。実施対象となるリソースは、例えば、イベント情報の送信元リソース、宛先リソース、送信元リソース・グループ内の全部または一部のリソース、宛先リソース・グループ内の全部または一部のリソース、その他外部メールサーバなどの外部システムとすることができる。
【００３０】
アクション決定部１５８は、対策アクションが決定されると、その対策アクションをセキュリティ・ゲートウェイ１４０に通知する。セキュリティ・ゲートウェイ１４０は、アクション実施部１４４を含み、アクション実施部１４４は、解析エンジン１５０から通知された対策アクションを実際に実施する。実施され得る対策アクションとしては、特に限定されるものではないが、トラフィックのブロッキング、トラフィックの変更、新規トラフィックの発行、アラート通知を挙げることができる。
【００３１】
セキュリティ・ゲートウェイ１４０は、トラフィックからイベント情報を生成した際に、そのトラフィックを一旦ペンディングし、アクション実施部１４４は、解析エンジン１５０による解析の完了を待つ。対策アクションとしてトラフィックのブロッキングが通知されたときは、アクション実施部１４４は、対応するトラフィックをブロックする。対策アクションとしてトラフィックの変更が通知された場合は、アクション実施部１４４は、得られた対策アクションに記述された内容でペンディング中のトラフィックを変更または修正して、ペンディングを解除する。対策アクションとして新規トラフィックの発行が通知された場合、アクション実施部１４４は、対象リソースに対して停止命令など新規トラフィックを発行する。
【００３２】
以下、図２〜図５を参照しながら、ＣＭＤＢ１７０と連携した異常検知に基づく監視制御処理についてより詳細に説明する。図２は、ＣＭＤＢ１７０と連携した異常検知に基づく監視制御処理で使用されるデータを説明する図である。図２に示すイベント情報２００は、セキュリティ・ゲートウェイ１４０の監視部１４２から解析エンジン１５０に渡されるイベント情報を示す。イベント情報２００は、送信元リソースを識別する送信元ＩＤと、宛先リソースを識別する宛先ＩＤと、イベントタイプと、イベントデータとを含み構成される。送信元リソースおよび宛先リソースは、それぞれ、当該イベント情報の元となったトラフィック・データの送信元および宛先を指す。例えば、センサ１２２からのセンサ出力を制御システム１０２で受信する場合、センサ端末であるデバイス１２０を送信元とし、制御システム１０２を宛先としたトラフィック・データが、制御ネットワーク１３０内で発生する。このようなトラフィック・データがセキュリティ・ゲートウェイ１４０の監視部１４２により拾われ、イベント情報２００として解析エンジン１５０へ渡される。
【００３３】
グループ識別部１５２は、受け取ったイベント情報２００のうちの送信元ＩＤおよび宛先ＩＤを使用して、ＣＭＤＢ１７０にクエリを発行し、送信元リソースが属するグループのグループＩＤ（以下、送信元グループＩＤと参照する。）および宛先リソースが属するグループのグループＩＤ（以下、宛先グループＩＤと参照する。）を含む照会結果２０２を取得し、これをイベント情報２００に付加する。ここで、送信元リソースまたは宛先リソースがいずれのリソース・グループにも属していない場合には、照会結果２０２としてｎｕｌｌ値が取得される。
【００３４】
図３は、ＣＭＤＢ１７０内に構築される構成アイテム間の関係を模式的に表した図である。図３に示すように、ＣＭＤＢ１７０内には、１以上のプロセスＣＩおよび１以上のリソースＣＩ、並びにこれらの関係が定義される。例えば、プロセスＣＩインスタンス（「プロセスＡ」は、リソースＣＩインスタンス（「制御システムＡ」および「制御システムＢ」）に対し「ｕｓｅｄＢｙ」の関係が定義されており、これは「プロセスＡ」の実行時に「制御システムＡ」および「制御システムＢ」が使用される依存関係があることを表す。リソースＣＩインスタンス（「制御システムＡ」）は、リソースＣＩインスタンス（「デバイスＡ」）に対し「ｍａｎａｇｅｄＢｙ」の関係が定義されており、これは「デバイスＡ」が「制御システムＡ」に管理される依存関係があることを表す。その他のプロセスＣＩインスタンス、リソースＣＩインスタンスについても同様である。
【００３５】
なお、構成アイテム間の関係としては、図３に、使用関係「ｕｓｅｄＢｙ」、管理関係「ｍａｎａｇｅｄＢｙ」、必要関係「ｐｏｗｅｒｅｄＢｙ」、包含関係「ｃｏｎｔａｉｎｅｓ」を例示するが、これらに限定されるものではない。その他、「ａｓｓｉｇｎｓ」、「ｃａｎＵｓｅ」、「ｄｅｐｌｏｙｅｄＯｎ」、「Ｏｗｎｅｄ」、「ｒｕｎＡｔ」など種々の関係を定義することができ、ＣＭＤＢの実装により異なり、ユーザ定義も可能である。
【００３６】
図３には、さらに、２つのリソース・グループＡ，Ｂが示されている。リソース・グループＡは、制御システムＡ，Ｂ、デバイスＡ、機材Ａ，Ｂ、センサＡ，Ｂ，Ｃ，Ｄ、アクチュエータＡ，Ｂ，Ｃから構成されている。リソース・グループＢは、同様に、制御システムＣ、機材Ｃ、センサＥ、アクチュエータＤから構成されている。各リソース・グループに属するプロセスおよびリソースは、上述した構成アイテム間の関係によって直接的にまたは間接的に関連付けられたプロセスおよびリソースである。
【００３７】
例えばイベント情報の送信元または宛先リソースがデバイスＡであった場合、ＣＭＤＢ１７０は、グループ識別部１５２からの問い合わせに応答して、リソース・グループＡを識別するグループＩＤ、またはリソース・グループＡ内のリソースのＩＤリストを照会結果２０２に含めて回答する。上記リソース・グループＡ，Ｂは、事前に、またはグループ識別部１５２が照会する際に動的に定義することができる。リソース・グループの定義の際には、例えば「特定デバイスを利用しているプロセスとｕｓｅｄＢｙ関係があるリソース」というような条件のクエリを用いて、リソース・グループ内のＣＩの集合を得て、ＣＭＤＢ１７０内にグループをＣＩとして新規に登録することができる。
【００３８】
このようなＣＭＤＢ１７０内の構造は、ＣＭＤＢ１７０に対するマニュアル入力、ヒストリアンとの同期、資産管理システムからの通知、プロセス管理システム１８０からの定義の更新通知などの外部システムとの連携、またはディスカバリ機能やトラッキング機能による自動検出により構築される。なお、説明する実施形態では、ＣＭＤＢ１７０は、充分に短い時間間隔でディスカバリ機能およびトラッキング機能による自動検出を実施しており、さらに、上記外部システムとの連携によって適時に更新されており、ＣＭＤＢ１７０は、常に最新状態に維持されているものとする。本発明の実施形態による解析エンジン１５０は、構成アイテムとしてリソースに加えてプロセスが管理されるＣＭＤＢ１７０と連携することによって、上記プロセスを経由したリソース間の依存関係を考慮した異常検知を行う。
【００３９】
ここで、再び図２を参照する。グループ識別部１５２は、送信元グループＩＤおよび宛先グループＩＤを含む照会結果２０２を取得すると、それをイベント情報２００に付して、イベント解析部１５４へ渡す。イベント解析部１５４の情報付加部１５６は、グループ識別済みイベント情報２００，２０２を受け取ると、適宜、ポリシを適用する上で必要な情報の豊富化を行う。セキュリティ・ポリシ記憶部１６０には、１以上のポリシが記憶されており、イベント情報に対して各ポリシに適用されるため、ここでは、少なくともいずれかのポリシのマッチング記述部において条件式が定義されている属性情報等がすべて取得される。より具体的には、情報付加部１５６は、グループ識別済みイベント情報２００，２０２のうちの、送信元グループＩＤおよび宛先グループＩＤを使用して、ＣＭＤＢ１７０に照会して、送信元グループおよび宛先グループに関連する種々の属性情報を取得する。
【００４０】
以下、ＣＭＤＢ１７０のデータ構造を参照しながら、情報付加部１５６が取得する属性情報について説明する。図４は、構築されたＣＭＤＢ１７０のデータ構造を例示する図である。図４に示す構成アイテムテーブル２２０は、構成アイテムの名称を保管するフィールド２２２と、構成アイテムのカテゴリを保管するフィールド２２４と、構成アイテムの上記カテゴリをさらに細分化したモデルを保管するフィールド２２６と、属性フィールド２２８と、関係フィールド２３０とを含む。関係フィールド２３０は、当該構成アイテムに対して定義されている１以上の関係に関する情報を保管し、関係の種類と、当該構成アイテムの相手方の構成アイテムを識別する名称（または識別番号等）とが保管される。
【００４１】
属性フィールド２２８は、１以上の属性（Attribute）および属性値のセットを保管する。属性は、個々の構成アイテムを特定し、説明するものである。属性としては、特に限定されるものではないが、構成アイテムの名称、識別番号、カテゴリ（リソースおよびプロセスの別を識別する。）、タイプ（制御システム、機材、デバイス、センサ、アクチュエータなどを識別する。）、その他、型番、目的、所有者、発行者、ロケーション、保証期間、バージョン番号、開始日時や完了予定日時や期限などのスケジュール、ステータス、重要度などを挙げることができる。さらに本実施形態では、リソースＣＩについては、さらに、許容される状況の範囲（定格値、想定値など）、許容されるアクションの範囲（開始、停止、変更）などを含むことができる。
【００４２】
なお、構成アイテムの属性は、定義拡張が可能とされており、上述したものに限られるものでなく、またクラス（タイプおよびカテゴリで分類される。）毎に内容を相違させることもできる。本発明の実施形態においては、異常を検知する際に属性情報を使用する場合があるため、少なくともこのような異常検知に用いられる属性が定義されていればよい。なお、図４に示すデータ構造は一例であり、特に限定されるものではなく、他の実施形態では、関係フィールド２３０の内容等を別のテーブルで管理することもできる。
【００４３】
本実施形態では、ＣＭＤＢ１７０内には、プロセスとリソースとの間、リソース間、リソース・グループとリソースおよびプロセスとの間の関係が定義されている。このため、情報付加部１５６は、上記送信元グループＩＤおよび宛先グループＩＤを用いてＣＭＤＢ１７０に照会することにより、送信元および宛先グループに関連する種々の属性情報を取得し、グループ識別済みイベント情報２００，２０２を豊富化することができる。グループに関連する種々の属性情報としては、送信元リソース・グループおよび宛先リソース・グループの各種属性情報（以下、グループ属性情報と参照する。）２０６、これらリソース・グループ内の各リソースの属性情報（以下、リソース属性情報と参照する。）２０８、およびプロセスの各種属性情報（以下、プロセス属性情報と参照する。）２１０を含むことができる。
【００４４】
例えば、上記許容される状況の範囲（定格値や想定値）、許容されるアクションの範囲（開始、停止、変更）などの属性値に対する条件式がポリシのマッチング記述部内に記述されていれば、これら許容される範囲の情報を用いて、許容範囲内か範囲外か、あるいは想定範囲内か想定範囲外かを判定し、異常を検出することが可能となる。なお、上記許容される状況の範囲や許容されるアクションの範囲は、その最小値および最大値により規定されたり、限定的に列挙することにより取り得る値が規定されたりする。
【００４５】
また情報付加部１５６は、上記ＣＭＤＢ１７０から取得した送信元リソース・グループおよび宛先リソース・グループ内の各プロセスのプロセスＩＤを用いて、プロセス管理システム１８０に対し照会して、送信元グループおよび宛先グループ内の各プロセスに関するステータス値など動的な状況情報（以下、プロセス状況情報と参照する。）２１２を取得することができる。以下、プロセス管理システム１８０が管理するデータ構造を参照して、情報付加部１５６が取得する情報について説明する。
【００４６】
図５は、プロセス管理システム１８０が管理するプロセスに関するデータ構造を例示する図である。図５に示すプロセス管理テーブル２４０は、プロセスを識別するプロセスＩＤを保管するフィールド２４２と、プロセスの名称を保管するフィールド２４４と、プロセスのカテゴリを保管するフィールド２４６と、プロセスの動的なステータスを保管するフィールド２４８とを含む。さらに、プロセス管理テーブル２４０は、期限、開始日時、完了予定日時などのスケジュールを保管する複数のフィールド２５０〜２５４と、プロセスの発行者および所有者を保管する複数のフィールド２５６，２５８と、重要度を保管するフィールド２６０とを含む。図５に示すプロセス管理テーブル２４０は、図４に示した構成アイテムテーブル２２０と重複する情報も含んでいるが、本実施形態のプロセス管理システム１８０は、ＣＭＤＢ１７０と異なり、フィールド２４８に保管される動的に変化するステータスを保管しており、このような動的な状況情報を用いて、リアルタイムな状況を反映して異常を検出することが可能となる。
【００４７】
再び図２を参照すると、上記情報付加部１５６は、送信元グループＩＤおよび宛先グループＩＤを使用して、ＣＭＤＢ１７０およびプロセス管理システム１８０またはこれらのいずれか一方から、上記グループ属性情報２０６、リソース属性情報２０８、プロセス属性情報２１０およびプロセス状況情報２１２を含むグループ関連情報２０４を取得すると、これらをグループ識別済みイベント情報２００，２０２に付加する。豊富化されたイベント情報２００，２０２，２０４は、上述したように、アクション決定部１５８によりセキュリティ・ポリシに対し適用されて、対策アクションが導出される。以下、フローチャートを参照しながら、本発明の実施形態による上記豊富化されたイベント情報とセキュリティ・ポリシとを用いた異常検知処理について詳細を説明する。
【００４８】
図６は、本発明の実施形態による解析エンジン１５０が実行する、異常検知処理を示すフローチャートである。図６に示す処理は、セキュリティ・ゲートウェイ１４０の監視部１４２が、制御ネットワーク１３０からトラフィック・データを拾ってイベント情報を発信したことに応答して、ステップＳ１００から開始する。あるいは、他の実施形態では、上記イベント情報が監視部１４２から発信され、処理待ちのイベント情報を格納する待ちキューに投入されたことに応答して、イベント情報毎にステップＳ１００から開始する。ステップＳ１０１では、グループ識別部１５２は、セキュリティ・ゲートウェイ１４０の監視部１４２からイベント情報２００を受信する。ステップＳ１０２では、グループ識別部１５２は、イベント情報２００に含まれる送信元ＩＤおよび宛先ＩＤを用いてＣＭＤＢ１７０に照会し、送信元リソースおよび宛先リソースが属するリソース・グループをそれぞれ決定し、照会結果２０２をイベント情報２００に付加する。
【００４９】
ステップＳ１０３では、情報付加部１５６は、セキュリティ・ポリシ記憶部１６０に記憶されている有効なすべてのセキュリティ・ポリシ中の、外部情報を必要とするマッチング条件を検索し、外部情報として取得する必要のある情報を抽出する。ステップＳ１０４では、情報付加部１５６は、外部情報が必要であるか否かを判定する。ステップＳ１０４で外部情報が必要であると判定された場合（ＹＥＳ）には、ステップＳ１０５へ処理が分岐される。ステップＳ１０５では、情報付加部１５６は、ＣＭＤＢ１７０およびプロセス管理システム１８０またはこれらのいずれか一方に照会し、マッチング記述部の評価に必要な情報を取得し、イベント情報２００，２０２に付加し、ステップＳ１０６へ処理を進める。一方、ステップＳ１０４で外部情報が必要ではないと判定された場合（ＮＯ）には、ステップＳ１０６へ直接処理が進められる。
【００５０】
ここで、図７〜図１１を参照しながら、セキュリティ・ポリシの詳細について説明する。図７（Ａ）〜（Ｃ）、図８（Ａ）および（Ｂ）、図９（Ａ）および（Ｂ）、図１０（Ａ）および（Ｂ）並びに図１１（Ａ）および（Ｂ）は、それぞれセキュリティ・ポリシのデータ構造を例示する。図７〜図１１に示すように、各セキュリティ・ポリシは、マッチング条件を記述するマッチング記述部と、１以上の対策アクションを記述するアクション記述部とを含む。図７（Ａ）に示すセキュリティ・ポリシは、識別番号として「１」が付されたポリシであって、送信元リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベント情報に含まれるイベントデータが送信元リソースの許容値の範囲外である場合に、対策アクションとして、送信元グループ内のすべてのリソースを対象とし、イベントタイプが「操作」であるすべてのイベントを遮断する、という内容を記述している。
【００５１】
図７（Ａ）に示すセキュリティ・ポリシが適用される場合、情報付加部１５６は、ステップＳ１０５で、マッチング記述部の評価のために必要な情報として、送信元ＩＤで識別されるリソースが属する送信元リソース・グループ内のプロセスの状況情報（ステータス値）をプロセス管理システム１８０から取得し、送信元リソースの属性情報（許容される範囲）をＣＭＤＢ１７０から取得する。図７（Ａ）に示すポリシにおいては、取得されたプロセスのステータス値については、これに対する条件式が直接記述されており、取得されたリソースの許容される範囲の属性値については、これを引用する形式でイベントデータに対する条件式が記述されている。
【００５２】
図７（Ｂ）に示すセキュリティ・ポリシは、識別番号として「２」が付されたポリシであって、送信元ＩＤで識別される送信元リソースを利用するプロセスが存在せず（送信元ＩＤに対するグループＩＤの照会に対してｎｕｌｌ値が返る場合が対応する。）、かつ、イベントタイプが「センサデータ」である場合に、対策アクションとして、外部メール・システムを対象としアラート送信を行う、という内容を記述している。図７（Ｂ）に示すセキュリティ・ポリシが適用される場合、情報付加部１５６は、ステップＳ１０５で、必要な情報として、ＣＭＤＢ１７０から送信元リソースが属する送信元リソース・グループのグループＩＤおよびその属性情報を取得することができる。しかしながら、送信元リソース・グループを識別するグループＩＤは、グループ識別部１５２が既に取得されてイベント情報に付されているため、それ以外の情報が必要ない場合には、情報付加部１５６は、図７（Ｂ）に示すセキュリティ・ポリシに関して、特にマッチング記述部の評価のために必要な情報を取得しなくともよい。
【００５３】
図７（Ｃ）に示すセキュリティ・ポリシは、識別番号として「３」が付されたポリシであって、宛先リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベントタイプが「操作」であり、かつ、イベント情報に含まれるイベントデータが宛先リソースの最大許容値を超える場合に、対策アクションとして、宛先リソースを対象とし、当該イベント情報に対応するトラフィック・データのイベントデータを宛先デバイスの最大許容値に修正する、という内容を記述している。図７（Ｃ）に示すセキュリティ・ポリシが適用される場合、情報付加部１５６は、ステップＳ１０５で、必要な情報として、宛先リソースが属する宛先リソース・グループのプロセスの状況情報（ステータス値）をプロセス管理システム１８０から取得し、宛先リソースの属性情報（許容される範囲における最大値）をＣＭＤＢ１７０から取得する。
【００５４】
図８〜図１１に示すポリシが適用される場合についても同様であり、情報付加部１５６は、ステップＳ１０５で、マッチング記述部の評価のために必要な情報として、送信元または宛先リソースを利用するプロセスの情報（ステータス値や重要度など）、送信元または宛先リソースに関する情報（許容される範囲の最大値および最小値など）をプロセス管理システム１８０およびＣＭＤＢ１７０またはこれらのいずれか一方から取得することができる。
【００５５】
再び図６を参照すると、ステップＳ１０６では、アクション決定部１５８は、イベント情報２００，２０２，２０４が合致するマッチング条件を検索し、対応するアクション記述部を取得する。ステップＳ１０７では、アクション決定部１５８は、マッチング条件が真のポリシが存在するか否かを判定する。ステップＳ１０７で、マッチング条件が真のポリシが存在しないと判定された場合（ＮＯ）には、ステップＳ１１１へ処理を直接進め、本処理を終了し、次のイベント情報の処理が開始されるまで待ち受ける。一方、ステップＳ１０７で、マッチング条件が真のポリシが存在すると判定された場合（ＹＥＳ）には、ステップＳ１０８へ処理を分岐させる。
【００５６】
ステップＳ１０８では、アクション決定部１５８は、対応するアクション記述部の内容から、イベント情報の送信元および宛先リソース以外のリソースへの対策アクションを含むか否かを判定する。ステップＳ１０８で、送信元および宛先以外のリソースへのアクションを含むと判定された場合（ＹＥＳ）には、ステップＳ１０９へ処理を分岐させる。ステップＳ１０９では、情報付加部１５６は、イベント情報２００，２０２と、ＣＭＤＢ１７０およびプロセス管理システム１８０またはこれらのいずれか一方に照会して得た情報２０４とを使用して、アクション対象を決定し、ステップＳ１１０へ処理を進める。例えば、図７（Ａ）に示すポリシの場合、情報付加部１５６は、実施対象を選択するために必要な情報として、送信元リソースが属する送信元リソース・グループ内の他のリソースＩＤリストをＣＭＤＢ１７０から取得し、この取得されたリソースＩＤを対象に設定することができる。
【００５７】
ステップＳ１０８で、送信元および宛先以外のリソースへのアクションを含まないと判定された場合（ＮＯ）には、ステップＳ１１０へ処理を直接進める。ステップＳ１１０では、アクション決定部１５８は、送信元および宛先またはこれらのいずれか一方をアクション対象として、推奨される対策アクションを導出し、アクション対象および対策アクションをセキュリティ・ゲートウェイ１４０の実施部１４４に通知し、ステップＳ１１１で本処理を終了させる。
【００５８】
ここで、再び図７〜図１１を参照すると、図７（Ａ）に示すポリシによれば、プロセスにより利用されているリソースにおいて、許容できない値の操作が観測された場合に、そのプロセスが利用しているすべてのリソース（同一リソース・グループ内のすべてのリソース）への操作イベントを遮断することができる。また、図７（Ｂ）に示すポリシによれば、いずれのプロセスからも使用されておらず、使用計画もないリソースからセンサデータが出力されている場合に、その出力を不穏な挙動（異常）として検出し、アラートを発することができる。さらに図７（Ｃ）に示すポリシによれば、プロセスにより利用されているリソースにおいて、許容できない値の操作が観測された場合に、トラフィック・データを適正な値に修正することができ、異常操作を補正し、障害発生を予防することができる。
【００５９】
また図８（Ａ）に示すセキュリティ・ポリシは、識別番号として「４」が付されたポリシであって、送信元リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベント情報に含まれるイベントデータが送信元リソースの許容値の範囲外であり、かつ、イベント情報に含まれるイベントタイプが「操作」である場合に、対策アクションとして、宛先グループ内のすべてのリソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図８（Ａ）に示すポリシによれば、プロセスにより利用されているリソースからの異常イベントを検出し、同じプロセスで利用されているすべてのリソースへの操作を禁止することにより、不正侵入防止（ＩＰＳ）を実現することができる。
【００６０】
図８（Ｂ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベント情報に含まれるイベントデータが送信元リソースの許容値の範囲外である場合に、対策アクションとして、送信元グループ内のすべてのリソースを対象とし、リソースの緊急停止を指令する新規トラフィックを発行する、という内容を記述している。図８（Ｂ）に示すポリシによれば、プロセスにより利用されているリソースからの異常イベントを検出し、同じプロセスで利用されているすべてのリソースへ緊急停止を指令することにより、侵入の疑いのあるリソースの緊急停止を実施することができる。
【００６１】
図９（Ａ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスのプロセスＩＤが宛先リソースを利用するプロセスのプロセスＩＤと一致しない場合に、対策アクションとして、送信元グループ内のすべてのリソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図９（Ａ）に示すセキュリティ・ポリシによれば、異なるプロセスで利用されているリソース間の通信を検出し、通信をブロックすることができ、プロセス毎に独立な仮想的ネットワークを構成することができる。
【００６２】
図９（Ｂ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスの重要度が「ＨＩＧＨ」であり、かつ、イベント情報に含まれるイベントタイプが「操作」である場合に、対策アクションとして、宛先グループ内のすべてのリソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図９（Ｂ）に示すセキュリティ・ポリシによれば、重要度の高いプロセスで利用されるリソースへの操作を検出し、通信をブロックすることができ、ファイアウォールのフィルタのような働きを実現することができる。
【００６３】
図１０（Ａ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスの重要度が、宛先リソースを利用するプロセスの重要度より小さい場合に、対策アクションとして、宛先グループ内のすべてのリソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図１０（Ａ）に示すセキュリティ・ポリシによれば、重要度の低いプロセスで利用されるデバイスグループのリソースから、重要度の高いプロセスで利用されるデバイスグループへの通信を検出し、通信をブロックすることができ、セキュリティ・レベルに応じたゾーニング（zoning）を実現することができる。
【００６４】
図１０（Ｂ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスの重要度が「ＬＯＷ」であり、かつ、イベント情報に含まれるイベントデータが送信元リソースの許容される範囲内である場合に、対策アクションとして、送信元リソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図１０（Ｂ）に示すセキュリティ・ポリシによれば、重要度の低いプロセスで利用されるリソースからのセンサ値が許容される範囲内であった場合に通信をブロックすることができ、重要度の低い通常状態データのトラフィックを削減することができる。
【００６５】
以上図７〜図１０を参照しながら、種々のセキュリティ・ポリシについて説明してきたが、上述までのセキュリティ・ポリシは、セキュリティ・ゲートウェイ１４０から通知されるイベント情報毎に、解析をして異常の検知を試み、異常が見つかった場合に対策アクションを実施させるというものであった。しかしながら、セキュリティ・ポリシは、単一のイベント情報に対して規定されるのみならず、イベント情報毎の解析結果を一旦記憶しておき、現在処理対象であるイベント情報の送信元若しくは宛先に関連して蓄積された履歴情報（過去に発生したイベント情報）に関する条件式を含めて、マッチング条件を記述することができる。これにより、複数のイベント情報の組み合わせ、シーケンスまたは統計に対応して、選択的または段階的に対策アクションを導出することができる。図１１（Ａ）および（Ｂ）は、このような複数のイベント情報に対応して段階的に対策アクションを導出するためのセキュリティ・ポリシを例示する。
【００６６】
図１１（Ａ）に示すセキュリティ・ポリシは、宛先リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベントタイプが「操作」であり、かつ、イベント情報のイベントデータが宛先リソースの最大許容値を超える場合であって、宛先グループ全体についての異常の発生（許容範囲外とされる異常に限る。）が１時間に５回未満の頻度であったときに、所定の対策アクションを実施するという内容を規定する。上記所定の対策アクションとしては、図１１（Ａ）には、宛先リソースを対象としてイベントデータを修正するという対策アクションと、内部状態の記録として宛先グループについて異常の発生（許容範囲外とされる異常に限る。）を記録するという追加の対策アクションとが記述されている。異常の発生は、例えば、発生日時と異常の内容とをレコードとした、解析エンジン１５０の内部の一時的な履歴データとして記録することができる。このような内部で保持される履歴情報は、例えば、情報付加部１５６が、マッチング記述部の評価のために必要な情報として適宜取得することができる。
【００６７】
これに対して図１１（Ｂ）に示すセキュリティ・ポリシは、宛先グループ全体についての異常の発生（許容範囲外とされる異常に限る。）が１時間に５回以上の頻度で発生するという条件を除き、図１１（Ａ）に示すポリシと同様のマッチング条件を規定する。そして、図１１（Ｂ）に示すセキュリティ・ポリシは、上述したマッチング条件が満たされるときの対策アクションとして、宛先グループ内のすべてのリソースを対象として、リソースの緊急停止を指令する新規トラフィックを発行するという対策アクションと、内部状態の記録として宛先グループについて異常の発生の記録をリセットするという追加の対策アクションとを記述している。
【００６８】
上述した図１１（Ａ）および（Ｂ）に示す２つのセキュリティ・ポリシの組み合わせによれば、イベント情報に含まれるイベントデータが宛先リソースの最大許容値を超える場合、当該イベント情報に対応するトラフィック・データのイベントデータを宛先デバイスの最大許容値に修正するという対策アクションを実施しつつ、同一ルール違反の発生が所定の頻度を超えたときに、上記イベントデータの修正に代えて、停止イベントを発生させる対策アクションを実施するという、段階的な対策アクションの導出を可能とする。
【００６９】
以上説明したように、上述までの実施形態による監視制御によれば、構成管理データベース１７０を利用することで、制御ネットワーク１３０におけるプロセス、リソース間の依存関係を考慮して制御ネットワーク１３０内の現在の状況を解析し、リソース・グループ全体の振る舞いとして異常の疑われる状況をも好適に検知することができる。そして、制御ネットワーク１３０におけるプロセス、リソース間の依存関係を考慮して、適切な対策アクションおよびアクションを実施させる対象を決定することができる。したがって、アクチュエータ等のリソース単独の動きからは容易に判別し得ない異常を好適に検知することが可能となり、ひいては、産業制御システムのオープン化に伴うセキュリティ低下を好適に防止することができる。
【００７０】
なお、上記解析エンジン１５０は、それ単独で、１又は複数の汎用コンピュータからなる汎用コンピュータ・システム上に実装されてもよく、特定用途の機器として実装されてもよく、また他の実施形態では、セキュリティ・ゲートウェイ１４０の機能と一体として実装されてもよい。
【００７１】
以上説明したように、本発明の実施形態によれば、構成管理データベースを利用して、制御システムにおけるデバイス、機材、センサ、アクチュエータなどの構成要素間の依存関係を考慮し、構成要素間でネットワークを流れるデータ・トラフィックから異常が疑われる振る舞いを検知し、迅速に対策アクションを起こすことが可能な異常検知装置、監視制御システム、異常検知方法、プログラムおよび記録媒体を提供することができる。
【００７２】
本発明の実施形態による解析エンジンは、コンピュータ実行可能なプログラムを、コンピュータにロードして各機能部を実現することにより、異常検知装置として提供される。このようなプログラムとしては、例えば、ＦＯＲＴＲＡＮ、ＣＯＢＯＬ、ＰＬ／Ｉ、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなどのレガシー・プログラミング言語やオブジェクト指向プログラミング言語などで記述された、コンピュータ実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布することができる。
【００７３】
これまで本発明を図面に示した実施形態および実施例をもって説明してきたが、本発明は図面に示した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【符号の説明】
【００７４】
１００…産業システム、１０２…制御システム、１０４…コンソール・システム、１０６…保守システム、１０８…分析システム、１１０…機材、１１２…センサ、１１４…アクチュエータ、１２０…デバイス、１２２…センサ、１２４…アクチュエータ、１３０…制御ネットワーク、１４０…セキュリティ・ゲートウェイ、１４２…監視部、１４４…アクション実施部、１５０…解析エンジン、１５２…グループ識別部、１５４…イベント解析部、１５６…情報付加部、１５８…アクション決定部、１６０…セキュリティ・ポリシ記憶部、１７０…構成管理データベース（ＣＭＤＢ）、１８０…プロセス管理システム、２００…イベント情報、２０２…照会結果、２０４…グループ関連情報、２０６…グループ属性情報、２０８…リソース属性情報、２１０…プロセス属性情報、２１２…プロセス状況情報、２２０…構成アイテムテーブル、２２２〜２３０…フィールド、２４０…プロセス管理テーブル、２４２〜２６０…フィールド
【技術分野】
【０００１】
本発明は、情報セキュリティ技術に関し、より詳細には、重要インフラストラクチャ等における制御システムをセキュリティ保護するための異常検知装置、監視制御システム、異常検知方法、プログラムおよび記録媒体に関する。
【背景技術】
【０００２】
現代社会は、電力、ガス、水道、鉄道、金融、プラント、パイプラインなど様々なインフラストラクチャの上に成り立っている。上述のような社会的に重要なインフラストラクチャの制御システムは、その機能が停止すれば、社会経済に大きな影響を及ぼすおそれがあるため、旧来、外部から隔離され、仕様も公開されないクローズド・システムでの稼働を前提として設計され、運用されてきた。ところが、近年、接続性、生産性の向上、経営判断の効率化などの経営面からの要請により、上述のような旧来システムから、オープン・システムに移行しつつある。制御システムの専用製品や独自の構造は、汎用製品やＴＣＰ／ＩＰ等の標準プロトコルに置き換えられ始め、ネットワークを介した制御システム間の連携、情報処理システムとの連携も進んでいる。
【０００３】
しかしながら、オープン化が進むにつれ、制御システムは、汎用製品に存在する脆弱性、不正アクセス、情報漏洩、ウィルス、ワームなど、情報処理システムで発生している様々な脅威に晒される。上述のような重要なインフラストラクチャは、万が一攻撃を受けた場合、その影響が大規模かつ広範囲となる。また、産業制御システム（Industrial Control System）は、プラントやパイプラインにおけるポンプ、バルブなどアクチュエータを制御しているため、その誤作動は、ときには人的被害や環境破壊をもたらす。したがって、制御システムのオープン化に伴い、このような脅威から制御システムを保護するための高度なセキュリティを実現することが望ましい。また、万が一上述のような脅威が疑われる事態が発生した場合は、その異常を迅速に検知して適切な対策を講じることが望ましい。
【０００４】
上記脆弱性、不正アクセス等は、情報処理システムにおいても既に発生している問題であることから、情報処理システムで適用されているセキュリティ技術を導入することも、ある程度有用であるとも考えられる。情報処理システムにおけるセキュリティ技術としては、例えば、特許第４５２１４５６号公報（特許文献１）は、被管理情報処理装置の動作をコントロールするためのセキュリティ・ポリシを被管理情報処理装置に配布する情報処理装置を開示する。また、特開２００７−２７４０２７号公報（特許文献２）は、遠隔操作による回復サービスを容易に導入可能なリモートオペレーションシステムを開示する。しかしながら、産業制御システムは、情報処理システムとは異なる性質があり、情報処理システムで行われているセキュリティ技術を適用するだけでは充分ではない場合があった。上述のような脅威が疑われる異常を、迅速に検知して対策を講じることができない場合があった。
【０００５】
ところで、近年、ＩＴサービスにおいて、管理対象のコンポーネントに関する情報を一元的に管理し、必要なときに必要な情報を提供することを目的として、構成管理データベース（ＣＭＤＢ：Configuration Management Database）が注目されている。ＣＭＤＢは、サービス管理の対象となるハードウェア、ソフトウェア等のリソース、ドキュメント、インシデント履歴情報、さらには人的資源を含めて各構成要素を構成アイテム（ＣＩ；Configuration Item）として維持管理し、把握できるように支援するものである（特許文献３，特許文献４）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特許４５２１４５６号公報
【特許文献２】特開２００７−２７４０２７号公報
【特許文献３】特開２００９−２４５０２９号公報
【特許文献４】特開平９−６９０８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、上記従来の制御システムにおける問題点を鑑みてなされたものであり、本発明は、上述した構成管理データベースを利用し、制御システムにおけるデバイス、機材、センサ、アクチュエータなどの構成要素間の依存関係を考慮し、構成要素間でネットワークを流れるデータ・トラフィックから、異常が疑われる振る舞いを検知し、迅速に対策アクションを起こすことができる、異常検知装置、監視制御システム、異常検知方法、プログラムおよび記録媒体を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、上記従来技術の課題を解決するために、以下の特徴を有する異常検知装置および該異常検知装置を含む監視制御システムを提供する。本発明の異常検知装置は、制御ネットワーク内で発生したイベント情報を受信して、制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別する。異常検知装置は、異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部を参照して、１以上のポリシを読み出す。異常検知装置は、１以上のポリシを適用する上で必要となるグループに関連する情報を取得し、イベント情報に付加し、情報の豊富化を行う。そして、異常検知装置は、１以上のポリシに対しイベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する。
【０００９】
上記構成管理データベースは、プロセスおよびリソースを構成アイテムとして維持し、プロセス間、リソース間、プロセスおよびリソース間の関係により依存関係をも記述することができる。上記取得されるグループに関連する情報は、上記構成管理データベースまたはプロセス管理システムなどの外部システムから取得されるグループに属するプロセスの状況情報、上記グループに属するプロセスの属性情報および上記グループに属するリソースの属性情報またはこれらの少なくとも１つの情報を含むことができる。上記条件は、グループに関連する情報を条件式に含むことができる。
【発明の効果】
【００１０】
上記構成によれば、上述した構成管理データベースを利用することで、制御ネットワークにおけるプロセス、リソース間の依存関係を考慮して制御ネットワーク内の現在の状況を解析し、リソース・グループ全体の振る舞いとして異常の疑われる状況をも好適に検知し、さらに適切な対策アクションおよび該アクションを実施させる対象を決定することができる。したがって、アクチュエータ等のリソース単独の動きからは容易に判別し得ない異常を好適に検知することが可能となり、ひいては、産業制御システムのオープン化に伴うセキュリティ低下を好適に防止することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態による産業システムの概略構成を示す図。
【図２】構成管理データベースと連携した異常検知に基づく監視制御処理で使用されるデータを説明する図。
【図３】構成管理データベース内に構築される構成アイテム間の関係を模式的に表した図。
【図４】構築された構成管理データベースのデータ構造を例示する図。
【図５】プロセス管理システムが管理するプロセスに関するデータ構造を例示する図。
【図６】本発明の実施形態による解析エンジンが実行する、異常検知処理を示すフローチャート。
【図７】セキュリティ・ポリシのデータ構造を例示する図。
【図８】他のセキュリティ・ポリシのデータ構造を例示する図。
【図９】他のセキュリティ・ポリシのデータ構造を例示する図。
【図１０】他のセキュリティ・ポリシのデータ構造を例示する図。
【図１１】さらに他のセキュリティ・ポリシのデータ構造を例示する図。
【発明を実施するための形態】
【００１２】
以下、本発明について実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。以下に説明する実施形態では、１以上の制御システムを含む制御ネットワークの異常を検知する異常検知装置、および監視制御システムとして、制御ネットワークの異常を検知する解析エンジン、および上記解析エンジンとセキュリティ・ゲートウェイとを含む産業システムを例として説明する。
【００１３】
以下、図１を参照して、本発明の実施形態による産業システムの全体構成について説明する。図１は、本発明の実施形態による産業システムの概略構成を示す図である。図１に示す産業システム１００は、制御ネットワーク１３０に接続される、制御システム１０２、コンソール・システム１０４、保守システム１０６、分析システム１０８、機材１１０およびデバイス１２０を含む。産業システム１００は、例えば、農業、金融、化学、商業施設、ダム、防衛産業基盤、緊急サービス、エネルギー、政府施設、情報技術、原子炉、物流、公共衛生、通信、輸送、水道、重要製造業などにおけるシステムである。
【００１４】
制御システム１０２は、機材１１０およびデバイス１２０のシステム監視、プロセス制御を行うシステムであり、例えば、地理的に分散した制御対象を遠隔集中監視し、制御データの収集を行うＳＣＡＤＡ（Supervisory Control And Data Acquisition）、分散制御システム（ＤＣＳ：Distributed Control System）などのホストコンピュータをいう。制御システム１０２には、その他、プログラマブル・ロジック・コントローラ（ＰＬＣ）や遠隔監視制御装置（ＲＴＵ）を含めてもよい。コンソール・システム１０４は、対象システムのデータをオペレータに提示し、オペレータがシステムを監視し制御できるようにするＨＭＩ（ヒューマン・マシン・インタフェース）である。保守システム１０６は、機材１１０およびデバイス１２０等を遠隔的に保守点検を行うためのシステムである。分析システム１０８は、センサ端末からゲートウェイを通して集計したデータに対して相関モデル等を適用し、統計的な解析に基づいて異常を検出する分析システムである。
【００１５】
機材１１０およびデバイス１２０は、共に、センサ１１２，１２２やアクチュエータ１１４，１２４などのフィールド機器にセンサバスを介して接続するセンサ端末である。なお、機材１１０およびデバイス１２０の分類は、任意であり、産業システム１００の運用者が適宜決定すればよい。説明する実施形態では、機材１１０は、主として、単独で機能する装置をいうものとし、デバイス１２０は、主として他の機材１１０を装備することが可能な装置をいうものとする。上記センサ１１２，１２２としては、特に限定されるものではないが、温度センサ、湿度センサ、流量計、水位計、照度計、電力計、人感知センサなどの種々の計測器を挙げることができる。上記アクチュエータ１１４，１２４としては、特に限定されるものではないが、バルブ、コンプレッサ、その他モータや能動的に機能する装置を挙げることができる。
【００１６】
制御ネットワーク１３０は、特に限定されるものではないが、フィールド・ネットワーク、コントロール・ネットワーク、制御情報ネットワークを含み、制御ネットワーク１３０上には、各種信号やデータが伝送される。本発明の実施形態による産業システム１００では、制御ネットワーク１３０には、さらに、１以上のセキュリティ・ゲートウェイ１４０が接続される。セキュリティ・ゲートウェイ１４０は、制御ネットワーク１３０のトラフィックを監視しており、異常を検知するため制御ネットワーク１３０内で発生したイベントを拾い上げる。セキュリティ・ゲートウェイ１４０は、解析エンジン１５０に接続されており、拾い上げたイベントに関する信号およびデータを適宜フォーマット変換し、詳細な解析を行わせるため解析エンジン１５０に渡す。
【００１７】
解析エンジン１５０は、受け取ったイベント情報を解析して、制御ネットワーク１３０内で発生した異常の検知を試みる。産業制御システム（ＩＣＳ）では、制御ネットワーク１３０内の機材、デバイス、センサ、アクチュエータ等の個別要素の動作を監視しても、制御ネットワーク１３０内で発生する異常を発見することが難しい場合がある。例えば、あるアクチュエータが、使用されておらず、またその使用の計画さえないにもかかわらず、動作している場合は、不正侵入等何らかの異常を疑うべきである。しかしながら、アクチュエータ自体が通常の動作範囲で動いている限り、アクチュエータの動きからは、その不穏な動きを異常として検知することは難しい。つまり、制御システムでは、一般的な情報処理システムと異なり、その異常を正しく検知するためには、上記デバイス、機材、センサ、アクチュエータ等のリソース間の依存関係を把握した上で、リソース間を流れるデータ・トラフィックから異常の疑いのあるイベントを拾い上げる必要がある。
【００１８】
そこで、本発明の実施形態による産業システム１００では、解析エンジン１５０は、構成管理データベース（ＣＭＤＢ）１７０と連携して、機材、デバイス、センサ、アクチュエータ等の依存関係を考慮した上でイベント情報を解析する。イベント解析の結果、異常が疑われる場合には、解析エンジン１５０は、推奨される対策アクションを決定し、セキュリティ・ゲートウェイ１４０に通知し、セキュリティ・ゲートウェイ１４０に対策アクションを実行させる。
【００１９】
以下、ＣＭＤＢ１７０と連携した異常検知に基づく監視制御の構成について、より詳細に説明する。セキュリティ・ゲートウェイ１４０は、より詳細には、監視部１４２を含み構成される。監視部１４２は、制御ネットワーク１３０内を伝送するセンサデータやセンサ信号、アクチュエータに対する操作コマンドや制御信号などのトラフィックを監視し、所定フォーマットのイベント情報を生成し、解析エンジン１５０に渡す。制御ネットワーク１３０では、多種多様な形式でデータおよび信号が伝送されることが想定されるため、監視部１４２は、種々のデータ形式から統一的なデータ形式へ変換するフォーマット変換器としての機能を備えることが好ましい。
【００２０】
好適な実施形態では、監視部１４２は、多種多様な形式で表現されたデータおよび信号から、送信元を識別する送信元ＩＤ（IDentifier）と、宛先を識別する宛先ＩＤと、イベントのタイプを識別するイベントタイプと、上記センサデータや操作指令であるイベントデータとを含む所定形式のイベント情報を生成することができる。イベントタイプとは、センサデータであるか、操作命令であるかなど、イベントの型を表す。イベントデータは、一般には、センサ１１２，１２２からの出力であれば、センサデータを含み、アクチュエータ１１４，１２４に対する操作命令であれば、そのコマンドおよびその引数を含む。
【００２１】
解析エンジン１５０は、より詳細には、グループ識別部１５２と、イベント解析部１５４とを含み構成される。グループ識別部１５２は、セキュリティ・ゲートウェイ１４０の監視部１４２からイベント情報を受け取り、ＣＭＤＢ１７０に照会を行う。ＣＭＤＢ１７０は、構成アイテム（ＣＩ；Configuration Item）とその重要な属性の詳細を維持し、さらに構成アイテム間の関係を管理することで、管理対象に関する情報の統合された構成管理を実現する。構成アイテム（ＣＩ）は、ＣＭＤＢ１７０内の情報を管理するための基本単位であり、本発明の実施形態においては、構成アイテムは、主としてプロセスおよびリソースに分類される。
【００２２】
上記構成アイテムのうちの「リソース」（以下、「リソース」の構成アイテムをリソースＣＩという。）は、上記制御システム、機材、デバイス、センサ、アクチュエータ、ネットワーク機器、コンソール・システム、保守システム、分析システムなどの構成要素、その他フロアやビルディングなどの施設や設備を含むことができる。上記構成アイテムのうちの「プロセス」（以下、プロセスの構成アイテムをプロセスＣＩという。）は、上記リソースを使用するか、または使用する計画がある（以下、使用計画を含め「使用する」という。）処理または作業を意味する。プロセスの粒度は、特に限定されるものではなく、プロジェクト管理システムにおけるプロジェクトを構成するサブプロジェクト、ワークフロー管理システムにおけるワークフローを構成する工程のように、プロセスが他のプロセスを含む関係にあってもよい。プロセスとしては、定期点検、通常の製造工程、インシデント対応、緊急対応などを挙げることができる。
【００２３】
グループ識別部１５２は、上記イベント情報に含まれる送信元ＩＤおよび宛先ＩＤを用いて、ＣＭＤＢ１７０に照会し、当該イベント情報に関わる送信元または宛先のリソースが属するリソース・グループを識別するグループＩＤを取得し、上記イベント情報に付す。ここで、リソース・グループとは、リソースを使用するプロセス、該プロセスが使用する他のリソースなど、ＣＭＤＢ１７０内に定義される依存関係を辿ることでグループ化されるリソース群をいう。なお、ＣＭＤＢ１７０内でリソース・グループが管理されていない実施形態では、上記グループＩＤに代えて、グループに属するリソースのＩＤリストを用いても良い。いずれの場合も、グループを識別する情報（以下、グループＩＤおよびリソースのＩＤリストをまとめてグループ識別情報と参照する。）がイベント情報に付される。グループ識別情報が付されたイベント情報（以下、グループ識別済みイベント情報という。）は、グループ識別部１５２からイベント解析部１５４へ渡される。
【００２４】
イベント解析部１５４は、上記グループ識別済みイベント情報をグループ識別部１５２から受け取り、このグループ識別済みイベント情報に含まれる情報を使用して、所与のセキュリティ・ポリシに従いマッチング処理およびアクション決定処理を実行する。イベント解析部１５４は、より詳細には、情報付加部１５６と、アクション決定部１５８とを含む。上記セキュリティ・ポリシは、制御ネットワーク１３０において異常を疑うべき状況を規定するマッチング条件と、その疑われる異常に対抗するための１以上の対策アクションとを対応付けるユーザ定義データである。上記セキュリティ・ポリシは、上記マッチング条件を記述するマッチング記述部と、それに対応付けられる１以上の対策アクションを記述するアクション記述部とを含み、１以上のセキュリティ・ポリシがセキュリティ・ポリシ記憶部１６０に管理される。マッチング条件は、好適には、送信元および宛先リソースの依存関係に関連した条件を含むことができる。
【００２５】
情報付加部１５６は、マッチング記述部の評価のために必要な情報がある場合、外部システムに対し問い合わせを行い、グループ識別済みイベント情報をさらに豊富化（enrichment）させることができる。ここで豊富化のため付加される情報としては、グループに関連する種々の情報（以下、グループ関連情報と参照する。）、例えばグループ内の各リソースの属性情報、グループ内のプロセスの属性情報や状況情報を挙げることができる。情報付加部１５６は、また、対策アクションを決定する際に実施対象を選択するために必要な情報がある場合、外部システムに問い合わせを行い、対策アクション決定の際に必要な情報を付加し、グループ識別済みイベント情報を豊富化させることができる。
【００２６】
上述した外部システムとしては、上記ＣＭＤＢ１７０、プロセス管理システム１８０、その他、資産管理システム、ヒストリアン、プロジェクト管理システム、スケジューラなどの種々のシステムを採用することができる。なお、図１には、プロセス管理システム１８０が例示されている。プロセス管理システム１８０は、産業システム１００におけるプロセス定義の実体を管理し、プロセスのリアルタイムなステータスを管理する。ＣＭＤＢ１７０においても、プロセスが構成アイテムとして管理することができるが、動的に変化するステータス値は、プロセス管理に特化したプロセス管理システム１８０で管理される方がより好ましい。このため、説明する実施形態では、プロセス管理システム１８０がプロセス定義の実体を管理し、その実体定義に応じてＣＭＤＢ１７０内にプロセスＣＩが定義される構成をとる。
【００２７】
アクション決定部１５８は、上記セキュリティ・ポリシに対し、上記グループ識別済みイベント情報を適用して、推奨される対策アクションを導出する。本発明の実施形態によるアクション決定部１５８は、好ましくは、豊富化されたグループ識別済みイベント情報に含まれる依存関係を表す情報を使用して、依存関係を考慮した上で対策アクションを導出することができる。アクション決定部１５８は、より具体的には、上記セキュリティ・ポリシのマッチング記述部を評価し、記述されたマッチング条件に合致するポリシが見つかれば、その条件に対応するアクション記述部を読み出し、１以上の対策アクションを決定する。
【００２８】
上記マッチング条件は、特に限定されるものではないが、イベント情報の送信元リソースに関連するプロセスに対する条件式、イベント情報の宛先リソースに関連するプロセスに対する条件式、イベント情報の送信元リソースおよび宛先リソースに関連する両プロセスに対する条件式、イベント情報のイベントタイプに対する条件式、またはイベント情報のイベントデータに対する条件式を含むことができる。また、上記条件式は、許容される状況の範囲やアクションの範囲を規定するリソース属性情報やプロセス状況情報を引用する形式を採用することができる。
【００２９】
アクション決定部１５８は、また、対策アクションの決定に先立って、上記グループ識別済みイベント情報を用いて、対策アクションの実施対象となるリソースを選択する処理を行うことができる。実施対象となるリソースは、例えば、イベント情報の送信元リソース、宛先リソース、送信元リソース・グループ内の全部または一部のリソース、宛先リソース・グループ内の全部または一部のリソース、その他外部メールサーバなどの外部システムとすることができる。
【００３０】
アクション決定部１５８は、対策アクションが決定されると、その対策アクションをセキュリティ・ゲートウェイ１４０に通知する。セキュリティ・ゲートウェイ１４０は、アクション実施部１４４を含み、アクション実施部１４４は、解析エンジン１５０から通知された対策アクションを実際に実施する。実施され得る対策アクションとしては、特に限定されるものではないが、トラフィックのブロッキング、トラフィックの変更、新規トラフィックの発行、アラート通知を挙げることができる。
【００３１】
セキュリティ・ゲートウェイ１４０は、トラフィックからイベント情報を生成した際に、そのトラフィックを一旦ペンディングし、アクション実施部１４４は、解析エンジン１５０による解析の完了を待つ。対策アクションとしてトラフィックのブロッキングが通知されたときは、アクション実施部１４４は、対応するトラフィックをブロックする。対策アクションとしてトラフィックの変更が通知された場合は、アクション実施部１４４は、得られた対策アクションに記述された内容でペンディング中のトラフィックを変更または修正して、ペンディングを解除する。対策アクションとして新規トラフィックの発行が通知された場合、アクション実施部１４４は、対象リソースに対して停止命令など新規トラフィックを発行する。
【００３２】
以下、図２〜図５を参照しながら、ＣＭＤＢ１７０と連携した異常検知に基づく監視制御処理についてより詳細に説明する。図２は、ＣＭＤＢ１７０と連携した異常検知に基づく監視制御処理で使用されるデータを説明する図である。図２に示すイベント情報２００は、セキュリティ・ゲートウェイ１４０の監視部１４２から解析エンジン１５０に渡されるイベント情報を示す。イベント情報２００は、送信元リソースを識別する送信元ＩＤと、宛先リソースを識別する宛先ＩＤと、イベントタイプと、イベントデータとを含み構成される。送信元リソースおよび宛先リソースは、それぞれ、当該イベント情報の元となったトラフィック・データの送信元および宛先を指す。例えば、センサ１２２からのセンサ出力を制御システム１０２で受信する場合、センサ端末であるデバイス１２０を送信元とし、制御システム１０２を宛先としたトラフィック・データが、制御ネットワーク１３０内で発生する。このようなトラフィック・データがセキュリティ・ゲートウェイ１４０の監視部１４２により拾われ、イベント情報２００として解析エンジン１５０へ渡される。
【００３３】
グループ識別部１５２は、受け取ったイベント情報２００のうちの送信元ＩＤおよび宛先ＩＤを使用して、ＣＭＤＢ１７０にクエリを発行し、送信元リソースが属するグループのグループＩＤ（以下、送信元グループＩＤと参照する。）および宛先リソースが属するグループのグループＩＤ（以下、宛先グループＩＤと参照する。）を含む照会結果２０２を取得し、これをイベント情報２００に付加する。ここで、送信元リソースまたは宛先リソースがいずれのリソース・グループにも属していない場合には、照会結果２０２としてｎｕｌｌ値が取得される。
【００３４】
図３は、ＣＭＤＢ１７０内に構築される構成アイテム間の関係を模式的に表した図である。図３に示すように、ＣＭＤＢ１７０内には、１以上のプロセスＣＩおよび１以上のリソースＣＩ、並びにこれらの関係が定義される。例えば、プロセスＣＩインスタンス（「プロセスＡ」は、リソースＣＩインスタンス（「制御システムＡ」および「制御システムＢ」）に対し「ｕｓｅｄＢｙ」の関係が定義されており、これは「プロセスＡ」の実行時に「制御システムＡ」および「制御システムＢ」が使用される依存関係があることを表す。リソースＣＩインスタンス（「制御システムＡ」）は、リソースＣＩインスタンス（「デバイスＡ」）に対し「ｍａｎａｇｅｄＢｙ」の関係が定義されており、これは「デバイスＡ」が「制御システムＡ」に管理される依存関係があることを表す。その他のプロセスＣＩインスタンス、リソースＣＩインスタンスについても同様である。
【００３５】
なお、構成アイテム間の関係としては、図３に、使用関係「ｕｓｅｄＢｙ」、管理関係「ｍａｎａｇｅｄＢｙ」、必要関係「ｐｏｗｅｒｅｄＢｙ」、包含関係「ｃｏｎｔａｉｎｅｓ」を例示するが、これらに限定されるものではない。その他、「ａｓｓｉｇｎｓ」、「ｃａｎＵｓｅ」、「ｄｅｐｌｏｙｅｄＯｎ」、「Ｏｗｎｅｄ」、「ｒｕｎＡｔ」など種々の関係を定義することができ、ＣＭＤＢの実装により異なり、ユーザ定義も可能である。
【００３６】
図３には、さらに、２つのリソース・グループＡ，Ｂが示されている。リソース・グループＡは、制御システムＡ，Ｂ、デバイスＡ、機材Ａ，Ｂ、センサＡ，Ｂ，Ｃ，Ｄ、アクチュエータＡ，Ｂ，Ｃから構成されている。リソース・グループＢは、同様に、制御システムＣ、機材Ｃ、センサＥ、アクチュエータＤから構成されている。各リソース・グループに属するプロセスおよびリソースは、上述した構成アイテム間の関係によって直接的にまたは間接的に関連付けられたプロセスおよびリソースである。
【００３７】
例えばイベント情報の送信元または宛先リソースがデバイスＡであった場合、ＣＭＤＢ１７０は、グループ識別部１５２からの問い合わせに応答して、リソース・グループＡを識別するグループＩＤ、またはリソース・グループＡ内のリソースのＩＤリストを照会結果２０２に含めて回答する。上記リソース・グループＡ，Ｂは、事前に、またはグループ識別部１５２が照会する際に動的に定義することができる。リソース・グループの定義の際には、例えば「特定デバイスを利用しているプロセスとｕｓｅｄＢｙ関係があるリソース」というような条件のクエリを用いて、リソース・グループ内のＣＩの集合を得て、ＣＭＤＢ１７０内にグループをＣＩとして新規に登録することができる。
【００３８】
このようなＣＭＤＢ１７０内の構造は、ＣＭＤＢ１７０に対するマニュアル入力、ヒストリアンとの同期、資産管理システムからの通知、プロセス管理システム１８０からの定義の更新通知などの外部システムとの連携、またはディスカバリ機能やトラッキング機能による自動検出により構築される。なお、説明する実施形態では、ＣＭＤＢ１７０は、充分に短い時間間隔でディスカバリ機能およびトラッキング機能による自動検出を実施しており、さらに、上記外部システムとの連携によって適時に更新されており、ＣＭＤＢ１７０は、常に最新状態に維持されているものとする。本発明の実施形態による解析エンジン１５０は、構成アイテムとしてリソースに加えてプロセスが管理されるＣＭＤＢ１７０と連携することによって、上記プロセスを経由したリソース間の依存関係を考慮した異常検知を行う。
【００３９】
ここで、再び図２を参照する。グループ識別部１５２は、送信元グループＩＤおよび宛先グループＩＤを含む照会結果２０２を取得すると、それをイベント情報２００に付して、イベント解析部１５４へ渡す。イベント解析部１５４の情報付加部１５６は、グループ識別済みイベント情報２００，２０２を受け取ると、適宜、ポリシを適用する上で必要な情報の豊富化を行う。セキュリティ・ポリシ記憶部１６０には、１以上のポリシが記憶されており、イベント情報に対して各ポリシに適用されるため、ここでは、少なくともいずれかのポリシのマッチング記述部において条件式が定義されている属性情報等がすべて取得される。より具体的には、情報付加部１５６は、グループ識別済みイベント情報２００，２０２のうちの、送信元グループＩＤおよび宛先グループＩＤを使用して、ＣＭＤＢ１７０に照会して、送信元グループおよび宛先グループに関連する種々の属性情報を取得する。
【００４０】
以下、ＣＭＤＢ１７０のデータ構造を参照しながら、情報付加部１５６が取得する属性情報について説明する。図４は、構築されたＣＭＤＢ１７０のデータ構造を例示する図である。図４に示す構成アイテムテーブル２２０は、構成アイテムの名称を保管するフィールド２２２と、構成アイテムのカテゴリを保管するフィールド２２４と、構成アイテムの上記カテゴリをさらに細分化したモデルを保管するフィールド２２６と、属性フィールド２２８と、関係フィールド２３０とを含む。関係フィールド２３０は、当該構成アイテムに対して定義されている１以上の関係に関する情報を保管し、関係の種類と、当該構成アイテムの相手方の構成アイテムを識別する名称（または識別番号等）とが保管される。
【００４１】
属性フィールド２２８は、１以上の属性（Attribute）および属性値のセットを保管する。属性は、個々の構成アイテムを特定し、説明するものである。属性としては、特に限定されるものではないが、構成アイテムの名称、識別番号、カテゴリ（リソースおよびプロセスの別を識別する。）、タイプ（制御システム、機材、デバイス、センサ、アクチュエータなどを識別する。）、その他、型番、目的、所有者、発行者、ロケーション、保証期間、バージョン番号、開始日時や完了予定日時や期限などのスケジュール、ステータス、重要度などを挙げることができる。さらに本実施形態では、リソースＣＩについては、さらに、許容される状況の範囲（定格値、想定値など）、許容されるアクションの範囲（開始、停止、変更）などを含むことができる。
【００４２】
なお、構成アイテムの属性は、定義拡張が可能とされており、上述したものに限られるものでなく、またクラス（タイプおよびカテゴリで分類される。）毎に内容を相違させることもできる。本発明の実施形態においては、異常を検知する際に属性情報を使用する場合があるため、少なくともこのような異常検知に用いられる属性が定義されていればよい。なお、図４に示すデータ構造は一例であり、特に限定されるものではなく、他の実施形態では、関係フィールド２３０の内容等を別のテーブルで管理することもできる。
【００４３】
本実施形態では、ＣＭＤＢ１７０内には、プロセスとリソースとの間、リソース間、リソース・グループとリソースおよびプロセスとの間の関係が定義されている。このため、情報付加部１５６は、上記送信元グループＩＤおよび宛先グループＩＤを用いてＣＭＤＢ１７０に照会することにより、送信元および宛先グループに関連する種々の属性情報を取得し、グループ識別済みイベント情報２００，２０２を豊富化することができる。グループに関連する種々の属性情報としては、送信元リソース・グループおよび宛先リソース・グループの各種属性情報（以下、グループ属性情報と参照する。）２０６、これらリソース・グループ内の各リソースの属性情報（以下、リソース属性情報と参照する。）２０８、およびプロセスの各種属性情報（以下、プロセス属性情報と参照する。）２１０を含むことができる。
【００４４】
例えば、上記許容される状況の範囲（定格値や想定値）、許容されるアクションの範囲（開始、停止、変更）などの属性値に対する条件式がポリシのマッチング記述部内に記述されていれば、これら許容される範囲の情報を用いて、許容範囲内か範囲外か、あるいは想定範囲内か想定範囲外かを判定し、異常を検出することが可能となる。なお、上記許容される状況の範囲や許容されるアクションの範囲は、その最小値および最大値により規定されたり、限定的に列挙することにより取り得る値が規定されたりする。
【００４５】
また情報付加部１５６は、上記ＣＭＤＢ１７０から取得した送信元リソース・グループおよび宛先リソース・グループ内の各プロセスのプロセスＩＤを用いて、プロセス管理システム１８０に対し照会して、送信元グループおよび宛先グループ内の各プロセスに関するステータス値など動的な状況情報（以下、プロセス状況情報と参照する。）２１２を取得することができる。以下、プロセス管理システム１８０が管理するデータ構造を参照して、情報付加部１５６が取得する情報について説明する。
【００４６】
図５は、プロセス管理システム１８０が管理するプロセスに関するデータ構造を例示する図である。図５に示すプロセス管理テーブル２４０は、プロセスを識別するプロセスＩＤを保管するフィールド２４２と、プロセスの名称を保管するフィールド２４４と、プロセスのカテゴリを保管するフィールド２４６と、プロセスの動的なステータスを保管するフィールド２４８とを含む。さらに、プロセス管理テーブル２４０は、期限、開始日時、完了予定日時などのスケジュールを保管する複数のフィールド２５０〜２５４と、プロセスの発行者および所有者を保管する複数のフィールド２５６，２５８と、重要度を保管するフィールド２６０とを含む。図５に示すプロセス管理テーブル２４０は、図４に示した構成アイテムテーブル２２０と重複する情報も含んでいるが、本実施形態のプロセス管理システム１８０は、ＣＭＤＢ１７０と異なり、フィールド２４８に保管される動的に変化するステータスを保管しており、このような動的な状況情報を用いて、リアルタイムな状況を反映して異常を検出することが可能となる。
【００４７】
再び図２を参照すると、上記情報付加部１５６は、送信元グループＩＤおよび宛先グループＩＤを使用して、ＣＭＤＢ１７０およびプロセス管理システム１８０またはこれらのいずれか一方から、上記グループ属性情報２０６、リソース属性情報２０８、プロセス属性情報２１０およびプロセス状況情報２１２を含むグループ関連情報２０４を取得すると、これらをグループ識別済みイベント情報２００，２０２に付加する。豊富化されたイベント情報２００，２０２，２０４は、上述したように、アクション決定部１５８によりセキュリティ・ポリシに対し適用されて、対策アクションが導出される。以下、フローチャートを参照しながら、本発明の実施形態による上記豊富化されたイベント情報とセキュリティ・ポリシとを用いた異常検知処理について詳細を説明する。
【００４８】
図６は、本発明の実施形態による解析エンジン１５０が実行する、異常検知処理を示すフローチャートである。図６に示す処理は、セキュリティ・ゲートウェイ１４０の監視部１４２が、制御ネットワーク１３０からトラフィック・データを拾ってイベント情報を発信したことに応答して、ステップＳ１００から開始する。あるいは、他の実施形態では、上記イベント情報が監視部１４２から発信され、処理待ちのイベント情報を格納する待ちキューに投入されたことに応答して、イベント情報毎にステップＳ１００から開始する。ステップＳ１０１では、グループ識別部１５２は、セキュリティ・ゲートウェイ１４０の監視部１４２からイベント情報２００を受信する。ステップＳ１０２では、グループ識別部１５２は、イベント情報２００に含まれる送信元ＩＤおよび宛先ＩＤを用いてＣＭＤＢ１７０に照会し、送信元リソースおよび宛先リソースが属するリソース・グループをそれぞれ決定し、照会結果２０２をイベント情報２００に付加する。
【００４９】
ステップＳ１０３では、情報付加部１５６は、セキュリティ・ポリシ記憶部１６０に記憶されている有効なすべてのセキュリティ・ポリシ中の、外部情報を必要とするマッチング条件を検索し、外部情報として取得する必要のある情報を抽出する。ステップＳ１０４では、情報付加部１５６は、外部情報が必要であるか否かを判定する。ステップＳ１０４で外部情報が必要であると判定された場合（ＹＥＳ）には、ステップＳ１０５へ処理が分岐される。ステップＳ１０５では、情報付加部１５６は、ＣＭＤＢ１７０およびプロセス管理システム１８０またはこれらのいずれか一方に照会し、マッチング記述部の評価に必要な情報を取得し、イベント情報２００，２０２に付加し、ステップＳ１０６へ処理を進める。一方、ステップＳ１０４で外部情報が必要ではないと判定された場合（ＮＯ）には、ステップＳ１０６へ直接処理が進められる。
【００５０】
ここで、図７〜図１１を参照しながら、セキュリティ・ポリシの詳細について説明する。図７（Ａ）〜（Ｃ）、図８（Ａ）および（Ｂ）、図９（Ａ）および（Ｂ）、図１０（Ａ）および（Ｂ）並びに図１１（Ａ）および（Ｂ）は、それぞれセキュリティ・ポリシのデータ構造を例示する。図７〜図１１に示すように、各セキュリティ・ポリシは、マッチング条件を記述するマッチング記述部と、１以上の対策アクションを記述するアクション記述部とを含む。図７（Ａ）に示すセキュリティ・ポリシは、識別番号として「１」が付されたポリシであって、送信元リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベント情報に含まれるイベントデータが送信元リソースの許容値の範囲外である場合に、対策アクションとして、送信元グループ内のすべてのリソースを対象とし、イベントタイプが「操作」であるすべてのイベントを遮断する、という内容を記述している。
【００５１】
図７（Ａ）に示すセキュリティ・ポリシが適用される場合、情報付加部１５６は、ステップＳ１０５で、マッチング記述部の評価のために必要な情報として、送信元ＩＤで識別されるリソースが属する送信元リソース・グループ内のプロセスの状況情報（ステータス値）をプロセス管理システム１８０から取得し、送信元リソースの属性情報（許容される範囲）をＣＭＤＢ１７０から取得する。図７（Ａ）に示すポリシにおいては、取得されたプロセスのステータス値については、これに対する条件式が直接記述されており、取得されたリソースの許容される範囲の属性値については、これを引用する形式でイベントデータに対する条件式が記述されている。
【００５２】
図７（Ｂ）に示すセキュリティ・ポリシは、識別番号として「２」が付されたポリシであって、送信元ＩＤで識別される送信元リソースを利用するプロセスが存在せず（送信元ＩＤに対するグループＩＤの照会に対してｎｕｌｌ値が返る場合が対応する。）、かつ、イベントタイプが「センサデータ」である場合に、対策アクションとして、外部メール・システムを対象としアラート送信を行う、という内容を記述している。図７（Ｂ）に示すセキュリティ・ポリシが適用される場合、情報付加部１５６は、ステップＳ１０５で、必要な情報として、ＣＭＤＢ１７０から送信元リソースが属する送信元リソース・グループのグループＩＤおよびその属性情報を取得することができる。しかしながら、送信元リソース・グループを識別するグループＩＤは、グループ識別部１５２が既に取得されてイベント情報に付されているため、それ以外の情報が必要ない場合には、情報付加部１５６は、図７（Ｂ）に示すセキュリティ・ポリシに関して、特にマッチング記述部の評価のために必要な情報を取得しなくともよい。
【００５３】
図７（Ｃ）に示すセキュリティ・ポリシは、識別番号として「３」が付されたポリシであって、宛先リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベントタイプが「操作」であり、かつ、イベント情報に含まれるイベントデータが宛先リソースの最大許容値を超える場合に、対策アクションとして、宛先リソースを対象とし、当該イベント情報に対応するトラフィック・データのイベントデータを宛先デバイスの最大許容値に修正する、という内容を記述している。図７（Ｃ）に示すセキュリティ・ポリシが適用される場合、情報付加部１５６は、ステップＳ１０５で、必要な情報として、宛先リソースが属する宛先リソース・グループのプロセスの状況情報（ステータス値）をプロセス管理システム１８０から取得し、宛先リソースの属性情報（許容される範囲における最大値）をＣＭＤＢ１７０から取得する。
【００５４】
図８〜図１１に示すポリシが適用される場合についても同様であり、情報付加部１５６は、ステップＳ１０５で、マッチング記述部の評価のために必要な情報として、送信元または宛先リソースを利用するプロセスの情報（ステータス値や重要度など）、送信元または宛先リソースに関する情報（許容される範囲の最大値および最小値など）をプロセス管理システム１８０およびＣＭＤＢ１７０またはこれらのいずれか一方から取得することができる。
【００５５】
再び図６を参照すると、ステップＳ１０６では、アクション決定部１５８は、イベント情報２００，２０２，２０４が合致するマッチング条件を検索し、対応するアクション記述部を取得する。ステップＳ１０７では、アクション決定部１５８は、マッチング条件が真のポリシが存在するか否かを判定する。ステップＳ１０７で、マッチング条件が真のポリシが存在しないと判定された場合（ＮＯ）には、ステップＳ１１１へ処理を直接進め、本処理を終了し、次のイベント情報の処理が開始されるまで待ち受ける。一方、ステップＳ１０７で、マッチング条件が真のポリシが存在すると判定された場合（ＹＥＳ）には、ステップＳ１０８へ処理を分岐させる。
【００５６】
ステップＳ１０８では、アクション決定部１５８は、対応するアクション記述部の内容から、イベント情報の送信元および宛先リソース以外のリソースへの対策アクションを含むか否かを判定する。ステップＳ１０８で、送信元および宛先以外のリソースへのアクションを含むと判定された場合（ＹＥＳ）には、ステップＳ１０９へ処理を分岐させる。ステップＳ１０９では、情報付加部１５６は、イベント情報２００，２０２と、ＣＭＤＢ１７０およびプロセス管理システム１８０またはこれらのいずれか一方に照会して得た情報２０４とを使用して、アクション対象を決定し、ステップＳ１１０へ処理を進める。例えば、図７（Ａ）に示すポリシの場合、情報付加部１５６は、実施対象を選択するために必要な情報として、送信元リソースが属する送信元リソース・グループ内の他のリソースＩＤリストをＣＭＤＢ１７０から取得し、この取得されたリソースＩＤを対象に設定することができる。
【００５７】
ステップＳ１０８で、送信元および宛先以外のリソースへのアクションを含まないと判定された場合（ＮＯ）には、ステップＳ１１０へ処理を直接進める。ステップＳ１１０では、アクション決定部１５８は、送信元および宛先またはこれらのいずれか一方をアクション対象として、推奨される対策アクションを導出し、アクション対象および対策アクションをセキュリティ・ゲートウェイ１４０の実施部１４４に通知し、ステップＳ１１１で本処理を終了させる。
【００５８】
ここで、再び図７〜図１１を参照すると、図７（Ａ）に示すポリシによれば、プロセスにより利用されているリソースにおいて、許容できない値の操作が観測された場合に、そのプロセスが利用しているすべてのリソース（同一リソース・グループ内のすべてのリソース）への操作イベントを遮断することができる。また、図７（Ｂ）に示すポリシによれば、いずれのプロセスからも使用されておらず、使用計画もないリソースからセンサデータが出力されている場合に、その出力を不穏な挙動（異常）として検出し、アラートを発することができる。さらに図７（Ｃ）に示すポリシによれば、プロセスにより利用されているリソースにおいて、許容できない値の操作が観測された場合に、トラフィック・データを適正な値に修正することができ、異常操作を補正し、障害発生を予防することができる。
【００５９】
また図８（Ａ）に示すセキュリティ・ポリシは、識別番号として「４」が付されたポリシであって、送信元リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベント情報に含まれるイベントデータが送信元リソースの許容値の範囲外であり、かつ、イベント情報に含まれるイベントタイプが「操作」である場合に、対策アクションとして、宛先グループ内のすべてのリソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図８（Ａ）に示すポリシによれば、プロセスにより利用されているリソースからの異常イベントを検出し、同じプロセスで利用されているすべてのリソースへの操作を禁止することにより、不正侵入防止（ＩＰＳ）を実現することができる。
【００６０】
図８（Ｂ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベント情報に含まれるイベントデータが送信元リソースの許容値の範囲外である場合に、対策アクションとして、送信元グループ内のすべてのリソースを対象とし、リソースの緊急停止を指令する新規トラフィックを発行する、という内容を記述している。図８（Ｂ）に示すポリシによれば、プロセスにより利用されているリソースからの異常イベントを検出し、同じプロセスで利用されているすべてのリソースへ緊急停止を指令することにより、侵入の疑いのあるリソースの緊急停止を実施することができる。
【００６１】
図９（Ａ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスのプロセスＩＤが宛先リソースを利用するプロセスのプロセスＩＤと一致しない場合に、対策アクションとして、送信元グループ内のすべてのリソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図９（Ａ）に示すセキュリティ・ポリシによれば、異なるプロセスで利用されているリソース間の通信を検出し、通信をブロックすることができ、プロセス毎に独立な仮想的ネットワークを構成することができる。
【００６２】
図９（Ｂ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスの重要度が「ＨＩＧＨ」であり、かつ、イベント情報に含まれるイベントタイプが「操作」である場合に、対策アクションとして、宛先グループ内のすべてのリソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図９（Ｂ）に示すセキュリティ・ポリシによれば、重要度の高いプロセスで利用されるリソースへの操作を検出し、通信をブロックすることができ、ファイアウォールのフィルタのような働きを実現することができる。
【００６３】
図１０（Ａ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスの重要度が、宛先リソースを利用するプロセスの重要度より小さい場合に、対策アクションとして、宛先グループ内のすべてのリソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図１０（Ａ）に示すセキュリティ・ポリシによれば、重要度の低いプロセスで利用されるデバイスグループのリソースから、重要度の高いプロセスで利用されるデバイスグループへの通信を検出し、通信をブロックすることができ、セキュリティ・レベルに応じたゾーニング（zoning）を実現することができる。
【００６４】
図１０（Ｂ）に示すセキュリティ・ポリシは、送信元リソースを利用するプロセスの重要度が「ＬＯＷ」であり、かつ、イベント情報に含まれるイベントデータが送信元リソースの許容される範囲内である場合に、対策アクションとして、送信元リソースを対象とし、すべてのイベントを遮断する、という内容を記述している。図１０（Ｂ）に示すセキュリティ・ポリシによれば、重要度の低いプロセスで利用されるリソースからのセンサ値が許容される範囲内であった場合に通信をブロックすることができ、重要度の低い通常状態データのトラフィックを削減することができる。
【００６５】
以上図７〜図１０を参照しながら、種々のセキュリティ・ポリシについて説明してきたが、上述までのセキュリティ・ポリシは、セキュリティ・ゲートウェイ１４０から通知されるイベント情報毎に、解析をして異常の検知を試み、異常が見つかった場合に対策アクションを実施させるというものであった。しかしながら、セキュリティ・ポリシは、単一のイベント情報に対して規定されるのみならず、イベント情報毎の解析結果を一旦記憶しておき、現在処理対象であるイベント情報の送信元若しくは宛先に関連して蓄積された履歴情報（過去に発生したイベント情報）に関する条件式を含めて、マッチング条件を記述することができる。これにより、複数のイベント情報の組み合わせ、シーケンスまたは統計に対応して、選択的または段階的に対策アクションを導出することができる。図１１（Ａ）および（Ｂ）は、このような複数のイベント情報に対応して段階的に対策アクションを導出するためのセキュリティ・ポリシを例示する。
【００６６】
図１１（Ａ）に示すセキュリティ・ポリシは、宛先リソースを利用するプロセスのステータスが「稼働中」であり、かつ、イベントタイプが「操作」であり、かつ、イベント情報のイベントデータが宛先リソースの最大許容値を超える場合であって、宛先グループ全体についての異常の発生（許容範囲外とされる異常に限る。）が１時間に５回未満の頻度であったときに、所定の対策アクションを実施するという内容を規定する。上記所定の対策アクションとしては、図１１（Ａ）には、宛先リソースを対象としてイベントデータを修正するという対策アクションと、内部状態の記録として宛先グループについて異常の発生（許容範囲外とされる異常に限る。）を記録するという追加の対策アクションとが記述されている。異常の発生は、例えば、発生日時と異常の内容とをレコードとした、解析エンジン１５０の内部の一時的な履歴データとして記録することができる。このような内部で保持される履歴情報は、例えば、情報付加部１５６が、マッチング記述部の評価のために必要な情報として適宜取得することができる。
【００６７】
これに対して図１１（Ｂ）に示すセキュリティ・ポリシは、宛先グループ全体についての異常の発生（許容範囲外とされる異常に限る。）が１時間に５回以上の頻度で発生するという条件を除き、図１１（Ａ）に示すポリシと同様のマッチング条件を規定する。そして、図１１（Ｂ）に示すセキュリティ・ポリシは、上述したマッチング条件が満たされるときの対策アクションとして、宛先グループ内のすべてのリソースを対象として、リソースの緊急停止を指令する新規トラフィックを発行するという対策アクションと、内部状態の記録として宛先グループについて異常の発生の記録をリセットするという追加の対策アクションとを記述している。
【００６８】
上述した図１１（Ａ）および（Ｂ）に示す２つのセキュリティ・ポリシの組み合わせによれば、イベント情報に含まれるイベントデータが宛先リソースの最大許容値を超える場合、当該イベント情報に対応するトラフィック・データのイベントデータを宛先デバイスの最大許容値に修正するという対策アクションを実施しつつ、同一ルール違反の発生が所定の頻度を超えたときに、上記イベントデータの修正に代えて、停止イベントを発生させる対策アクションを実施するという、段階的な対策アクションの導出を可能とする。
【００６９】
以上説明したように、上述までの実施形態による監視制御によれば、構成管理データベース１７０を利用することで、制御ネットワーク１３０におけるプロセス、リソース間の依存関係を考慮して制御ネットワーク１３０内の現在の状況を解析し、リソース・グループ全体の振る舞いとして異常の疑われる状況をも好適に検知することができる。そして、制御ネットワーク１３０におけるプロセス、リソース間の依存関係を考慮して、適切な対策アクションおよびアクションを実施させる対象を決定することができる。したがって、アクチュエータ等のリソース単独の動きからは容易に判別し得ない異常を好適に検知することが可能となり、ひいては、産業制御システムのオープン化に伴うセキュリティ低下を好適に防止することができる。
【００７０】
なお、上記解析エンジン１５０は、それ単独で、１又は複数の汎用コンピュータからなる汎用コンピュータ・システム上に実装されてもよく、特定用途の機器として実装されてもよく、また他の実施形態では、セキュリティ・ゲートウェイ１４０の機能と一体として実装されてもよい。
【００７１】
以上説明したように、本発明の実施形態によれば、構成管理データベースを利用して、制御システムにおけるデバイス、機材、センサ、アクチュエータなどの構成要素間の依存関係を考慮し、構成要素間でネットワークを流れるデータ・トラフィックから異常が疑われる振る舞いを検知し、迅速に対策アクションを起こすことが可能な異常検知装置、監視制御システム、異常検知方法、プログラムおよび記録媒体を提供することができる。
【００７２】
本発明の実施形態による解析エンジンは、コンピュータ実行可能なプログラムを、コンピュータにロードして各機能部を実現することにより、異常検知装置として提供される。このようなプログラムとしては、例えば、ＦＯＲＴＲＡＮ、ＣＯＢＯＬ、ＰＬ／Ｉ、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなどのレガシー・プログラミング言語やオブジェクト指向プログラミング言語などで記述された、コンピュータ実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布することができる。
【００７３】
これまで本発明を図面に示した実施形態および実施例をもって説明してきたが、本発明は図面に示した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【符号の説明】
【００７４】
１００…産業システム、１０２…制御システム、１０４…コンソール・システム、１０６…保守システム、１０８…分析システム、１１０…機材、１１２…センサ、１１４…アクチュエータ、１２０…デバイス、１２２…センサ、１２４…アクチュエータ、１３０…制御ネットワーク、１４０…セキュリティ・ゲートウェイ、１４２…監視部、１４４…アクション実施部、１５０…解析エンジン、１５２…グループ識別部、１５４…イベント解析部、１５６…情報付加部、１５８…アクション決定部、１６０…セキュリティ・ポリシ記憶部、１７０…構成管理データベース（ＣＭＤＢ）、１８０…プロセス管理システム、２００…イベント情報、２０２…照会結果、２０４…グループ関連情報、２０６…グループ属性情報、２０８…リソース属性情報、２１０…プロセス属性情報、２１２…プロセス状況情報、２２０…構成アイテムテーブル、２２２〜２３０…フィールド、２４０…プロセス管理テーブル、２４２〜２６０…フィールド
【特許請求の範囲】
【請求項１】
１以上の制御システムを含む制御ネットワークの異常を検知する異常検知装置であって、
前記制御ネットワーク内で発生したイベント情報を受信して、前記制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別する識別部と、
異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部と、
前記１以上のポリシを適用する上で必要となる前記グループに関連する情報を取得し、前記イベント情報に付加する付加部と、
前記１以上のポリシに対し前記イベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する決定部と
を含む、異常検知装置。
【請求項２】
前記グループに関連する情報は、外部システムから取得される前記グループに属するプロセスの状況情報、前記グループに属するプロセスの属性情報および前記グループに属するリソースの属性情報またはこれらの少なくとも１つの情報を含み、前記条件は、前記グループに関連する情報を条件式に含む、請求項１に記載の異常検知装置。
【請求項３】
前記リソースの属性情報は、前記リソースで許容される状況の範囲および許容されるアクションの範囲またはこれらの一方を規定し、前記条件は、前記範囲を規定する属性情報を引用する条件式を含む、請求項２に記載の異常検知装置。
【請求項４】
前記条件は、前記イベント情報の送信元リソースに関連するプロセスに対する条件式、前記イベント情報の宛先リソースに関連するプロセスに対する条件式、前記イベント情報の送信元リソースおよび宛先リソースに関連する両プロセスに対する条件式、前記イベント情報のイベントタイプに対する条件式、前記イベント情報のイベントデータに対する条件式、または前記イベント情報の送信元若しくは宛先に関連して過去に発生したイベント情報に関する条件式を含む、請求項３に記載の異常検知装置。
【請求項５】
前記ポリシは、前記アクションを実施させる対象リソースを規定する記述を含み、前記決定部は、前記記述に従って、前記グループに属するリソースの全部または一部を前記対象リソースとして決定する、請求項１に記載の異常検知装置。
【請求項６】
前記識別部は、受信したイベント情報に含まれる送信元リソースの識別値、宛先リソースの識別値、イベントタイプおよびイベントデータに、それぞれ前記送信元リソースまたは前記宛先リソースが属するグループを識別するグループ識別値、または該グループに属するリソースの識別値のリストを付する、請求項１に記載の異常検知装置。
【請求項７】
前記アクションは、トラフィックのブロッキング、トラフィックの変更、新規トラフィックの発行、アラート通知を含み、前記制御ネットワークは、制御システム、デバイス、装置、センサおよびアクチュエータからなる群から選択された１種または２種以上のリソースを複数含む、請求項１に記載の異常検知装置。
【請求項８】
１以上の制御システムを含む制御ネットワークを監視するセキュリティ・ゲートウェイと、前記制御ネットワークの異常を検知する解析エンジンとを備える監視制御システムであって、前記解析エンジンは、
前記制御ネットワーク内で発生したイベント情報を受信して、前記制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別する識別部と、
異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部と、
前記１以上のポリシを適用する上で必要となる前記グループに関連する情報を取得し、前記イベント情報に付加する付加部と、
前記１以上のポリシに対し前記イベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する決定部と
を含み、前記セキュリティ・ゲートウェイは、
前記制御ネットワーク内のトラフィック・データを監視し、イベントを拾い上げて、前記イベント情報として発信する監視部と、
決定されたアクションを実施する実施部と
を含む、監視制御システム。
【請求項９】
前記識別部は、前記セキュリティ・ゲートウェイの前記監視部から前記イベント情報を受信し、前記決定部は、前記イベント情報に応じて決定された前記アクションを前記セキュリティ・ゲートウェイの前記実施部に対し通知することで実施させる、請求項８に記載の監視制御システム。
【請求項１０】
１以上の制御システムを含む制御ネットワークの異常を検出するための異常検出装置が実行する方法であって、
前記異常検出装置が、前記制御ネットワーク内で発生したイベント情報を受信して、前記制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別するステップと、
前記異常検出装置が、異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシに対し前記イベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定するステップとを含み、
前記異常検出装置が、前記１以上のポリシを適用する上で必要となる前記グループに関連する情報を取得し、前記イベント情報に付加するステップをさらに含む、異常検出方法。
【請求項１１】
前記付加するステップは、前記アクションを決定するステップの前に行われ、
前記異常検出装置が、外部システムから取得される前記グループに属するプロセスの状況情報、前記グループに属するプロセスの属性情報および前記グループに属するリソースの属性情報またはこれらの少なくとも１つの情報を取得するステップを含み、前記条件は、前記グループに関連する情報を条件式に含む、請求項１０に記載の異常検出方法。
【請求項１２】
前記リソースの属性情報は、前記リソースで許容される状況の範囲および許容されるアクションの範囲またはこれらの一方を規定し、前記条件は、前記範囲を規定する属性情報を引用する条件式を含む、請求項１１に記載の異常検出方法。
【請求項１３】
コンピュータ・システム上に、１以上の制御システムを含む制御ネットワークの異常を検知する異常検知装置を実現するためのコンピュータ実行可能なプログラムであって、前記コンピュータ・システムを、
前記制御ネットワーク内で発生したイベント情報を受信して、前記制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別する識別部、
異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部、
前記１以上のポリシを適用する上で必要となる前記グループに関連する情報を取得し、前記イベント情報に付加する付加部、および
前記１以上のポリシに対し前記イベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する決定部
として機能させるためのプログラム。
【請求項１４】
請求項１３に記載のコンピュータ実行可能なプログラムをコンピュータ読取可能に格納する記録媒体。
【請求項１】
１以上の制御システムを含む制御ネットワークの異常を検知する異常検知装置であって、
前記制御ネットワーク内で発生したイベント情報を受信して、前記制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別する識別部と、
異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部と、
前記１以上のポリシを適用する上で必要となる前記グループに関連する情報を取得し、前記イベント情報に付加する付加部と、
前記１以上のポリシに対し前記イベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する決定部と
を含む、異常検知装置。
【請求項２】
前記グループに関連する情報は、外部システムから取得される前記グループに属するプロセスの状況情報、前記グループに属するプロセスの属性情報および前記グループに属するリソースの属性情報またはこれらの少なくとも１つの情報を含み、前記条件は、前記グループに関連する情報を条件式に含む、請求項１に記載の異常検知装置。
【請求項３】
前記リソースの属性情報は、前記リソースで許容される状況の範囲および許容されるアクションの範囲またはこれらの一方を規定し、前記条件は、前記範囲を規定する属性情報を引用する条件式を含む、請求項２に記載の異常検知装置。
【請求項４】
前記条件は、前記イベント情報の送信元リソースに関連するプロセスに対する条件式、前記イベント情報の宛先リソースに関連するプロセスに対する条件式、前記イベント情報の送信元リソースおよび宛先リソースに関連する両プロセスに対する条件式、前記イベント情報のイベントタイプに対する条件式、前記イベント情報のイベントデータに対する条件式、または前記イベント情報の送信元若しくは宛先に関連して過去に発生したイベント情報に関する条件式を含む、請求項３に記載の異常検知装置。
【請求項５】
前記ポリシは、前記アクションを実施させる対象リソースを規定する記述を含み、前記決定部は、前記記述に従って、前記グループに属するリソースの全部または一部を前記対象リソースとして決定する、請求項１に記載の異常検知装置。
【請求項６】
前記識別部は、受信したイベント情報に含まれる送信元リソースの識別値、宛先リソースの識別値、イベントタイプおよびイベントデータに、それぞれ前記送信元リソースまたは前記宛先リソースが属するグループを識別するグループ識別値、または該グループに属するリソースの識別値のリストを付する、請求項１に記載の異常検知装置。
【請求項７】
前記アクションは、トラフィックのブロッキング、トラフィックの変更、新規トラフィックの発行、アラート通知を含み、前記制御ネットワークは、制御システム、デバイス、装置、センサおよびアクチュエータからなる群から選択された１種または２種以上のリソースを複数含む、請求項１に記載の異常検知装置。
【請求項８】
１以上の制御システムを含む制御ネットワークを監視するセキュリティ・ゲートウェイと、前記制御ネットワークの異常を検知する解析エンジンとを備える監視制御システムであって、前記解析エンジンは、
前記制御ネットワーク内で発生したイベント情報を受信して、前記制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別する識別部と、
異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部と、
前記１以上のポリシを適用する上で必要となる前記グループに関連する情報を取得し、前記イベント情報に付加する付加部と、
前記１以上のポリシに対し前記イベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する決定部と
を含み、前記セキュリティ・ゲートウェイは、
前記制御ネットワーク内のトラフィック・データを監視し、イベントを拾い上げて、前記イベント情報として発信する監視部と、
決定されたアクションを実施する実施部と
を含む、監視制御システム。
【請求項９】
前記識別部は、前記セキュリティ・ゲートウェイの前記監視部から前記イベント情報を受信し、前記決定部は、前記イベント情報に応じて決定された前記アクションを前記セキュリティ・ゲートウェイの前記実施部に対し通知することで実施させる、請求項８に記載の監視制御システム。
【請求項１０】
１以上の制御システムを含む制御ネットワークの異常を検出するための異常検出装置が実行する方法であって、
前記異常検出装置が、前記制御ネットワーク内で発生したイベント情報を受信して、前記制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別するステップと、
前記異常検出装置が、異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシに対し前記イベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定するステップとを含み、
前記異常検出装置が、前記１以上のポリシを適用する上で必要となる前記グループに関連する情報を取得し、前記イベント情報に付加するステップをさらに含む、異常検出方法。
【請求項１１】
前記付加するステップは、前記アクションを決定するステップの前に行われ、
前記異常検出装置が、外部システムから取得される前記グループに属するプロセスの状況情報、前記グループに属するプロセスの属性情報および前記グループに属するリソースの属性情報またはこれらの少なくとも１つの情報を取得するステップを含み、前記条件は、前記グループに関連する情報を条件式に含む、請求項１０に記載の異常検出方法。
【請求項１２】
前記リソースの属性情報は、前記リソースで許容される状況の範囲および許容されるアクションの範囲またはこれらの一方を規定し、前記条件は、前記範囲を規定する属性情報を引用する条件式を含む、請求項１１に記載の異常検出方法。
【請求項１３】
コンピュータ・システム上に、１以上の制御システムを含む制御ネットワークの異常を検知する異常検知装置を実現するためのコンピュータ実行可能なプログラムであって、前記コンピュータ・システムを、
前記制御ネットワーク内で発生したイベント情報を受信して、前記制御システムを含むリソースおよびプロセス間の依存関係を維持する構成管理データベースに照会し、該イベント情報に関わるリソースが属するグループを識別する識別部、
異常が疑われる状況を規定する条件と１以上のアクションとを対応付ける１以上のポリシを記憶するポリシ記憶部、
前記１以上のポリシを適用する上で必要となる前記グループに関連する情報を取得し、前記イベント情報に付加する付加部、および
前記１以上のポリシに対し前記イベント情報を適用し、合致する条件に対応付けられるアクションを実施するべきアクションとして決定する決定部
として機能させるためのプログラム。
【請求項１４】
請求項１３に記載のコンピュータ実行可能なプログラムをコンピュータ読取可能に格納する記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１２−１６８６８６（Ｐ２０１２−１６８６８６Ａ）
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願番号】特願２０１１−２８３４１（Ｐ２０１１−２８３４１）
【出願日】平成２３年２月１４日（２０１１．２．１４）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【復代理人】
【識別番号】１００１１０６０７
【弁理士】
【氏名又は名称】間山 進也
【Ｆターム（参考）】
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願日】平成２３年２月１４日（２０１１．２．１４）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【復代理人】
【識別番号】１００１１０６０７
【弁理士】
【氏名又は名称】間山 進也
【Ｆターム（参考）】
[ Back to top ]