JP2019185183A - 通信装置保護管理サーバおよび通信装置保護システム - Google Patents

Abstract

【課題】未知の攻撃データを含む通信データによるサイバー攻撃に対する対策を可能とする。【解決手段】管理サーバ（通信装置保護管理サーバ）１００の攻撃判定学習部１２０は、通信装置に対する正常な通信データ群に含まれる学習用通信データ（通信データ）５０１および不正な通信データ群に含まれる通信データから、集約装置（通信装置）３００に対するコマンドを抜き出して学習データ５１１を作成する（ステップＳ１１）。攻撃判定学習部１２０は、この学習データ５１１を用いて教師ありの学習をさせることで、通信装置に対する通信データが正常か不正かを判定する攻撃判定モデル１２１を生成する。攻撃判定学習部１２０は、通信データからコマンドの他に、コマンドのパラメータから学習データを生成してもよい。【選択図】図５

Description

本発明は、安全ではないネットワークに接続された通信装置を保護する通信装置保護管理サーバおよび通信装置保護システムに関する。

情報通信技術の進展にともない、農場や工場、オフィスビル、商業施設、住宅などのフィールドに設置されているセンサやアクチュエータなどのデバイスをネットワークに接続して監視し、制御するＩｏＴ（Internet of Things）が普及しつつある。フィールドに設置された集約装置（エッジサーバ）を介して、センサで取得した情報の収集やアクチュエータの制御を管理するエッジコンピューティングという形態も注目されている。集約装置は、デバイスの動作状況をＩｏＴシステムの管理サーバに報告したり、センサが取得したデータを集計して管理サーバに送信したり、管理サーバからの指示を各アクチュエータの指示に翻訳して送信したりする。

デバイスや集約装置という通信装置は、インターネットに接続されるため、ＤｏＳ（Denial of Service）攻撃や総当たり攻撃、通信装置のプログラムの脆弱性を狙う攻撃などのサイバー攻撃に遭う可能性がある。総当たり攻撃とは、パスワードを変えながらログインを試みるような攻撃であり、パラメータを次々と変えながらサービスにアクセスしようとする攻撃である。
インターネットに接続されたサーバやパソコンにおけるサイバー攻撃への対策としては、ファイアウォールやウィルス対策ソフトウェアが普及している（非特許文献１参照）。

独立行政法人情報処理推進機構, "標的型サイバー攻撃対策," 2014年2月10日, [online], [2018年3月20日検索], インターネット<URL: https://www.ipa.go.jp/security/event/2013/isec-semi/documents/2013videosemi_targeted_cyber_attacks_v1a.pdf>

攻撃者が通信装置に送信する攻撃データは、事前に判明しているものではなく、通知装置の製造者やＩｏＴシステムの運用者にとって未知のものである。このため、送信元のアドレスや通信データに含まれるパラメータを指定してフィルタリングする手法では、攻撃を防ぐことは困難である。

このような背景を鑑みて本発明がなされたのであって、本発明は、未知の攻撃データを含む通信データによるサイバー攻撃に対する対策を可能とする通信装置保護管理サーバおよび通信装置保護システムを提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、通信装置に対する正常な通信データ群に含まれる通信データおよび不正な通信データ群に含まれる通信データから、前記通信装置に対するコマンドおよび前記コマンドのパラメータの何れか１つまたは双方を抜き出して作成した学習データを用いて教師ありの学習をさせることで、前記通信装置に対する通信データが正常か不正かを判定する攻撃判定モデルを生成する攻撃判定学習部を備えることを特徴とする通信装置保護管理サーバとした。

本発明によれば、未知の攻撃データを含む通信データによるサイバー攻撃に対する対策を可能とする通信装置保護管理サーバおよび通信装置保護システムを提供することができる。

第１の実施形態に係る通信装置保護システムの保護対象となる集約装置とデバイスを含むＩｏＴシステムの全体構成を例示する図である。 第１の実施形態に係る管理サーバの全体構成を例示する図である。 第１の実施形態に係る集約装置の全体構成を例示する図である。 第１の実施形態に係るデバイスの全体構成を例示する図である。 第１の実施形態に係る、管理サーバの制御部に含まれる攻撃判定学習部の動作、および、集約装置の通信データ監視部の動作を説明するための図である。 第１の実施形態に係る、通信データのパラメータに含まれるバイナリ列に基づいた攻撃判定モデルにおける学習データを例示する図である。 第１の実施形態の変形例に係る、時間間隔を含む通信データのコマンド列に基づいた攻撃判定モデルに対する学習データを例示する図である。 第１の実施形態の変形例に係るＮ−タプルのコマンド列に基づいた攻撃判定モデルに対する学習データを例示する図である。 第１の実施形態に係る管理サーバの攻撃判定学習部が実行する攻撃判定モデルの学習処理を示すフローチャートである。 第１の実施形態に係る集約装置の通信データ監視部が実行する通信データ監視処理を示すフローチャートである。 第２の実施形態に係る通信装置保護システムにおける管理サーバの全体構成を示す。 第２の実施形態に係る、集約機能部のプログラムの一部を模式的に示す図である。 第２の実施形態に係るＨＢ適否判定グラフを例示する図である。 第２の実施形態に係る通信データ検査部が実行する通信データ検査処理を示すフローチャートである。 第３の実施形態に係る通信装置保護システムにおける管理サーバの全体構成を示す。 第３の実施形態に係る使用メモリデータベースのデータ構成を例示する図である。 第３の実施形態に係る、不正ポインタ参照の脆弱性がある関数のプログラムを示す。 第３の実施形態に係る、不正ポインタ参照の脆弱性を修正した後の関数のプログラムを示す。 第３の実施形態に係る、バッファ溢れの脆弱性がある関数のプログラムを示す。 第３の実施形態に係る、バッファ溢れの脆弱性を修正した後の関数のプログラムを示す。 第３の実施形態に係る、二重解放脆弱性がある関数のプログラムを示す。 第３の実施形態に係る、二重解放脆弱性を修正した後の関数のプログラムを示す。 第３の実施形態に係る、整数溢れの脆弱性がある関数のプログラムを示す。 第３の実施形態に係る、整数溢れの脆弱性を修正した後の関数のプログラムを示す。 第３の実施形態に係るパッチ生成部が実行する脆弱性検出処理のフローチャートである。 第３の実施形態に係る管理サーバのパッチ生成部が実行する更新プログラム生成処理のフローチャートである。 第３の実施形態に係る集約装置が実行するゲストシステムのシステム更新処理のフローチャートである。 第３の実施形態に係る集約装置の全体構成を例示する図である。 第２の実施形態の変形例に係る、通信データが脆弱性攻撃を含むか否かを検出する集約装置の全体構成を例示する図である。

≪第１の実施形態：ＩｏＴシステムおよび通信装置保護システムの全体構成≫
以下に本発明を実施するための形態（実施形態）における通信装置保護システムについて説明する。図１は、第１の実施形態に係る通信装置保護システムの保護対象となる集約装置（通信装置）３００Ｘ、３００Ｙとデバイス（通信装置）４００Ｖ〜４００Ｚを含むＩｏＴシステム１０の全体構成を例示する図である。

図１には、フィールドエリアネットワーク５１０Ｙで接続される集約装置３００Ｙとデバイス４００Ｘ〜４００Ｚとを含むフィールドシステム、および、フィールドエリアネットワーク５１０Ｘで接続される集約装置３００Ｘとデバイス４００Ｖ〜４００Ｗとを含むフィールドシステムが示されている。ＩｏＴシステム１０は、ネットワーク５００で接続される２つのフィールドシステムと管理サーバ１００とを含んで構成される。以下、集約装置やデバイスを個々に区別しない場合には、集約装置３００、デバイス４００と記す。

