JP6433851B2 - 情報収集システムおよび方法 - Google Patents

Description

本発明は、制御システムにおける情報収集システムおよび方法に関し、特に制御システムで発生するサイバー攻撃等のインシデントを検知する情報収集システムおよび方法に関する。

電力、鉄道、水道、ガスといった社会インフラや自動車を制御する制御システムは、センサによる制御対象の状態情報をもとにバルブやアクチュエータといった装置を動作させ、制御対象の状態を、あらかじめ設定されている状態（たとえば、圧力や温度）に保つことが要求される。この要求を満たすために、制御システムはセンサからの状態情報を取得し、制御対象の状態を確認し、必要に応じて制御対象を制御する。

制御システムは、一般に周期的に処理を実行し、周期的に実行される処理は１周期の間で完結することが要求される。すなわち、処理が１周期を超えて実行されると、１周期の時間を基準とする速度や状態の変化情報に基づいて、制御システムは制御対象を制御できないことになる。したがって、制御対象の状態によって処理時間が長くなっても、１周期の間で完結することが要求される。このような処理時間の制約を満たすように構築されている制御システムの周期や周期内の空き時間は、電力、鉄道、水道、自動車といった制御対象によって異なる。

これまでの制御システムの多くは、専用ＯＳや専用プロトコルを利用していたので、インターネット等の外部ネットワークからアクセスされなかった。したがって、制御システムは、コンピュータウィルスやＤｏＳ攻撃といったサイバー攻撃を考慮に入れて設計、運用する必要がなかった。しかしながら、制御システムの運用効率向上および/または開発や運用に係るコスト削減のために、汎用ＯＳや汎用プロトコルの利用、さらに外部ネットワークとの接続などが進められ、制御システムは変化している。制御システムの変化は、コンピュータウィルスや外部からの不正アクセスへの対応を必要としている。

このような課題に対して、特許文献１は、制御システム内で用いる通信のパターン（送信元、送信先、プロトコル等）やデータのフォーマットをリスト化し、リスト化されたパターンに合致しない通信を不正な通信として検知することを開示している。

非特許文献１は、通信パケットに認証データを付与し、正当な認証データを持たない通信パケットを不正な通信パケットとして識別することを開示している。

特許文献２は、ネットワーク負荷、監視端末の処理負荷を考慮し、保護対象となるデータに対する不正アクセス情報の監視端末への送信の要否を条件に基づいて決定することを開示している。

特開２０１２−３４２７３号公報 特開２００５−１８１８６号公報