ネットワーク５００は、インターネットのようなオープンなネットワークであって、図１に示した以外の装置も接続されており、集約装置３００やデバイス４００に、攻撃データを送信してサイバー攻撃を実行することが可能である。管理サーバ１００は、ＩｏＴシステム１０外の装置と、集約装置３００およびデバイス４００との通信データを捕捉することができるように、ネットワーク５００に接続されている。

通信装置保護システムは、後記する管理サーバ１００（後記する図２参照）、集約装置３００（後記する図３参照）の通信データ監視部３４０とルートシステム３２０、および、デバイス４００（後記する図４参照）の通信データ監視部４４０とルートシステム４２０を含んで構成される。

≪第１の実施形態：管理サーバの全体構成≫
図２は、第１の実施形態に係る管理サーバ（通信装置保護管理サーバ）１００の全体構成を例示する図である。管理サーバ１００は、ＣＰＵ（Central Processing Unit）から構成される制御部１１０、ＲＡＭ（Random Access Memory）、ハードディスク、フラッシュメモリ等から構成される記憶部１６０、ＮＩＣ（Network Interface Card）から構成される通信部１８０を含んで構成される。

制御部１１０に含まれる攻撃判定学習部１２０（後記する図５参照）は、正常な通信データと攻撃用の（不正な、異常な）通信データとを学習データとして、通信データの正常または不正（異常）を判定する攻撃判定モデル１２１（後記する図５参照）を生成する。攻撃判定モデル１２１は、機械学習技術のモデル（機械学習モデル）である。

記憶部１６０は、通信データ蓄積部１６１および更新データ鍵１６２を含む。通信データ蓄積部１６１は、学習用の通信データ（通信データ群）を記憶している。なお、通信データは、コマンドとパラメータを含んで構成される。更新データ鍵１６２は、攻撃判定モデル１２１の攻撃判定パラメータ１２２（図５参照）を集約装置３００やデバイス４００に送信する際に、攻撃判定パラメータ１２２を保護するための暗号鍵（暗号化用の鍵とデジタル署名生成用の鍵）を含む。

≪第１の実施形態：集約装置の全体構成≫
図３は、第１の実施形態に係る集約装置３００の全体構成を例示する図である。集約装置３００は、ハードウェアとしての制御部（ＣＰＵ）３０１、記憶部（ＲＡＭやフラッシュメモリ）３０２および通信部（ＮＩＣ）３０３を含む。集約装置３００は、論理的には、ゲストシステム３１０、ルートシステム３２０およびハイパーバイザ３３０を含んで構成される。

ゲストシステム３１０は、ハイパーバイザ３３０上で動作する仮想マシンであり、集約機能部３１１および通信データ監視部３４０を含んで構成される。集約機能部３１１は、ＩｏＴシステム１０の集約装置３００としての機能を有する。通信データ監視部３４０は、ゲストシステム３１０が受信した通信データが、正常か不正かを判断して、正常なら集約機能部３１１に出力し、不正なら破棄する。

ルートシステム３２０は、ハイパーバイザ３３０上で動作する仮想マシンであり、システム更新部３２１および更新データ鍵３２２を含んで構成される。システム更新部３２１は、ゲストシステム３１０やルートシステム３２０、ハイパーバイザ３３０のシステム更新を実行する。更新データ鍵３２２は、管理サーバ１００の更新データ鍵１６２と対となる暗号処理用の鍵であり、暗号化された攻撃判定パラメータ１２２（図５参照）を復号したり、デジタル署名を検証したりするための鍵を含む。

ハイパーバイザ３３０は、仮想マシンとしてのゲストシステム３１０およびルートシステム３２０が動作する基盤であり、通信部３０３が受信した通信データをゲストシステム３１０に中継する。

≪第１の実施形態：デバイスの全体構成≫
図４は、第１の実施形態に係るデバイス４００の全体構成を例示する図である。デバイス４００は、ハードウェアとしての制御部（ＣＰＵ）４０１、記憶部（ＲＡＭ、フラッシュメモリなど）４０２、通信部（ＮＩＣ）４０３およびセンサ４０４を含む。センサ４０４は、カメラ、温度計や振動測定用のセンサなどである。図４では、センサ４０４は、デバイス４００に内蔵されるように記載されているが、外付けの場合もある。デバイス４００は、論理的には、ゲストシステム４１０、ルートシステム４２０およびハイパーバイザ４３０を含んで構成される。

ゲストシステム４１０は、ハイパーバイザ４３０上で動作する仮想マシンであり、ＩｏＴシステム１０のデバイス４００としての機能を有するセンサ制御部４１１を含む。通信データ監視部４４０、ルートシステム４２０、システム更新部４２１、更新データ鍵４２２およびハイパーバイザ４３０は、集約装置３００の通信データ監視部３４０、ルートシステム３２０、システム更新部３２１、更新データ鍵３２２およびハイパーバイザ３３０と、それぞれ同様の構成である。なお、通信データ監視部４４０は、ゲストシステム４１０が受信した通信データが、正常ならセンサ制御部４１１に出力し、不正なら破棄する。
なお、デバイス４００がアクチュエータのデバイスである場合には、デバイス４００は、センサ４０４とセンサ制御部４１１の替わりにアクチュエータとアクチュエータ制御部を備える。

≪第１の実施形態：攻撃判定モデル：コマンド列による判定≫
図５は、第１の実施形態に係る、管理サーバ１００の制御部１１０（図５では不図示）に含まれる攻撃判定学習部１２０の動作、および、集約装置３００の通信データ監視部３４０の動作を説明するための図である。

学習用通信データ（図５では通信データと記載）５０１は、通信データ蓄積部１６１に記憶された、１つ以上の通信データを含む通信データのセット（通信データ群）であり、正常か不正（異常）か予め分類されている。不正な学習用通信データ５０１は、不正の種別により、さらに脆弱性攻撃、ＤｏＳ攻撃、総当たり攻撃、その他攻撃の通信データに分類されている。

攻撃判定学習部１２０は、学習用通信データ５０１に含まれる通信データそれぞれからコマンド（制御コマンド）を抜き出して、学習データ５１１を生成する（ステップＳ１１）。例えば、攻撃判定学習部１２０は、正常な学習用通信データ５０１の通信データそれぞれからコマンドを抜き出して、コマンド列（Ｃ１，Ｃ２，Ｃ１，Ｃ２，Ｃ１，Ｃ２，・・・）を生成して、さらに正常であることを示すラベルである「正常」を付与して、学習データ５１１の１行目に示すデータを生成する。「正常」以外のラベルとしては、「脆弱性攻撃」、「ＤｏＳ攻撃」、「総当たり攻撃」などがある。

攻撃判定学習部１２０は、時系列の機械学習モデルである攻撃判定モデル１２１に学習データ５１１を入力して学習処理を実行する（ステップＳ１２）。時系列の機械学習モデルとして、例えばＲＮＮ（Recurrent Neural Network）がある。
攻撃判定学習部１２０は、学習結果である攻撃判定モデル１２１の攻撃判定パラメータ１２２に更新データ鍵１６２を用いてデジタル署名を付与し、暗号化して、集約装置３００に送信する（ステップＳ１３）。

集約装置３００のルートシステム３２０のシステム更新部３２１（図３参照、図５では不図示）は、更新データ鍵３２２を用いて受信した攻撃判定パラメータを復号し、デジタル署名を検証した後に、ゲストシステム３１０の通信データ監視部３４０に出力する。通信データ監視部３４０は、出力されたデータを攻撃判定モデル３４１の攻撃判定パラメータ３４２として設定する。

通信データ監視部３４０は、ゲストシステム３１０が受信した通信データ５０３から、コマンドを抜き出して判定データ５２１を生成して（ステップＳ２１）、攻撃判定モデル３４１に入力し（ステップＳ２２）、正常な通信データか否かの攻撃判定結果５２２を得る（ステップＳ２３）。攻撃判定結果５２２が正常ならば、通信データ監視部３４０は、通信データを集約機能部３１１に出力する。正常でない（脆弱性攻撃、ＤｏＳ攻撃、総当たり攻撃など）場合には、通信データを破棄する。

≪第１の実施形態：攻撃判定モデル：パラメータに含まれるバイナリ列による判定≫
図６は、第１の実施形態に係る、通信データのパラメータに含まれるバイナリ列（図６ではバイト列として記載）に基づいた攻撃判定モデルにおける学習データ５１２を例示する図である。図５では、学習用通信データ（通信データ群）からコマンド列を生成して学習データ５１１としている。図６は、コマンド列に替わり、１つの通信データに含まれるパラメータをバイナリ列として扱い学習データ５１２とする。学習データ５１２には、通信データに含まれるパラメータのバイト列と、正常または異常の種別を示すラベルとが含まれている。

図５に示したコマンド列の場合には、複数の通信データ（通信データ群）から１つのコマンド列の学習データが生成されたが、図６に示したパラメータに含まれるバイナリ列の場合には、学習用通信データに含まれるそれぞれの通信データから学習データが生成される。また、図５のコマンド列の学習モデルは、時系列の学習モデルであったが、図６のバイナリ列の学習モデルとしては、ＳＶＭ（Support Vector Machine）やＮＮ（Neural Network）などの時系列ではない機械学習モデルを用いてもよいし、バイナリ列に含まれるバイナリ（ビット）の並びを時系列データと見做して時系列の機械学習モデルを用いてもよい。

コマンド列の場合と同様に、学習した結果である攻撃判定パラメータ１２２（図５参照）は、集約装置３００に送信され、判定処理が行われる。判定の基となる判定データは、学習処理と同様に１つの通信データのパラメータに含まれるバイナリ列である。コマンド列による攻撃判定とパラメータのバイナリ列による攻撃判定とは、どちらか一方を用いてもよいし、両方の判定結果を組み合わせて判定してもよい。

図６に示した、１つの通信データから１つの学習データを生成する方法に替わり、１つの学習用通信データからバイナリ列の時系列の学習データが生成されるようにしてもよい。詳しくは、１つの学習用通信データに含まれるそれぞれの通信データからパラメータのバイナリ列を抜き出し、バイナリ列の並びを時系列データ（バイナリ列をある時刻のデータと見做す）として、攻撃判定モデル１２１に入力して学習するようにしてもよい。

図６に示した学習データ５１２は、パラメータのバイナリ列のみを学習データとしていた。これに対して、通信データのコマンドとパラメータを組み合わせたデータを学習データとしてもよい。例えば、学習データ５１２の１行目がコマンド「Ｃ３」のパラメータである場合には、（Ｃ３，０ｘ３４，０ｘ５ｆ，０ｘ８ａ，０ｘ０４，０ｘｃ３，・・・，正常）を学習データとしてもよい。

≪第１の実施形態：攻撃判定モデル：コマンド列の変形例≫
図５のコマンド列は、各通信データに含まれるコマンドを通信データの受信した順に抜き出したコマンド列であったが、受信間隔を含めるようにしてもよい。
図７は、第１の実施形態の変形例に係る、時間間隔を含む通信データのコマンド列に基づいた攻撃判定モデルに対する学習データ５１３を例示する図である。学習データ５１３の１行目は、最初の通信データのコマンドがＣ１であり、２．０秒後にコマンドＣ２を含んだ通信データを受信して、その１．４秒後にコマンドＣ１を含んだ通信データを受信した場合の学習データである。

図８は、第１の実施形態の変形例に係るＮ−タプルのコマンド列に基づいた攻撃判定モデルに対する学習データ５１４を例示する図である。コマンド列全体を１つの学習データとするのではなく、コマンド列から所定の長さの部分コマンド列を抜き出しそれぞれを学習データとする。学習データ５１１の１行目は、（Ｃ１，Ｃ２，Ｃ１，Ｃ２，Ｃ１，Ｃ２，・・・）というコマンド列の１つの学習データであった。これを、５−タプルとして長さ５のコマンド列（Ｃ１，Ｃ２，Ｃ１，Ｃ２，Ｃ１）、（Ｃ２，Ｃ１，Ｃ２，Ｃ１，Ｃ２）を抜き出し、それぞれを学習データとしてもよい。

≪第１の実施形態：管理サーバでの攻撃判定モデルの学習処理≫
図９は、第１の実施形態に係る管理サーバ１００の攻撃判定学習部１２０が実行する攻撃判定モデルの学習処理を示すフローチャートである。
ステップＳ１０１において、攻撃判定学習部１２０は、学習用通信データ５０１（図５参照）に含まれる通信データそれぞれからコマンドを抜き出して、学習データ５１１を生成する。

ステップＳ１０２において、攻撃判定学習部１２０は、時系列の機械学習モデルである攻撃判定モデル１２１に学習データ５１１を入力して学習処理を実行する。
ステップＳ１０３において、攻撃判定学習部１２０は、学習処理の結果である攻撃判定モデル１２１の攻撃判定パラメータ１２２にデジタル署名を付与し、暗号化して、集約装置３００に送信する。デジタル署名生成や暗号化には、更新データ鍵１６２が用いられる。

≪第１の実施形態：集約装置での通信データ監視処理≫
図１０は、第１の実施形態に係る集約装置３００の通信データ監視部３４０が実行する通信データ監視処理を示すフローチャートである。
ステップＳ１２１において、集約装置３００は、攻撃判定学習部１２０が送信した攻撃判定パラメータを受信し、受信データを検証して、攻撃判定モデル３４１（図５参照）に攻撃判定パラメータ３４２を設定する。詳しくは、ゲストシステム３１０は、受信データをルートシステム３２０に出力する。次に、ルートシステム３２０のシステム更新部３２１は、更新データ鍵３２２を用いて受信データを復号し、デジタル署名を検証した後に、ゲストシステム３１０の通信データ監視部３４０に出力する。通信データ監視部３４０は、出力されたデータを攻撃判定モデル３４１の攻撃判定パラメータ３４２として設定する（図５参照）。なお、システム更新部３２１が、受信したデータの復号またはデジタル署名の検証に失敗した場合には、管理サーバ１００に通知する。

ステップＳ１２２において、通信データ監視部３４０は、ゲストシステム３１０が受信した通信データごとに、ステップＳ１２３〜Ｓ１２９の処理を繰り返す。
ステップＳ１２３において、通信データ監視部３４０は、通信データからコマンドを抜き出し、攻撃判定モデル３４１に入力して、攻撃か否かを判定する。通信データのパラメータのバイナリ列を学習した機械学習モデルを採用している場合には、通信データ監視部３４０は、通信データからパラメータのバイナリ列を抜き出し、攻撃判定モデル３４１に入力して、攻撃か否か、攻撃であればその種別を判定する。