S．Kent，K．Seo，"Security Architecture for the Internet Protocol(RFC4301)"，[online]， ２００５年１２月，IETF，[２０１４年１１月２５日検索］，インターネット＜URL: https://tools．ietf．org/html/rfc4301＞

制御システムの変化に伴う、コンピュータウィルスや外部からの不正アクセスへの対応として、特許文献１および非特許文献１は、不正な通信の検知または不正な通信パケットの識別について、また特許文献２はネットワーク負荷、監視端末の処理負荷を考慮し、送信すべき不正アクセス情報の絞り込みについて開示しているが、制御システムの周期的な処理の実行に伴う処理時間の制約について考慮されていない。

処理時間の制約を満たさない制御システムは制御対象を制御できないことになるので、情報収集システムは、処理時間の制約を満たした上で、コンピュータウィルスや外部からの不正アクセスまたはその可能性を検知する必要がある。

開示する情報収集システムは、制御周期の下で、制御対象の状態情報に基づいて制御対象へ制御指令を出力する制御部、および、状態情報と制御指令との制御データおよびインシデントリストに定められた優先度に従ったインシデントログを、制御周期の制約の下での所定長のデータ部に格納した制御パケットを生成する制御パケット生成部を含む制御装置、並びに、制御装置からの制御パケットに格納されたインシデントログを格納するインシデントログ格納部、インシデントログ格納部に格納されたインシデントログからインシデントの発生の可能性のあるログデータを検出し、検出したログデータに対応して警告メッセージを出力するインシデント検知部、および、インシデント検知部によるログデータの検出に対応して、インシデントログの優先度を定めたインシデントリストを更新するインシデントリスト作成部を含む管理サーバを有する。

開示する情報収集システムによれば、制御システムとしての処理時間の制約を満たした上で、コンピュータウィルスや外部からの不正アクセスまたはその可能性を検知できる。

情報収集システムの構成図である。 インシデント−ログ対応表の例である。 インシデントリストの例である。 制御パケットの例である。 制御パケット生成部の処理フローチャートである。 ログパケットの例である。 ログパケット生成部の処理フローチャートである。 インシデント検知部の処理フローチャートである。 ログデータリストの例である。 更新されたインシデントリストの例である。 インシデント検知部の一部の代替処理フローチャートである。

図１は、情報収集システムの構成図である。情報収集システムは、制御システムへのコンピュータウィルスやＤｏＳ攻撃といったサイバー攻撃のインシデントログ（以下、単にログと呼ぶことがある。）を収集する。

情報収集システムは、センタサーバ１０、管理サーバ２０、制御装置３０（以下、一般に複数の制御装置があるが、１つを代表させて説明する。）、及び、これらを接続するネットワーク８０、９０を含む。センタサーバ１０、管理サーバ２０、および制御装置３０は、制御対象によって、規模の大小や接続する入出力装置に差異などがあるが、ＣＰＵ、記憶装置を有するコンピュータである。

センタサーバ１０は、インシデント検知部１１、インシデントリスト作成部１２、およびインシデントログ収集部１３の各処理部、インシデント−ログ対応表１４、インシデントログ格納部１５、およびインシデントリスト１６のテーブルまたは記憶部、並びに管理サーバ２０とネットワーク８０を介して通信する通信部１７を有する。

インシデント検知部１１は、インシデントログ格納部１５に格納されたインシデントログから、マルウェア等の感染や外部からの不正アクセスなどのインシデントを、後述するインシデント−ログ対応表１４の判定基準１４４を参照して、検知する。インシデント検知部１１は、検知したインシデントに基づいて、インシデントリスト作成部１２に指示すると共に、センタサーバ１０の出力装置（図示略）に警報メッセージなどを出力する。

インシデントリスト作成部１２は、インシデント検知部１１からの指示、および、予め作成され、必要に応じて更新されるインシデント−ログ対応表１４に基づいて、収集すべきインシデントに対応するログ（インシデントログ）の優先度を表すインシデントリスト１６を作成する。インシデントリスト１６は、通信部１７によって、管理サーバ２０、および管理サーバ２０を介して制御装置３０に送信される。

インシデントログ収集部１３は、管理サーバ２０から送信されたインシデントログ、および管理サーバ２０を介して通信部１７が受信する、制御装置３０から送信されたインシデントログをインシデントログ格納部１５に格納する。

管理サーバ２０は、制御管理部２１、ログ収集部２４、およびログパケット生成部２６の各処理部、制御管理ファイル２２、ログ格納部２５、およびインシデントリスト２８のテーブルまたは記憶部、並びに、センタサーバ１０とネットワーク８０を介して通信する通信部２７、および制御装置３０とネットワーク９０を介して通信する通信部２３を有する。

制御管理部２１は、制御管理ファイル２２に格納されている、制御装置３０からの、制御対象の状態を表す状態情報に基づいて、たとえば、制御装置３０によるアクチュエータの制御指令の変更や、複数の制御装置３０の間の同期（制御タイミング）などを制御する。制御管理部２１による制御装置３０を制御するための指令は、通信部２３によって制御装置３０に送信される。

ログ収集部２４は、制御管理ファイル２２に格納されている、制御装置３０から受信した制御パケットのデータ部（ペイロード）に含まれる制御装置３０のインシデントログ、および管理サーバ２０の状態情報から収集したインシデント検知のためのインシデントログをログ格納部２５に格納する。管理サーバ２０の状態情報から収集するインシデントログは、制御管理部２１が、インシデントリスト２８を参照して収集する。収集するインシデントログは、制御管理ファイル２２に格納されるが、その多くは制御管理部２１のＯＳが管理する記憶領域にある管理サーバ２０の状態情報である。この記憶領域は、ＯＳやＯＳの制御下で動作するシステムタスク以外からはアクセス禁止として制御されるが、一般にＯＳに、管理サーバ２０の状態情報を出力するシステムタスクが存在するので、このシステムタスクを用いることにより、所望のインシデントログが制御管理ファイル２２に格納される。

ログパケット生成部２６は、ログ格納部２５に格納されているインシデントログを送信するためのログパケットを生成する。生成されたログパケットは、通信部２７によってセンタサーバ１０に送信される。ログ収集部２４とログパケット生成部２６とを一体構成として、収集したインシデントログを基にログパケットを生成し、ログ格納部２５を設けなくてもよい。

制御装置３０は、制御部３１、制御パケット生成部３４、およびログ選択部３５の各処理部、制御情報ファイル３２およびインシデントリスト３６のテーブルまたは記憶部、並びに管理サーバ２０および他の制御装置３０と通信する通信部３３を有する。ログ選択部３５は、図１では明示的に図示してあるが、制御パケット生成部３４の一部（一部の処理、またはサブルーチン）として動作する。

制御部３１は、センサから得られる制御対象の状態情報を制御情報ファイル３２に格納すると共に、制御情報ファイル３２に格納されている、制御管理部２１からの指令（制御目標値の変更など）、および制御対象の状態情報に基づいた制御指令をアクチュエータに出力する。制御部３１は、アクチュエータに出力した制御指令も制御情報ファイル３２に格納する。また、制御部３１は、管理サーバ２０および他の制御装置３０へ送信すべき制御対象の状態情報および制御指令を制御データとして制御パケット生成部３４へ出力する。

制御パケット生成部３４は、管理サーバ２０および他の制御装置３０へ送信すべき制御データである、制御対象の状態情報および制御指令を所定のフォーマットに設定した制御パケットを生成する。

制御装置３０が送信する制御パケットは、ネットワーク９０における輻輳を避けるために、制御周期（制御対象により異なり、100m秒、1秒、1分など）毎に１回、宛先を特定しないブロードキャストまたは必要な複数の宛先を指定するマルチキャストにより送信される。制御パケットに宛先を付したPoint to Point通信が用いられる場合もあるが、同じまたは類似の状態情報および制御指令を含む複数の制御パケットを制御装置３０が送信することになり、ネットワーク９０において輻輳が発生する可能性が高くなるので、ネットワーク９０の通信容量に余裕がある場合に用いられる。

制御パケット生成部３４は、制御パケットのデータ部の容量のうち、状態情報および制御指令の制御データ量を除くデータ量をインシデントログの送信に用いる。制御パケット生成部３４は、インシデントログの送信に用いるデータ量をログ選択部３５に出力する。

ログ選択部３５は、インシデントログの送信に用いるデータ量および、インシデントリスト３６の内容に応じて、送信すべきインシデントログの指定を制御パケット生成部３４に出力する。制御パケット生成部３４は、送信すべきインシデントログの指定に応じて、制御情報ファイル３２から指定されたインシデントログを読み出し、制御パケットに格納する。生成された制御パケットは、通信部３３によって、ネットワーク９０を介して送信される。

通常、制御システムは、制御管理部２１、制御管理ファイル２２、および通信部２３を有する管理サーバ２０、並びに、制御部３１、制御パケット生成部３４、制御情報ファイル３２および通信部３３を有する制御装置３０により構成される。情報収集システムは、通常の制御システムに、センタサーバ１０およびネットワーク８０を付加し、さらに管理サーバ２０および制御装置３０に、前述した処理部や記憶部を付加したものである。また、情報収集システムでは、管理サーバ２０の制御管理ファイル２２にはインシデントログが格納され、制御装置３０の制御パケット生成部３４には制御パケットにインシデントログを格納する処理が付加される。また、センタサーバ１０は、説明の分かり易さおよび管理サーバ２０の処理能力や記憶容量等に余裕がない場合を想定して設けているが、管理サーバ２０の処理能力などに十分な余裕がある場合は、センタサーバ１０の各処理部および各記憶部を管理サーバ２０に設けてもよい。

収集するインシデントログは、制御情報ファイル３２に格納されるが、その多くは制御装置３０のＯＳが管理する記憶領域にある制御装置３０の状態情報である。この記憶領域は、ＯＳやＯＳの制御下で動作するシステムタスク以外からはアクセス禁止として制御されるが、一般にＯＳに、制御装置３０の状態情報を出力するシステムタスクが存在するので、このシステムタスクを用いることにより、所望のインシデントログが制御情報ファイル３２に格納される。

インシデントログの送信に用いるデータ量について説明を補足する。ネットワーク９０を介して、制御装置３０が送信する制御パケットのデータ部（ヘッダなどを除いたペイロード）の長さを、たとえば1ｋＢ（1000バイト）とする。この値は、制御周期の間に、制御部３１および制御パケット生成部３４の処理を完了し、さらに生成された制御パケットを、ネットワーク９０を介して送信完了する必要があるという制約条件を持つ制御装置３０において、ネットワーク９０の使用に許容される通信帯域や通信部２３および通信部３３の性能、通信プロトコルなどにより決定される値であるので、1ｋＢは説明の都合上の値である。通常の制御システムの運用において、制御データである、状態情報および制御指令の通信のために800バイトを使用するならば、インシデントログの送信に用いるデータ量の上限は200バイトである。制御システムの場合は、通信に係る処理の複雑さを避けるために、予め定めた固定長の制御パケットが用いられる。

なお、可変長の制御パケットが用いられる場合は、ネットワーク９０や通信部などの性能、通信プロトコルなどにより決定される、制御装置３０に許容されるデータ部の長さ（容量）から、この制御装置３０が用いる制御データの長さを減算した長さをインシデントログの送信に用いる。

一方、インシデントは、制御システム全体の状態に影響を及ぼすものから、ほとんど影響しないものまであり、それらのインシデントに対応する（インシデントを特定できる）インシデントログの情報量は多く、多くの場合、インシデントログの送信に用いるデータ量の上限を超える。そこで、インシデントログを選択的に制御パケットに格納する必要がある。

ここで、制御システムにおける、マルウェア等の感染や外部からの不正アクセスなどのインシデントについて、図示するまでもない簡単な例を挙げて説明する。最も典型的な例は、管理サーバ２０のインターネットなどの公衆網への接続である。管理サーバ２０を操作するユーザは、制御や状態情報の統計処理やグラフ化などのためにインターネット上の情報（プログラムやデータ）を必要とすることがある。また管理サーバ２０のユーザは、制御システムの管理者との間の問い合わせや応答に電子メールを使用することもある。管理サーバ２０に入ったインシデントが、ネットワーク９０を介して制御装置３０に伝わる、または影響を及ぼす。制御装置３０をインターネットなどの公衆網に接続する例として、センサとしてＷｅｂカメラを用いる場合や、遠隔のセンサの値を、インターネットを介して制御装置３０が受信する例がある。このような例は、専用線を用いる場合に比べて安価であるからである。このような通信環境においては、マルウェア等の感染や外部からの不正アクセスなどのインシデントが、認証情報の付加やコンピュータウィルスの検知などのセキュリティ対策を超えて発生する可能性がある。

図２は、インシデント−ログ対応表１４の例である。インシデント−ログ対応表１４の内容は、センタサーバ１０に接続する入力装置から、センタサーバ１０のユーザによって入力され、必要に応じて更新される。インシデント−ログ対応表１４は、優先度１４０、インシデント名１４１、インシデントコード１４２、ログデータ種別１４３、ログコード１４４、ログデータ長１４５、および判定基準１４６を有する。

優先度１４０は、インシデントの重要性であり、対応するインシデントログを制御装置３０が送信するときの優先度として用いられる。ここでは、「１」を最優先とし、数字が大きくなるにつれて、優先度が低下するものとする。インシデント名１４１はインシデントの名称であり、インシデントコード１４２はインシデントを識別するコードである。ログデータ種別１４３は、インシデントの発生を判定するためのログデータの種別であり、ログコード１４４はログデータの種別を識別するコードである。たとえば、インシデント名１４０が「サービス不能」のインシデントにはインシデントコード１４２「Ａ」を付し、「サービス不能」のインシデントの発生を判定するためのログデータ種別１４３の「ネットワーク帯域」にログコード１４４「Ａ01」を付してある。

なお、あるログコード１４４に対応するログデータを収集したとしても、そのログコード１４４に対応するインシデントが必ずしも発生しているとは限らない。逆に、あるインシデントが発生したならば、対応するログコード１４４のログデータが収集される。すなわち、ログデータの収集は、インシデントの発生の可能性を示すことになる。

ログデータ長１４５は、ログコード１４４のインシデントログの長さである。この長さには、後述するインシデントログを収集した時刻データを含む。ファイル名のように、長さが不定なインシデントログがある。このような場合は、予め想定される最長のファイル名の長さを設定し、設定した長さを超えるファイル名の場合は、ファイル名の先頭から設定した長さの文字列をインシデントログとして収集する。

判定基準１４６は、収集したインシデントログからインシデント検知部がインシデントの発生（の可能性）を判定するために用いられる。図２では、ログデータ種別１４３が「ネットワーク帯域」や「ＣＰＵ利用率」の判定基準を「○Ｍｂｐｓ以下」、「○○％以上」と例示しているが、これらの継続時間を判定基準に含めてもよい。また、ログデータ種別１４３が「不適切なファイル名」の判定基準を「有り」としているが、インシデントログとしては検出した不適切なファイル名が収集される。

センタサーバ１０は、インシデント−ログ対応表１４の入力、または更新に応じて、優先度１４０、インシデントコード１４２、ログコード１４４およびログデータ長１４５の対応関係を管理サーバ２０および制御装置３０に送信しておく。管理サーバ２０および制御装置３０の各々は、制御周期毎に、ログコード１４４の各々に対応するインシデントログを前述のシステムタスクを利用して収集し、収集した時刻（時刻データ）を付して、制御管理ファイル２２または制御情報ファイル３２に格納する。したがって、管理サーバ２０と制御装置３０との特性が異なる場合、制御装置３０によって特性が異なる場合、インシデント−ログ対応表１４は管理サーバ用と制御装置用との２種類以上を設けてもよいが、ここでは簡単のために１種類として説明する。

図３は、インシデントリスト１６の例である。インシデントリスト１６は、インシデントリスト作成部１２によって作成され、優先度１６０、インシデントコード１６１、ログコード１６２、およびログデータ長１６３を有する。優先度１６０は、インシデント−ログ対応表１４の中から、インシデントリスト作成部１２が選択したインシデントの優先度１４０に対応し、インシデントコード１６１は選択したインシデントのインシデントコード１４１に対応し、ログコード１６２は、選択したインシデントを検知するためにインシデントリスト作成部１２が選択したログデータ種別１４３のログコード１４４に対応し、ログデータ長１６３は、ログコード１４４に対応するインシデントログのログデータ長１４５に対応する。インシデントリスト１６も、インシデント−ログ対応表１４の種類に対応して、管理サーバ用と制御装置用との２種類以上を設けてもよいが、ここでは簡単のために１種類とする。

インシデントリスト１６が通信部１７によって、管理サーバ２０および制御装置３０に送信され、各々インシデントリスト２８およびインシデントリスト３６として格納されたものとして、制御装置３０の動作を説明し、続いて管理サーバ２０の動作を説明する。

制御情報ファイル３２には、前述のように、制御部３１によって、センサから得られる制御対象の状態情報およびアクチュエータに出力した制御指令、並びに、制御装置３０のＯＳが管理する記憶領域にある制御装置３０の状態情報が格納されている。制御装置３０の状態情報に関しては、インシデントリスト３６のログコード１６２に対応する情報に限定してシステムタスクを用いることにより、インシデントを検知するために不使用のデータがインシデントログとして制御情報ファイル３２に格納されることが避けられる。

図４は、制御パケット生成部３４が生成する制御パケット４０の例である。制御パケット４０は、ヘッダ長、パケット長、送信元アドレスなどを含むヘッダ部４１、並びに、制御データ部４２およびログデータ部４３を格納するデータ部（ペイロード）を有する。制御データ部４２は、前述したように、制御部３１が入力した状態情報、出力した制御情報、並びに管理サーバ２０および他の制御装置３０へ送信すべき制御に係る制御データを格納する。制御パケット生成部３４による、ヘッダ部４１及び制御データ部４２の設定や格納は、通常の制御システムと同様であるので、説明を簡略にする。ログデータ部４３は、以降がログデータ４３であることを表す区切り（コード）４４、並びにログコード４５とログコード４５に対応するインシデントログ４６の組の列を格納する。

図５は、制御パケット生成部３４の処理フローチャートである。制御パケット生成部３４は、制御装置３０の所定の制御周期（センサから状態情報を入力し、アクチュエータに制御指令を出力する周期）のタイマにより周期起動されてもよいが、所定の制御周期で制御部３１が動作するので、制御部３１が動作終了直前で、制御パケット生成部３４を起動する。

このように起動する理由は次のとおりである。同じ周期の周期タイマにより制御部３１と制御パケット生成部３４を起動すると、制御部３１と制御パケット生成部３４との優先制御（一般に、制御部３１を優先する。）を実行する必要があり、周期は同じで起動タイミングをずらす方法をとると、制御部３１と制御パケット生成部３４との一方が動作中に他方が起動されると優先制御を必要とされ、または、制御部３１の動作終了と制御パケット生成部３４の動作開始との間に無駄時間が生じ、制御部３１の動作開始から制御パケット生成部３４の動作終了までの時間が、所定の制御周期を超える可能性があることによる。

制御パケット生成部３４は、制御パケット４０のヘッダ部４１を設定し、制御情報ファイル３２から送信すべき制御データを読み出し、データ部に制御データを格納する（Ｓ３４０）。制御パケット生成部３４は、制御パケット４０のデータ部の容量のうち、制御データ量（制御データ部４２の長さ）を除くデータ量（ログデータ部４３の長さ）をインシデントログの送信に用いる。制御パケット生成部３４は、制御パケット４０のデータ部の長さから制御データ部４２の長さを減じたログデータ部４３の長さから、さらに区切り４４の長さを減じたデータ量を、インシデントログの送信に用いる実際のデータ量としてログ選択部３５に出力する（Ｓ３４１）。制御パケット生成部３４は、この段階で制御パケット４０の区切り４４に所定の区切り符号を格納する。

制御パケット生成部３４の一部として動作するログ選択部３５は、制御装置３０のワークエリアに、ログコードとログデータ長の組を格納するログコードリストを作成する。ログ選択部３５は、ログコードリストに格納されたログコードの長さ（図２、図３のログコードの例から分かるように、ログコードの長さは、ログコードに依存せずに固定長に設計可能である。）とログデータ長の合計が、インシデントログの送信に用いる実際のデータ量を超えるかを判定する（Ｓ３４２）。インシデントログの送信に用いる実際のデータ量を超えるならば、制御パケット生成部３４のＳ３４５の処理へ移る。

ログコードリストを作成（ワークエリアに領域を確保）した直後は、ログコードリストにログコードおよびログデータ長は格納されていないので、インシデントログの送信に用いる実際のデータ量を超えない。もし超えるならば、ヘッダ部４１と制御データ部４２との長さが、制御パケット４０に許容される長さを超えているので、不適合な制御パケットである。

インシデントログの送信に用いる実際のデータ量を超えないならば、ログ選択部３５は、インシデントリスト３６の最後まで参照したかを判定する（Ｓ３４３）。最後まで参照したならば、制御パケット生成部３４のＳ３４６の処理へ移る。

最後まで参照してないならば、ログ選択部３５は、インシデントリスト３６のログコードおよびログデータ長をログコードリストに格納する（Ｓ３４４）。Ｓ３４２〜Ｓ３４４の処理ループの各回の処理において、インシデントリスト３６の優先度の高い方からログコードおよびログデータ長を順次選択し、ログコードリストに格納することになる。インシデントリスト３６と同じ、図３のインシデントリスト１６を用いて具体例を説明する。初回のループ処理では、優先度１６０が「１」のログコード１６２「Ａ01」とそのログデータ長１６３「8Byte」が選択され、ログコードリストに格納される。２回目のループ処理では、優先度１６０が「１」のログコード１６２「Ａ03」とそのログデータ長１６３「24Byte」が選択され、ログコードリストに格納される。同じ優先度の場合、インシデントリスト３６の上位から順に選択する。

制御パケット生成部３４は、最後に格納したログコードおよびログデータ長をログコードリストから削除する（Ｓ３４５）。ログコードリストに最後に格納したログコードおよびログデータ長を格納したことにより、インシデントログの送信に用いる実際のデータ量を超えたので、最後に格納したログコードおよびログデータ長をログコードリストから削除する。

制御パケット生成部３４は、ログコードリストに従って、ログコードリストのログコード、およびログコードに対応するインシデントログを制御情報ファイル３２から読み出し、ログパケット４０の、ログコード４５及びインシデントログ４６の組として制御パケットに順次格納する（Ｓ３４６）。ログコードリストに従っているので、インシデントログの送信に用いる実際のデータ量を超えない範囲で、ログコード４５及びインシデントログ４６の組が列として制御パケットに格納される。

制御パケット生成部３４は、通信部３３およびネットワーク９０を介して、生成した制御パケット４０を管理サーバ２０および他の制御装置３０に送信する（Ｓ３４７）。

この制御パケット生成部３４の動作により、制御周期の制約の中で、制御部３０のインシデントログを効率的に収集できる。

管理サーバ２０の動作を説明する。制御管理部２１は、通常の制御システムにおける動作と同様であり、管理サーバ２０の周期タイマにより起動され、制御管理ファイル２２に格納されている、制御装置３０からの、制御データに基づいて、たとえば、制御装置３０によるアクチュエータの制御指令の変更や複数の制御装置３０の間の同期（制御タイミング）などを制御する。制御管理部２１による制御装置３０を制御するための指令は、通信部２３によって制御装置３０に送信される。前述の管理するための、指令を含めた管理データは、制御管理ファイル２２に格納される。制御管理部２１は、前述の管理及び指令の送信の一連の処理を終了した段階で、ログパケット生成部２６を起動する。

制御管理ファイル２２には、各制御装置３０の制御データ（インシデントログデータを含む）、管理サーバ２０の管理データ、および、管理サーバ２０のＯＳが管理する記憶領域にある管理サーバ２０の状態情報が格納されている。各制御装置３０の制御データは、制御装置３０のアドレスなどを用いた識別子で識別されればよく、順不同で良い。管理サーバ２０の状態情報に関しては、インシデントリスト２８のログコード１６２に対応する情報に限定してシステムタスクを用いることにより、インシデントを検知するために不使用のデータがインシデントログとして制御管理ファイル２２に格納されることが避けられる。

図６は、ログパケット生成部２６が生成するログパケット５０の例である。ログパケット５０は、ヘッダ長、パケット長、送信元アドレス、送信先アドレスなどを含むヘッダ部５１、並びに、管理サーバ２０のログデータ部（以下、管理ログ部）５２および制御装置３０のログデータ部（以下、制御ログ部）５３を格納するデータ部を有する。制御ログ部５３は、制御装置３０毎のログデータであり、Ｎ台の制御装置３０がネットワーク９０を介して管理サーバ２０に接続しているものとして図示している。

管理ログ部５２および制御ログ部５３は同じ形式である。図６には、ある制御装置３０の制御ログ部５３を代表させて図示している。制御ログ部５３は、制御装置３０を識別する識別子５４（管理ログ部５２の場合は、管理サーバ２０の識別子）、並びにログコード５５とログコード５５に対応するログ５６の組の列を格納する。制御ログ部５３は、図４に示した制御パケット４０の制御データ部４２及びログデータ部４３が制御管理ファイル２２に格納されているので、そのログデータ部４３の区切り４４を制御装置３０の識別子に置換したものである。制御装置３０の識別子は、制御パケット４０のヘッダ部４１に含まれる送信元アドレスに基づく。制御装置３０の送信元アドレスを識別子として用いてもよいし、送信元アドレスと識別子との対応表を管理サーバ２０およびセンタサーバ１０が持ち、送信元アドレスから識別子へ変換してもよい。

なお、ネットワーク８０は、センタサーバ１０と管理サーバ２０との１対１通信に供されるので、ネットワーク９０上の制御パケット４０に比べて、ログパケット５０のパケット長を長くすることができる。さらに、前述したように、センタサーバ１０と管理サーバ２０とを同じサーバで一体として構成できる場合は、管理サーバ２０のログ格納部２５とセンタサーバ１０のインシデントログ格納部１５を同一（ログ格納部２５およびインシデントログ格納部１５の一方を省略するとともに、ログパケット生成部２６、通信部２７、ネットワーク８０、通信部１７、およびインシデントログ収集部１３を省略した構成）にできるので、ログパケット５０のパケット長を考慮に入れる必要がない。

ログ収集部２４による、管理サーバ２０の状態情報からのインシデントログの収集は、前述したとおりである。また、ログ収集部２４による、制御管理ファイル２２に格納されている制御装置３０のインシデントログの収集は、図６を用いたログパケット５０の説明と重複するので省略する。ログ収集部２４は、制御管理ファイル２２に格納されている、管理サーバ２０および制御装置３０のインシデントログを、ログ格納部２５に格納する。ログ格納部２５に格納されるインシデントログは、管理サーバ２０および制御装置３０の識別子で識別できればよいので、特定の順序に従う必要はない。

図７は、ログパケット生成部２６の処理フローチャートである。ログパケット生成部２６は、ログパケット５０のヘッダ部５１を設定する（Ｓ２６０）。ログパケット生成部２６は、管理サーバ２０のインシデントログをログ格納部２５から読み出し、ログパケット５０の管理ログ部５２に格納する（Ｓ２６１）。

ログパケット生成部２６は、ログ格納部２５に格納されている、制御装置３０からのインシデントログをログパケット５０に格納したかを判定する（Ｓ２６２）。格納が完了しているならば、ログパケット生成部２６はＳ２６４へ移る。

格納が完了していないならば、ログパケット生成部２６は、次の制御装置３０からのインシデントログを、制御装置３０の識別子を付して、ログパケット５０の制御ログ部に格納し（Ｓ２６３）、Ｓ２６２へ移る。

ログパケット生成部２６は、通信部２７およびネットワーク８０を介して、生成したログパケット５０をセンタサーバ１０に送信する（Ｓ２６４）。

センタサーバ１０のインシデントログ収集部１３は、通信部１７を介して受信するログパケット５０のデータ部（インシデントログである管理ログ部５２および制御ログ部５３）をインシデントログ格納部１５に格納する。インシデントログ収集部１３は、ログパケット５０を受信した通信部１７からの受信割込みにより起動され、インシデントログ格納部１５への格納完了に伴い、インシデント検知部１１を起動し、処理を終了する。

図８は、インシデント検知部１１の処理フローチャートである。インシデント検知部１１は、センタサーバ１０のワークエリアにログデータリストの領域を確保する（Ｓ１１０）。ログデータリストについては後述する。

インシデント検知部１１は、インシデントログ格納部１５に格納されている全てのインシデントログデータ（管理ログ部５２および制御ログ部５３の内容に相当）がチェック済みかを判定する（Ｓ１１１）。具体的には、管理サーバ２０のインシデントログおよびＮ台の制御装置３０のインシデントログがチェック済みかを判定する。チェック済みならば、インシデント検知部１１はＳ１１５へ移る。

なお、インシデントログ格納部１５に格納されているインシデントログは、一つのログパケット５０のデータ部である。図示を省略するが、インシデント検知部１１は、後述のＳ１２１の処理の後、インシデントログ格納部１５に格納されているインシデントログを削除して、処理を終了する。

チェック済みでないならば、インシデント検知部１１は、インシデントログ格納部１５からチェック済みでないインシデントログデータを識別子５４単位で読み出し（Ｓ１１２）、読み出したインシデントログデータに警告すべきインシデントログが少なくとも一つあるかを判定する（Ｓ１１３）。警告すべきインシデントログがないならば、インシデント検知部１１はＳ１１１へ戻る。

インシデントログデータは、図６のログパケット５０の形式でインシデントログ格納部１５に格納されているので、インシデント検知部１１はログコード５５とログ５６の組に関して、ログコード５５と同じ、インシデント−ログ対応表１４のログコード１４４の判定基準１４６を用いて、ログ５６を順次判定する。たとえば、ログコード５５が「Ａ01」のログ５６の内容が、判定基準１４６「○Mbps以下」であるかを判定する。この例の場合、「○Mbps以下」であるならば、警告すべきインシデントログ（前述のインシデント発生の可能性を表すログ）と判定する。

警告すべきインシデントログが少なくとも一つあるならば、インシデント検知部１１は、識別子、インシデントコード、ログコード、ログデータを対応付けて、ログデータリストに格納する（Ｓ１１４）。格納後、インシデント検知部１１はＳ１１１へ戻る。

インシデント検知部１１がログデータリストに格納する識別子、ログコード、およびログデータは、識別子５４、ログコード５５、およびログデータ５６であり、インシデントコードはインシデント−ログ対応表１４を参照した、ログコード５５と同じログコード１４４に対応するインシデントコード１４２である。

図９は、ログデータリスト９００の例である。ログデータリスト９００は、上述のインシデントログの格納に対応して、識別子９０１、インシデントコード９０２、ログコード６０３、およびログデータ９０４を含む。インシデント検知部１１は、警告すべきインシデントログがあるとの判定に対応して、順次ログデータリスト９００に識別子９０１などを格納する。同じ識別子５４に対応して、警告すべきインシデントログが複数あるならば、インシデント検知部１１は、ログデータリスト９００の複数行に識別子９０１などを格納する。

図９に示すログデータリスト９００の例は、識別子９０１が「２」の制御装置３０に、インシデントコード９０２が「Ｂ」、ログコード６０３が「Ｂ01」、およびログデータ９０４が「85％」の警告すべきインシデントログがあり、並びに、識別子９０１が「３」の制御装置３０に、インシデントコード９０２が「Ｂ」であり、ログコード６０３「Ｂ01」に対応してログデータ９０４が「95％」、およびログコード６０３「Ｂ03」に対応してログデータ９０４が「90％」の警告すべきインシデントログがあると、インシデント検知部１１が判定したことを表している。

インシデント検知部１１は、インシデントログ格納部１５に格納されている全てのインシデントログデータをチェック済みであるならば、ログデータリスト９００が空かを判定し（Ｓ１１５）、空ならば処理を終了する。ログデータリスト９００の空は、警告すべきインシデントログがないと判定されたことを意味する。

ログデータリスト９００が空でなければ、インシデント検知部１１は、ログデータリスト９００に複数種（異なる複数）の識別子９０１があるかを判定し（Ｓ１１６）、１種類の識別子ならば、インシデント検知部１１はＳ１１８へ移る。複数種の識別子９０１があることは、管理サーバ２０とＮ台の制御装置３０との中で、複数台において警告すべきインシデントログがあると判定されたことを表している。図９に示すログデータリスト９００の例は、識別子９０１が「２」と「３」との複数台において警告すべきインシデントログがあると判定されたことを表している。

インシデント検知部１１は、複数種の識別子９０１に共通して同じインシデントコード９０２があるかを判定し（Ｓ１１７）、ないならば、インシデント検知部１１はＳ１２０へ移る。複数種の識別子９０１に共通して同じインシデントコード９０２があるならば、同じ原因によるインシデントの発生の可能性がある。

インシデント検知部１１は、同じインシデントコード９０２に複数のログコード９０３があるかを判定し（Ｓ１１８）、ないならば、インシデント検知部１１はＳ１２０へ移る。この判定は、ログデータリスト９００に１種の識別子９０１があり、１種の識別子９０１に対応した同じインシデントコード９０２が複数ある場合と、複数の識別子９０１があり、複数または１種の識別子９０１に対応した同じインシデントコード９０２に複数のログコード９０３がある場合に実行される。複数か１種の識別子９０１かに係らず、同じ原因によるインシデントの発生の可能性があるかを、インシデント検知部１１が判定していることを意味する。

同じインシデントコード９０２に複数のログコード９０３があるならば、インシデント検知部１１は、重要なインシデントの発生の可能性があるとして、重要警告メッセージをセンタサーバ１０の出力装置（図示略）に出力する（Ｓ１１９）。出力装置が表示装置の場合は、重要警告メッセージと共にログデータリスト９００を表示することにより、重要警告メッセージの詳細がセンタサーバ１０のユーザによって認識される。

ログデータリスト９００に複数の識別子９０１があるが、同じインシデントコード９０２がない場合、および同じインシデントコード９０２に複数のログコード９０３がない場合、インシデント検知部１１は、警告メッセージをログデータリスト９００と共にセンタサーバ１０の出力装置に出力する（Ｓ１２０）。

インシデント検知部１１は、重要警告メッセージまたは警告メッセージを出力後、ログデータリスト９００に含まれるインシデント９０２、ログコード９０３およびログデータ９０４に応じたインシデントリスト１６の更新を、インシデントリスト作成部１２に指示する。

図１０は、インシデント検知部１１からの更新指示に基づいて、インシデントリスト作成部１２によって、図３に示すインシデントリスト１６が更新された例である。図１０に示すインシデントリスト１６は、図３と比較すると、ログコード１６２およびログデータ長１６３の組として、「Ａ04」および「24Byte」、並びに、「Ｂ03」および「24Byte」が追加されている。この追加は、ログデータリスト９００のログコード９０３が「Ｂ01」（ＣＰＵ利用率が高い）の原因が、「Ｂ02」（ネットワーク使用率が高い）に関係し、さらにログコード１６２「Ａ04」（送信元が異常なパケット）および「Ｂ03」（ファイルの拡張子異常）に関係しているのではないかとの設計ポリシーに基づいている。ログコード１６２およびログデータ長１６３の組の追加により、インシデントリスト１６の容量が、管理サーバ２０や制御装置３０の記憶装置の容量制限や、ネットワーク９０上での容量制限を超える場合は、優先度の低いログコード１６２およびログデータ長１６３の組を削除する。

図１１は、図８のインシデント検知部１１の一部の処理（Ｓ１１６〜Ｓ１２０）の代替処理フローチャートである。図１１は、ログデータリスト９００の、優先度を表すインシデントコード９０２に注目した処理である。

インシデント検知部１１は、インシデントコード９０２に「Ａ」（優先度１４０が「１」）がある場合（Ｓ１５０）、および「Ｂ」（優先度１４０が「２」）が複数ある場合（Ｓ１５１）に第１警告メッセージ（第１が最も重要であり、第２、第３、の順に、重要性低下）を出力する（Ｓ１５２）。同様に、インシデント検知部１１は、インシデントコード９０２に「Ｂ」が一つある場合（Ｓ１５３）、および「Ｃ」（優先度１４０が「３」）が複数ある場合（Ｓ１５４）に第２警告メッセージを出力する（Ｓ１５５）。さらに同様に、インシデント検知部１１は、インシデントコード９０２に「Ｃ」が一つある場合（Ｓ１５６）、および「Ｄ」以下（優先度１４０が「４以下」）が複数ある場合（Ｓ１５７）に第３警告メッセージを出力し（Ｓ１５８）、「Ｄ」以下が一つ又はない場合に第４警告メッセージを出力する（Ｓ１５９）。

インシデント検知部１１の警告メッセージを出力する処理として、図８および図１１の２種類を説明したが、最も簡単には、ログデータリスト９００に少なくとも一つのインシデントログがあれば、ログデータリスト９００と共に警告メッセージを出力してもよい。

このように、インシデントの重要性（インシデント−ログ対応表１４の優先度１４０）、およびインシデントの発生の可能性を表すログデータ（インシデント−ログ対応表１４のログデータ種別１４３およびログコード１４４）に関しての選択や順序付けは、制御システムおよび制御対象の状態変化を把握または想定した設計ポリシーに基づけばよい。

同様に、インシデントの発生の可能性を表すログデータを収集したときに、インシデントリスト１６の更新内容に関しても、制御システムおよび制御対象の状態変化を把握または想定した設計ポリシーに基づけばよい。

本実施形態の情報収集システムによれば、制御システムとしての処理時間の制約を満たした上で、コンピュータウィルスや外部からの不正アクセスまたはその可能性を検知できる。

１０：センタサーバ、１１:インシデント検知部、１２：インシデントリスト作成部、１３：インシデントログ収集部、１５:インシデントログ格納部、１６:インシデントリスト、１７:通信部、２０：管理サーバ、２１:制御管理部、２２：制御管理ファイル、２３:通信部、２４：ログ収集部、２５: ログ格納部、２６：ログパケット生成部、２７:通信部、２８：インシデントリスト、３０：制御装置、３１:制御部、３２、制御情報ファイル、３３: 通信部、３４: 制御パケット生成部、３５:ログ選択部、３６インシデントリスト、４０:制御パケット、５０:ログパケット、８０: ネットワーク、９０：ネットワーク。

Claims (10)

1. 制御周期の下で、制御対象の状態情報に基づいて前記制御対象へ制御指令を出力する制御部、および、前記状態情報と前記制御指令との制御データおよびインシデントリストに定められた優先度の高いインシデントログから順に、インシデントログを前記制御周期の制約の下での所定長のデータ部に格納した制御パケットを生成する制御パケット生成部を含む制御装置、
   並びに、前記制御装置からの前記制御パケットに格納された前記インシデントログを格納するインシデントログ格納部、前記インシデントログ格納部に格納された前記インシデントログからインシデントの発生の可能性のある第１のログデータを検出し、検出した前記第１のログデータに対応して警告メッセージを出力するインシデント検知部、および、前記インシデント検知部からの更新指示に従って、前記警告メッセージを出力した前記第１のログデータの検出に対応して、ログコードおよびログデータ長の組を追加することにより、前記インシデントログの前記優先度を定めた前記インシデントリストを更新するインシデントリスト作成部を含む管理サーバを有することを特徴とする情報収集システム。
2. 前記インシデントリストは、前記インシデントに定めた前記優先度に対応した、前記インシデントログを表す第２のログデータおよび前記第２のログデータの長さであるログデータ長を含み、前記第１のログデータは前記第２のログデータに含まれることを特徴とする請求項１に記載の情報収集システム。
3. 前記インシデント検知部は、前記第１のログデータに対応して設定された判定基準に基づいて、前記インシデントの発生の可能性のある前記第１のログデータを検出することを特徴とする請求項２に記載の情報収集システム。
4. 前記管理サーバは、複数の前記制御装置と接続し、前記インシデントログ格納部は、複数の前記制御装置からの前記制御パケットに格納された前記インシデントログを格納することを特徴とする請求項３に記載の情報収集システム。
5. 前記管理サーバは、センタサーバと接続し、複数の前記制御装置からの前記制御パケットに格納された前記インシデントログを含むログパケットを前記センタサーバに送信し、前記インシデントログ格納部、インシデント検知部およびインシデントリスト作成部を前記センタサーバに設けたことを特徴とする請求項４に記載の情報収集システム。
6. 制御装置に接続する情報収集システムによる情報収集方法であって、
   前記制御装置は、制御周期の下で、制御対象の状態情報に基づいて前記制御対象へ制御指令を出力し、前記状態情報と前記制御指令との制御データおよびインシデントリストに定められた優先度の高いインシデントログから順に、インシデントログを前記制御周期の制約の下での所定長のデータ部に格納した制御パケットを生成し、
   前記情報収集システムは、前記制御装置からの前記制御パケットに格納された前記インシデントログを収集し、収集した前記インシデントログからインシデントの発生の可能性のある第１のログデータを検出し、検出した前記第１のログデータに対応して警告メッセージを出力し、前記警告メッセージを出力した前記第１のログデータを検出に対応して、ログコードおよびログデータ長の組を追加することにより、前記インシデントログの前記優先度を定めた前記インシデントリストを更新することを特徴とする情報収集方法。
7. 前記インシデントリストは、前記インシデントに定めた前記優先度に対応した、前記インシデントログを表す第２のログデータおよび前記第２のログデータの長さであるログデータ長を含み、前記第１のログデータは前記第２のログデータに含まれることを特徴とする請求項６に記載の情報収集方法。
8. 前記情報収集システムは、前記第１のログデータに対応して設定された判定基準に基づいて、前記インシデントの発生の可能性のある前記第１のログデータを検出することを特徴とする請求項７に記載の情報収集方法。
9. 前記情報収集システムは、複数の前記制御装置と接続し、複数の前記制御装置からの前記制御パケットに格納された前記インシデントログを収集することを特徴とする請求項８に記載の情報収集方法。
10. 前記情報収集システムは、センタサーバを含み、複数の前記制御装置からの前記制御パケットに格納された前記インシデントログを含むログパケットを前記センタサーバに送信し、
    前記センタサーバが、前記制御装置からの前記制御パケットに格納された前記インシデントログを収集し、収集した前記インシデントログからインシデントの発生の可能性のあるログデータを検出し、検出した前記ログデータに対応して警告メッセージを出力し、前記ログデータを検出に対応して、前記インシデントログの前記優先度を定めた前記インシデントリストを更新する処理を実行することを特徴とする請求項９に記載の情報収集方法。

Images