ステップＳ１２４において、通信データ監視部３４０は、ステップＳ１２３の判定結果が攻撃であれば（Ｓ１２４→Ｙ）ステップＳ１２６に進み、正常であれば（Ｓ１２４→Ｎ）ステップＳ１２５に進む。
ステップＳ１２５において、通信データ監視部３４０は、通信データを集約機能部３１１に出力し、ステップＳ１３０に進む。
ステップＳ１２６において、通信データ監視部３４０は、攻撃種別がＤｏＳ攻撃であれば（Ｓ１２６→ＤｏＳ攻撃）ステップＳ１２７に進み、攻撃種別が総当り攻撃であれば（Ｓ１２６→総当たり攻撃）ステップＳ１２８に進み、攻撃種別がその他攻撃であれば（Ｓ１２６→その他攻撃）ステップＳ１２９に進む。

ステップＳ１２７において、通信データ監視部３４０は、通信データの送信元から送信される通信データを所定時間フィルタリングして、当該送信元からの通信データを受信しないようにし、ステップＳ１３０に進む。
ステップＳ１２８において、通信データ監視部３４０は、通信データのコマンドと同じコマンドを含む通信データを所定時間フィルタリングして、当該コマンドの通信データを受信しないようにし、ステップＳ１３０に進む。
ステップＳ１２９において、通信データ監視部３４０は、通信データを破棄し、ステップＳ１３０に進む。
ステップＳ１３０において、通信データ監視部３４０は、ステップＳ１２３に戻る。

≪第１の実施形態：攻撃判定モデルの特徴≫
コマンド列を基にした攻撃判定モデルは、１以上の長さのコマンド列から攻撃の当否や攻撃種別を判定している。このために、当初正常だが途中から攻撃に変化する通信データ列による攻撃や長い期間に亘って続くような攻撃も判定できる。
パラメータのバイナリ列を基にした攻撃判定モデルを採用することにより、コマンド列だけでは判定できないような、パラメータに攻撃の特徴が現れるような攻撃でも判定できる。また、パラメータのバイナリ列を時系列として扱う攻撃判定モデルを採用することにより、パラメータを変化させながら攻撃するような場合でも、攻撃と判定できるようになる。

通信データ監視部３４０は、判定された攻撃種別に応じて、送信元を基にフィルタリング、コマンドを基にフィルタリング、および、通信データの廃棄を実行しており、正常な通信データへの影響を抑制しながら、攻撃を防ぐことができる。
以上において、集約装置３００における攻撃判定モデルの生成（図５参照）や通信データ監視（図１０参照）を説明したが、デバイス４００に関しても同様に攻撃判定モデルの生成や通信データの監視が可能である。

≪第１の実施形態：変形例：送信元別の攻撃判定モデル≫
図５に示した学習用通信データ５０１は、通信データ蓄積部１６１に記憶された、１つ以上の通信データを含む通信データのセットであり、正常か不正か予め分類されている。通信データの送信元によって、さらに分類されて、１つの学習用通信データ５０１に含まれる通信データの送信元は同一であるように分類されてもよい。この場合には、通信データ監視部３４０における判定データ５２１の生成も送信元ごとに行う。詳しくは、通信データ監視部３４０は、送信元ごとに攻撃判定モデル３４１を設けて、ゲストシステム３１０が通信データを受信したら、判定データ５２１を生成（ステップＳ２１）して、送信元に対応する攻撃判定モデル３４１に入力（ステップＳ２２）し、攻撃判定結果５２２を出力として得る（ステップＳ２３）。

≪第１の実施形態：変形例：集約装置の通信データ監視部≫
集約装置３００において、ゲストシステム３１０の通信データ監視部３４０が、通信データを攻撃判定モデル３４１に入力して、攻撃か否かを判定して、攻撃と判定されたならば通信パケットをフィルタリング（破棄）していた。この通信データ監視の処理を、ゲストシステム３１０ではなく、ハイパーバイザ３３０で実行してもよい。詳しくは、ハイパーバイザ３３０が、ゲストシステム３１０宛ての通信データを、ハイパーバイザ内の攻撃判定モデルに入力して、攻撃か否かを判定して、攻撃と判定されたならば通信パケットをフィルタリング（破棄）するようにしてもよい。

または、ルートシステム３２０で判定するようにしてもよい。詳しくは、ハイパーバイザ３３０が、ゲストシステム３１０宛ての通信データをルートシステム３２０に送信し、ルートシステム３２０が自身の攻撃判定モデルに入力して、攻撃か否かを判定し、判定結果をハイパーバイザ３３０に送信する。ハイパーバイザ３３０は、攻撃と判定されたならば通信パケットをフィルタリング（破棄）し、正常ならゲストシステム３１０に送信する。
ステップＳ１２７〜Ｓ１２９（図１０参照）のフィルタリング処理において、通信データ監視部３４０が管理サーバ１００に攻撃を検知したことを通知するようにしてもよい。

≪第１の実施形態：変形例：管理サーバ≫
管理サーバ１００は、ＩｏＴシステム１０の管理サーバであり、集約装置３００やデバイス４００の通信装置を保護する通信装置保護システムの管理サーバでもある。ＩｏＴシステム１０の管理サーバと、通信装置保護システムの管理サーバとを異なるサーバにしてもよい。

≪第１の実施形態：変形例：正常な学習用通信データのみでの学習≫
攻撃判定学習部１２０は、正常と不正の学習用通信データ５０１を用いて学習する（図５参照）。正常な学習用通信データのみから攻撃判定モデル１２１を生成して、不正な通信データを異常として検出するようにしてもよい。このような機械学習モデル（アルゴリズム） として、１クラスＳＶＭ、クラスタリング、ｋ近傍法などがある。

≪第２の実施形態≫
第１の実施形態では、学習用通信データは、正常と攻撃種別により、予め分類されて通信データ蓄積部１６１に格納されていた。これに対して、第２の実施形態の管理サーバでは、未分類の通信データ（通信データ群）を集約装置３００のクローン（図１１参照）に処理させて、動作が正常か否かを観察することで、正常と攻撃種別とを分類する。

≪第２の実施形態：管理サーバの全体構成≫
図１１は、第２の実施形態に係る通信装置保護システムにおける管理サーバ１００Ａの全体構成を示す。第１の実施形態の管理サーバ１００と比較すると、制御部１１０にクローン１３０と通信データ検査部１４０とが加わり、記憶部１６０にプログラムリポジトリ１６３とＨＢ適否判定グラフ１６４とが加わる。なお、ＨＢはHeart Beatの略記である。

クローン１３０は、集約装置３００のクローンである仮想マシンであり、ゲストシステム３１０の動作をシミュレートする。クローン１３０は、集約装置３００の台数分だけ存在し、それぞれ対応する集約装置３００（ゲストシステム３１０）をシミュレートする。通信データ検査部１４０は、通信データを処理中のクローン１３０が送信するＨＢを受信し、クローン１３０の処理に異常が発生していないかを監視して、通信データが正常か不正かを判定する。

プログラムリポジトリ１６３は、通信データを処理する集約機能部３１１（図３参照）のプログラムを格納している。ＨＢ適否判定グラフ１６４（後記する図１３参照）は、ＨＢの受信順序や受信間隔の適否を判定する際に参照される有向グラフである。クローン１３０から送信されるＨＢの受信順序や受信間隔が、ＨＢ適否判定グラフ１６４に示される順序や間隔に合致しているなら、クローン１３０は正常動作しており、処理中の通信データは正常であると判定される。

≪第２の実施形態：ＨＢを用いた通信データ検査≫
図１２と図１３を参照しながら、通信データをクローン１３０に処理させ、ＨＢの受信順序や受信間隔を観察することで正常に処理するか否かを判断して、通信データが正常か不正かを判断する手法を説明する。

図１２は、第２の実施形態に係る、集約機能部３１１のプログラムの一部を模式的に示す図である。関数Ａと関数Ｂと関数Ｃの一部が図示されており、関数Ａのループ処理（４〜８行）のなかで、関数Ｂと、条件によっては関数Ｃが呼ばれる。２行目と５行目と１２行目と１７行目とは、ＨＢ送信処理を実行するコードであり、送信するＨＢの識別子（ＨＢ識別子）をパラメータとする。クローン１３０が、通信データを処理する最中にＨＢ送信処理を実行すると、通信データ検査部１４０が、ＨＢ識別子と実行タイミング（実行時刻）を受信する。

図１３は、第２の実施形態に係るＨＢ適否判定グラフ１６４を例示する図である。グラフの各ノードは、ＨＢを表している。ノード間の矢印と矢印に付与された数値とは、それぞれ次に受信する可能性のあるＨＢと、受信する実行タイミングの間隔（実行タイミングサイクル数）とを示している。例えば、「関数Ｂ開始」から出る３つの矢印は、「関数Ｂ開始」のＨＢの次には、「関数Ａループ開始１」、「関数Ｃ開始」のＨＢを受信するか、処理が終了することを示している。何れの場合であっても、９実行タイミングサイクルでＨＢを受信または終了することを示している。

矢印で示されるＨＢ以外のＨＢを受信した場合、または、矢印に付与された実行タイミングサイクルでＨＢを受信しない場合には、通信データ検査部１４０は、処理に異常（不正）が発生した（ＨＢ適否判定グラフ１６４から逸脱）と判断し、処理中の通信データは攻撃データであると判定する。図１３では、実行タイミングサイクル数が１つの数値として示されているが、「１０〜１４」や「１２±２」と幅をもった間隔であってもよい。
ＨＢ適否判定グラフ１６４は、プログラム（図１２参照）を解析して、処理の流れから生成してもよいし、正常な通信データをクローン１３０に処理させたときに受信したＨＢの種別や間隔から生成してもよい。

≪第２の実施形態：通信データ検査処理≫
図１４は、第２の実施形態に係る通信データ検査部１４０が実行する通信データ検査処理を示すフローチャートである。
ステップＳ２０１において、通信データ検査部１４０は、通信データ蓄積部１６１から集約装置３００向けの通信データのセット（学習用通信データ）を取得して、所定の単位時間当たりの通信データ数が所定の閾値以上である期間の長さを測定する。

ステップＳ２０２において、通信データ検査部１４０は、測定した期間の長さが、所定の閾値以上ならば（ステップＳ２０２→Ｙ）ステップＳ２０３に進み、所定の閾値未満ならば（ステップＳ２０２→Ｎ）ステップＳ２０４に進む。
ステップＳ２０３において、通信データ検査部１４０は、ステップＳ２０１で取得した学習用通信データは、ＤｏＳ攻撃の学習用通信データと判定し、図１４の通信データ検査処理を終了する。

ステップＳ２０４において、通信データ検査部１４０は、通信データのセットをクローン１３０に入力して処理させて、処理結果が正常（コマンド処理が終了して正常な応答を返す。）か、エラー（コマンド処理が終了してエラーの応答を返す。例えば、認証失敗など。）かの処理結果を得る。
ステップＳ２０５において、通信データ検査部１４０は、所定の単位時間当たりの、処理結果がエラーである通信データ数が所定の閾値以上である期間の長さを測定する。

ステップＳ２０６において、通信データ検査部１４０は、測定した期間の長さが、所定の閾値以上ならば（ステップＳ２０６→Ｙ）ステップＳ２０７に進み、所定の閾値未満ならば（ステップＳ２０６→Ｎ）ステップＳ２０８に進む。
ステップＳ２０７において、通信データ検査部１４０は、ステップＳ２０１で取得した学習用通信データは、総当たり攻撃の学習用通信データと判定し、図１４の通信データ検査処理を終了する。

ステップＳ２０８において、通信データ検査部１４０は、通信データごとにステップＳ２０９〜Ｓ２１２の処理を繰り返す。
ステップＳ２０９において、通信データ検査部１４０は、通信データをクローン１３０に入力し処理させて、ＨＢを受信する。
ステップＳ２１０において、通信データ検査部１４０は、受信したＨＢの順序や受信間隔がＨＢ適否判定グラフから逸脱しているか否かを判定する。

ステップＳ２１１において、通信データ検査部１４０は、ステップＳ２１０において逸脱と判定すれば（ステップＳ２１１→Ｙ）ステップＳ２１２に進み、逸脱ではないと判定すれば（ステップＳ２１１→Ｎ）ステップＳ２１３に進む。
ステップＳ２１２において、通信データ検査部１４０は、ステップＳ２０１で取得した学習用通信データは、脆弱性攻撃の学習用通信データと判定し、図１４の通信データ検査処理を終了する。

ステップＳ２１３において、通信データ検査部１４０は、学習用通信データに含まれる全ての通信データについて、ステップＳ２０９〜Ｓ２１２の処理を実行したか判定する。通信データ検査部１４０は、全て処理済みならステップＳ２１４に進み、未処理の通信データがあればステップＳ２０９に戻る。
ステップＳ２１４において、通信データ検査部１４０は、ステップＳ２０１で取得した学習用通信データは、正常な学習用通信データと判定する。

≪第２の実施形態：通信データ検査処理の特徴≫
第１の実施形態では、学習用通信データの正常や攻撃種別を人手で予め分類することを想定している。これに対して、第２の実施形態では、管理サーバ１００Ａが、通信データ検査処理を実行することで、学習用通信データを正常か不正（異常）か分類し、さらに、不正ならば攻撃種別を分類することができる。取得した通信データについて管理サーバ１００Ａが分類して、学習処理を実行することで、大量の学習データを用いて学習することが可能となり、攻撃判定精度を向上させることができる。また、１つの集約装置で攻撃が発生した場合に、この攻撃に用いられた通信データを別の集約装置のクローンで正常か不正かを分類して、学習用通信データとすることで、他の集約装置に対する攻撃を未然に防ぐとことができるようになる。
以上、集約装置３００に対する通信データ検査処理について説明したが、デバイス４００についても同様に通信データの検査処理が可能である。

≪第３の実施形態≫
第３の実施形態では、第２の実施形態において脆弱性攻撃と判断された通信データを利用して、管理サーバがプログラムの脆弱性を修正するパッチ（更新プログラム、修正プログラム）を生成する。

≪第３の実施形態：管理サーバの全体構成≫
図１５は、第３の実施形態に係る通信装置保護システムにおける管理サーバ１００Ｂの全体構成を示す。第２の実施形態の管理サーバ１００Ａ（図１１参照）と比較すると、制御部１１０にパッチ生成部１５０が加わり、記憶部１６０に使用メモリデータベース（図１５では使用メモリＤＢ（Database）と記載）１７０が加わる。

パッチ生成部１５０は、通信データ検査処理において脆弱性攻撃（図１４のステップＳ２１２参照）と判定された通信データをクローン１３０に処理させて、動作を監視して、不正が発生する箇所を特定することで、ゲストシステム３１０のプログラム（集約機能部３１１のプログラム）のなかに存在する脆弱性を検出する。例えば、パッチ生成部１５０は、脆弱性攻撃の通信データを処理するプログラムのプロセスにアタッチしたプロセス（スタブ）と通信して制御することで、プロセスの処理をプログラムの１ステップ分ずつ進めたり、データ（プログラムの変数）の内容を確認したりしながら、不正（不正なデータ操作）が発生した箇所を特定する。

パッチ生成部１５０は、不正が発生した箇所の直前に、不正が発生するか否か検査して不正が発生する場合には処理を中断するコードを挿入するパッチ（更新プログラム、修正プログラム）を生成する。パッチ生成部１５０の動作は、図１７Ａ〜図２１を参照して後記する。

図１６は、第３の実施形態に係る使用メモリデータベース１７０のデータ構成を例示する図である。使用メモリデータベース１７０は表形式のデータであって、１つのレコード（行）は、クローン１３０のプログラムで用いられる変数や配列などのデータ（データが格納される領域）を示し、ポインタ１７１、サイズ１７２、種別１７３の属性（列）を含む。ポインタ１７１とサイズ１７２は、データの先頭アドレスとサイズ（長さ）である。種別１７３は、データのプログラムにおける種別（メモリ領域）であり、「スタック」、「ヒープ」、「スタティック（静的）」および「テキスト（プログラム）」の４つがある。例えば、レコード１７９は、アドレスが「0012e304（16進表記）」から始まる７２バイトのデータ（データの領域）を示す。

使用メモリデータベース１７０は、プログラムにおいてデータ領域が変更される場合に更新される。例えば、プログラムの開始時にプログラム全体で参照されるデータ（スタティック領域上のグローバル変数）が登録され、関数が呼び出されるタイミングで関数内から参照されるデータ（スタック領域上のローカル変数）が登録され、また、プログラムの実行途中で確保されるデータ（ヒープ領域のバッファ）がその時点で登録される。また、関数の終了やプログラム実行途中でのデータ解放のタイミングで削除される。

≪第３の実施形態：不正検出（不正ポインタ参照）とパッチ生成≫
以下に、パッチ生成部１５０が実行するパッチ生成処理における、脆弱性の検出手法と修正手法について説明する。図１７Ａと図１７Ｂとは、第３の実施形態に係るパッチ生成部１５０の不正ポインタ参照の脆弱性（不正なデータ操作）を検出する手法と修正する手法を説明するための図である。図１７Ａは、不正ポインタ参照の脆弱性がある関数Ｄのプログラムを示し、図１７Ｂは、不正ポインタ参照の脆弱性を修正した後の関数Ｄのプログラムを示す。脆弱性攻撃を含む通信データの処理中に関数Ｄは、引数Ｄ２が指すデータを引数Ｄ１が指す領域にstrcpy関数を用いてコピーする（図１７Ａの２行目参照）が、Ｄ１が不正ポインタであり、コピーしようとしてＤ１がポイントするメモリ領域を参照しようとすると、不正が発生してプログラムが異常終了する。

パッチ生成部１５０は、ポインタ変数が参照される前に、ポインタが参照する先のメモリ領域が、使用メモリデータベース１７０において、種別１７３がスタック、ヒープ、スタティックの何れかである領域を指しているか検査し、指していなければ不正と判断する。
不正と判断された場合には、不正な参照が発生する箇所（図１７Ａの２行目、図１７Ｂの４行目）の直前に、変数のポインタを検査するコード（図１７Ｂの２行目）と、不正である場合に例外処理を実行するコード（図１７Ｂの３行目）を挿入するパッチを生成する。

≪第３の実施形態：不正検出（バッファ溢れ）とパッチ生成≫
図１８Ａと図１８Ｂとは、第３の実施形態に係るパッチ生成部１５０のバッファ溢れ（buffer overflow）の脆弱性（不正なデータ操作）を検出する手法と修正する手法を説明するための図である。図１８Ａは、バッファ溢れの脆弱性がある関数Ｅのプログラムを示し、図１８Ｂは、バッファ溢れの脆弱性を修正した後の関数Ｅのプログラムを示す。脆弱性攻撃を含む通信データの処理中に関数Ｅは、引数Ｅ１が指すデータを変数bufferが指す領域にstrcpy関数を用いてコピーする（図１８Ａの３行目参照）が、コピー元のＥ１が示すデータのサイズが、コピー先のbufferのサイズより大きく、コピーするとバッファ溢れが生じ、不正発生の原因となる。

パッチ生成部１５０は、コピーの前に、コピー元とコピー先の領域のサイズを検査して、コピー元がコピー先より大きい場合には不正と判断する。領域のサイズは、使用メモリデータベース１７０において、ポインタが指す領域が、種別１７３がスタック、ヒープ、スタティックの何れかである領域であり、その領域のサイズ１７２から算出する。例えば、ポインタが「0012e308（１６進表示）」である場合、このポインタはレコード１７９が示す領域の先頭（０バイト目）から４バイト目を指しており、領域のサイズは６８バイトとなる。

不正と判断された場合には、不正なコピーが発生する箇所（図１８Ａの３行目、図１８Ｂの５行目）の直前に、領域のサイズを検査するコード（図１８Ｂの３行目）と、不正である場合に例外処理を実行するコード（図１８Ｂの４行目）を挿入するパッチを生成する。

≪第３の実施形態：不正検出（二重解放）とパッチ生成≫
図１９Ａと図１９Ｂとは、第３の実施形態に係るパッチ生成部１５０の二重解放（double-free）の脆弱性（不正なデータ操作）を検出する手法と修正する手法を説明するための図である。図１９Ａは、二重解放の脆弱性がある関数Ｆのプログラムを示し、図１９Ｂは、二重解放の脆弱性を修正した後の関数Ｆのプログラムを示す。脆弱性攻撃を含む通信データの処理中に関数Ｆは、引数Ｆ１が指すポインタが指すメモリ領域を、free関数を用いて解放する（図１９Ａの２行目参照）が、既に解放済みのメモリ領域を解放すると不正発生の原因となる。

パッチ生成部１５０は、解放の前に、ポインタが指す領域が解放されていないことを検査し、解放済みの場合には不正と判断する。解放済みか否かは、使用メモリデータベース１７０において、種別１７３がヒープであって、ポインタ１７１が解放対象のポインタに一致するレコードがあれば、解放前（使用中）であり、正常と判断する。このようなレコードがなければ不正と判断する。

不正と判断された場合には、不正な解放が発生する箇所（図１９Ａの２行目、図１９Ｂの４行目）の直前に、ポインタを検査するコード（図１９Ｂの２行目）と、不正である場合に例外処理を実行するコード（図１９Ｂの３行目）を挿入するパッチを生成する。

≪第３の実施形態：不正検出（整数溢れ）とパッチ生成≫
図２０Ａと図２０Ｂとは、第３の実施形態に係るパッチ生成部１５０の整数溢れの脆弱性（不正なデータ操作）を検出する手法と修正する手法を説明するための図である。図２０Ａは、整数溢れの脆弱性がある関数Ｇのプログラムを示し、図２０Ｂは、整数溢れの脆弱性を修正した後の関数Ｇのプログラムを示す。脆弱性攻撃を含む通信データの処理中に関数Ｇは、引数Ｇ１に引数Ｇ２を加算して変数ｘに格納する（図２０Ａの３行目参照）が、加算の結果が変数ｘの最大値を超える（整数溢れ）と不正発生の原因となる。

パッチ生成部１５０は、加算の前に、整数溢れの有無を検査し、溢れが発生する場合には不正と判断する。不正と判断された場合には、整数溢れが発生する箇所（図２０Ａの３行目、図２０Ｂの５行目）の直前に、整数溢れを検査するコード（図２０Ｂの３行目）と、不正である場合に例外処理を実行するコード（図２０Ｂの４行目）を挿入するパッチを生成する。なお、変数ｘの最小値を超える場合も同様である。

≪第３の実施形態：不正検出（その他）とパッチ生成≫
その他の脆弱性についても、不正な通信データを処理するプロセスを監視することで、不正が発生する箇所を検出するようにしてもよい。例えば、printf関数などの書式指定出力関数において、書式を指定する変数に書式を指定する文字列("%s"など)が含まれている場合に不正と判断するようにしてもよい。

≪第３の実施形態：脆弱性検出処理≫
図２１〜図２４を参照して、管理サーバにおける、脆弱性を検出し、検出された脆弱性を修正する更新プログラム（パッチ）を生成して、集約装置に送信する処理と、集約装置における、更新プログラムを受信して、システムを更新する処理とを説明する。

図２１は、第３の実施形態に係るパッチ生成部１５０が実行する脆弱性検出処理のフローチャートである。図２１を参照しながら、脆弱性攻撃の通信データを用いて脆弱性を検出する処理を説明する。
ステップＳ３０１において、パッチ生成部１５０は、脆弱性攻撃の通信データをクローン１３０に入力して、クローン１３０のプログラム（集約機能部３１１のプログラム）に通信データの処理を開始させる。

ステップＳ３０２において、パッチ生成部１５０は、クローン１３０のプログラムを制御して１ステップずつ進めながら、プログラム上のステップ（以下、現ステップまたは現コードとも記す）それぞれに対して、ステップＳ３０３〜Ｓ３１４の処理を繰り返す。プログラムを制御する手法として、例えば、パッチ生成部１５０と通信可能なクローン１３０上のプロセス（スタブ）をプログラムのプロセスにアタッチして、プログラム上の１ステップずつ進める手法がある。

ステップＳ３０３において、パッチ生成部１５０は、現コードにポインタが含まれ、当該ポインタが不正か否かを判定する。ポインタが不正であるとは、ポインタが、使用メモリデータベース１７０において、種別１７３がスタック、ヒープ、スタティックの何れかであるメモリ領域の内部を指していない場合である。例えば、ポインタが0012e306（１６進表記）であれば、レコード１７９で示されるメモリ領域の内部を指しているので正常である。

ステップＳ３０４において、パッチ生成部１５０は、ステップS３０３の判定において不正なポインタがあれば（ステップＳ３０４→Ｙ）ステップＳ３０５に進み、なければ（ステップＳ３０４→Ｎ）ステップＳ３０６に進む。

ステップＳ３０５において、パッチ生成部１５０は、現コードに不正ポインタ参照の脆弱性があると判定し、図２１の脆弱性検出処理を終了する。
ステップＳ３０６において、パッチ生成部１５０は、現コードがバッファ（メモリ領域）のコピー処理でありバッファ溢れが発生するか否かを判定する。バッファのサイズは、使用メモリデータベース１７０を参照して算出できる（図１８Ａと図１８Ｂの説明参照）。なお、コピー元が文字列である場合には、文字列の長さからバッファのサイズを算出する。例えば、文字の型がcharである「"abcd"」の文字列のサイズは終端文字を含めて５バイトである。コピー元のサイズがコピー先より大きい場合にはバッファ溢れが発生すると判定する。

ステップＳ３０７において、パッチ生成部１５０は、ステップＳ３０６の判定においてバッファ溢れが発生すれば（ステップＳ３０７→Ｙ）ステップＳ３０８に進み、なければ（ステップＳ３０７→Ｎ）ステップＳ３０９に進む。
ステップＳ３０８において、パッチ生成部１５０は、現コードにバッファ溢れ（図２１ではＢＯＦ（buffer overflow）と記載）の脆弱性があると判定し、図２１の脆弱性検出処理を終了する。

ステップＳ３０９において、パッチ生成部１５０は、現コードがメモリ解放の処理であり二重解放が発生するか否かを判定する。二重解放か否かは、使用メモリデータベース１７０のなかで、種別１７３がヒープであり、ポインタ１７１がメモリ解放処理の対象となっているポインタに一致するレコードがなければ、二重解放と判定する。
ステップＳ３１０において、パッチ生成部１５０は、ステップＳ３０９の判定において二重解放が発生すれば（ステップＳ３１０→Ｙ）ステップＳ３１１に進み、なければ（ステップＳ３１０→Ｎ）ステップＳ３１２に進む。

ステップＳ３１１において、パッチ生成部１５０は、現コードに二重解放の脆弱性があると判定し、図２１の脆弱性検出処理を終了する。
ステップＳ３１２において、パッチ生成部１５０は、現コードが整数演算の処理であり整数溢れが発生するか否かを判定する。整数溢れか否かは、演算の結果が、変数の型の最大値と最小値の間にあるか否かで判定する。
ステップＳ３１３において、パッチ生成部１５０は、ステップＳ３１２の判定において整数溢れが発生すれば（ステップＳ３１３→Ｙ）ステップＳ３１４に進み、なければ（ステップＳ３１３→Ｎ）ステップＳ３１５に進む。

ステップＳ３１４において、パッチ生成部１５０は、現コードに整数溢れの脆弱性があると判定し、図２１の脆弱性検出処理を終了する。
ステップＳ３１５において、パッチ生成部１５０は、通信データの処理に係るプログラムの全ステップを実行したか判断し、未処理のステップ（コード）があれば、ステップＳ３０３に戻り、全ステップを実行した場合には、脆弱性検査処理を終了する。

≪第３の実施形態：脆弱性検査処理の特徴≫
パッチ生成部１５０は、脆弱性攻撃を含む通信データをクローン１３０に処理させて、不正が発生するプログラムの箇所を特定することで、脆弱性のあるプログラムの場所（コード）を特定することができる。
プログラムを解析して、脆弱性を指摘するコード検査ツールが存在している。このような検査ツールは、静的な検査を行うために、変数の値であるポインタが解放済みか否かを判定できない、ポインタが指す文字列の長さが算出できずバッファ溢れが発生するか否かを判定できないといった問題があった。パッチ生成部１５０は、脆弱性攻撃を含む通信データを処理する過程で検査を行っており、ポインタが解放済みか否かを判定したり、文字列の長さを算出してバッファ溢れが発生するか否かを判定したりできる。このため、従来までの検査ツールでは検出できなかったプログラムの脆弱性のある箇所（コード）を特定することができる。引いては、後記するように、特定した脆弱性を修正するパッチを生成することができるようになる。

≪第３の実施形態：プログラム更新（パッチ）処理≫
図２２と図２３を参照して、管理サーバと集約装置とで実行されるプログラム更新処理を説明する。図２２は、第３の実施形態に係る管理サーバ１００Ｂのパッチ生成部１５０（図１５参照）が実行する更新プログラム（パッチ）生成処理のフローチャートである。図２２を参照して、脆弱性検出処理（図２１参照）で検出された脆弱性を修正する更新プログラムを生成する処理を説明する。

ステップＳ３３１において、パッチ生成部１５０は、更新プログラムを生成する。詳しくは、パッチ生成部１５０は、脆弱性検出処理（図２１参照）において検出された、プログラム（集約機能部３１１のプログラム）の不正ポインタ参照、バッファ溢れ、二重解放および整数溢れの脆弱性に対して図１７Ａ〜図２０Ｂで説明した修正コードを追加する更新プログラム（パッチ）を生成する。
ステップＳ３３２において、パッチ生成部１５０は、更新プログラムに署名を付与し、暗号化する。署名や暗号化に用いる鍵は、更新データ鍵１６２に含まれている。
ステップＳ３３３において、パッチ生成部１５０は、署名が付与され暗号化された更新プログラムを集約装置に送信する。

図２３は、第３の実施形態に係る集約装置３００Ａ（後記する図２４参照）が実行するゲストシステム３１０のシステム更新処理のフローチャートである。図２３を参照して、ゲストシステム３１０の集約機能部３１１を修正する処理を説明する。
ステップＳ３５１において、ゲストシステム３１０は、管理サーバ１００Ｂが送信した更新プログラムを受信する。

ステップＳ３５２において、ゲストシステム３１０は、更新プログラムをルートシステム３２０に送信する。
ステップＳ３５３において、ルートシステム３２０のシステム更新部３２１は、更新プログラムを検査する。詳しくは、システム更新部３２１は、更新プログラムを復号して、署名を検査する。復号や署名の検証の際には、更新データ鍵３２２を用いる。
ステップＳ３５４において、システム更新部３２１は、ステップＳ３５３の検査に合格（復号できて署名検証に成功）すれば（ステップＳ３５４→Ｙ）ステップＳ３５６に進み、失敗すれば（ステップＳ３５４→Ｎ）ステップＳ３５５に進む。

ステップＳ３５５において、システム更新部３２１は、検査に失敗したことを管理サーバ１００Ｂに報告する。
ステップＳ３５６において、システム更新部３２１は、ハイパーバイザ３３０を介してゲストシステム３１０にシャットダウンを指示する。
ステップＳ３５７において、システム更新部３２１は、ゲストシステム３１０のシャットダウン後に、更新プログラムを適用して、ゲストシステム３１０を更新する。詳しくは、記憶部３０２上の集約機能部３１１のプログラムを修正して更新する。

ステップＳ３５８において、システム更新部３２１は、ハイパーバイザ３３０に指示して、ゲストシステム３１０を起動する。
ステップＳ３５９において、システム更新部３２１は、更新が完了したことを管理サーバ１００Ｂに報告する。

≪第３の実施形態：集約装置の全体構成≫
図２４は、第３の実施形態に係る集約装置３００Ａの全体構成を例示する図である。第１の実施形態の集約装置３００（図３参照）と比較すると、ハイパーバイザ３３０内に使用メモリデータベース３５０が追加される。使用メモリデータベース３５０は、使用メモリデータベース１７０（図１５と図１６参照）と同様のデータ構成をしており、更新プログラムに含まれるポインタや領域サイズを検査するコードが実行されると参照される。
脆弱性攻撃を含む通信データを受信しても、システム更新後の集約機能部３１１は、不正（不正なデータ操作）を検出して、例外処理を実行することで、攻撃を未然に防ぐことができる。引いては、集約機能部３１１が停止したり、不正に操作されたりするなどのサイバー攻撃を防ぐことができる。
以上、集約装置３００Ａに対するパッチ（更新プログラム）生成とシステム更新について説明したが、デバイス４００についても同様に可能である。

≪変形例：集約装置において脆弱性攻撃を含む通信データを検出≫
第２の実施形態では、管理サーバ１００Ａのクローン１３０を用いて、脆弱性攻撃を含む通信データを検出していた（図１４のステップＳ２０８〜Ｓ２１３参照）。この検出を、集約装置で実行してもよい。
図２５は、第２の実施形態の変形例に係る、通信データが脆弱性攻撃を含むか否かを検出する集約装置の全体構成を例示する図である。集約装置３００（図３参照）と比較すると、ルートシステム３２０に、通信データ検査部３２３とＨＢ適否判定グラフ３２４とが追加されている。通信データ検査部３２３およびＨＢ適否判定グラフ３２４は、通信データ検査部１４０およびＨＢ適否判定グラフ１６４と同様である。通信データ検査部３２３は、通信データを処理している集約機能部３１１が送信するＨＢをハイパーバイザ３３０経由で受信して、ＨＢの受信順序や受信間隔がＨＢ適否判定グラフ３２４から逸脱していないかを監視することで、処理中の通信データが脆弱性攻撃を含むか否か判断する。
以上、集約装置３００Ｂに対する脆弱性攻撃を含む通信データ検出処理について説明したが、デバイス４００についても同様に検出処理が可能である。

１００，１００Ａ，１００Ｂ 管理サーバ（通信装置保護管理サーバ）
１２０ 攻撃判定学習部
１３０ クローン（仮想マシン）
１４０ 通信データ検査部
１５０ パッチ生成部
３００，３００Ａ，３００Ｂ 集約装置（通信装置）
３４０，４４０ 通信データ監視部
４００ デバイス（通信装置）

Claims (5)

1. 通信装置に対する正常な通信データ群に含まれる通信データおよび不正な通信データ群に含まれる通信データから、前記通信装置に対するコマンドおよび前記コマンドのパラメータの何れか１つまたは双方を抜き出して作成した学習データを用いて教師ありの学習をさせることで、前記通信装置に対する通信データが正常か不正かを判定する攻撃判定モデルを生成する攻撃判定学習部を備える
   ことを特徴とする通信装置保護管理サーバ。
2. 前記コマンドから作成された学習データは、
   前記正常な通信データ群の通信パケットから時系列のコマンド、および、前記不正な通信データ群の通信パケットから時系列のコマンドを抜き出して作成される
   ことを特徴とする請求項１に記載の通信装置保護管理サーバ。
3. 前記通信装置保護管理サーバ上で動作する仮想マシンであって、前記通信装置をシミュレートする仮想マシンの上で動作する前記通信データの処理プログラムに、前記通信装置に対する通信データ群を処理させて、前記処理プログラムが送信するハートビートの種別と送信間隔とが、前記正常な通信データ群を処理するときの前記ハートビートの種別と送信間隔と異なる場合に、前記処理プログラムが処理する通信データ群を不正と判断する通信データ検査部を備え、
   前記攻撃判定学習部は、前記通信データ検査部が不正と判断した通信データ群から前記学習データを作成する
   ことを特徴とする請求項１または請求項２に記載の通信装置保護管理サーバ。
4. 前記通信装置保護管理サーバ上で動作する仮想マシンであって、前記通信装置をシミュレートする仮想マシンの上で動作する前記通信データの処理プログラムに、前記不正な通信データ群に含まれる通信データの処理を１ステップずつ実行させて、所定の不正なデータ操作を実行するステップを検出し、検出されたステップの直前に、前記不正なデータ操作の対象となるデータを検出して例外処理を実行するコードを前記処理プログラムに挿入する修正プログラムを生成するパッチ生成部を備える
   ことを特徴とする請求項１〜３の何れか１項に記載の通信装置保護管理サーバ。
5. 通信装置と通信装置保護管理サーバから構成される通信装置保護システムであって、
   前記通信装置保護管理サーバは、
   前記通信装置に対する正常な通信データ群に含まれる通信データおよび不正な通信データ群に含まれる通信データから、前記通信装置に対するコマンドおよび前記コマンドのパラメータの何れか１つまたは双方を抜き出して作成した学習データを用いて教師ありの学習をさせることで、前記通信装置に対する通信データが正常か不正かを判定する攻撃判定モデルを生成して、前記攻撃判定モデルのパラメータを前記通信装置に送信する攻撃判定学習部を備え、
   前記通信装置は、
   前記攻撃判定モデルのパラメータを自身の攻撃判定モデルに設定して、自身が受信した通信データを前記自身の攻撃判定モデルが不正と判定した場合には、当該通信データを破棄する、または、当該通信データを送信した通信装置からの通信データを破棄する通信データ監視部を備える
   ことを特徴とする通信装置保護システム。

Images