JP7052602B2 - 生成装置、生成方法及び生成プログラム - Google Patents

Description

本発明は、生成装置、生成方法及び生成プログラムに関する。

ＰＣ（Personal Computer）等の機器におけるマルウェア感染等による異常を検知する方法として、機器の挙動パターンと既知の異常パターンを比較して異常を検知するブラックリスト方式と、機器の挙動パターンと正常状態の挙動パターンを比較して異常を検知するホワイトリスト方式とが従来から実用化されている。

また、システム負荷情報を基に異常判定を行い、異常が発生した機器で実行されている機能を特定しブラックリストに登録する一方、異常が発生していない機器で実行されている機能をホワイトリストに登録する技術が知られている。

特開２０１７－８４２９６号公報

しかしながら、従来の技術には、異常原因の特定を効率的に行うことができない場合があるという問題がある。例えば、ブラックリスト方式では予め異常パターンが定められているため、定められた異常パターンと合致した場合に異常原因を特定可能であるが、未知マルウェア等による異常の検知は困難である。一方、ホワイトリスト方式では正常状態と合致しない挙動パターンは全て異常として検知可能であるが、異常原因の特定は困難である。

また、異常が発生した機器で実行されている機能を特定しブラックリストに登録し、異常が発生していない機器で実行されている機能をホワイトリストに登録する技術では、異常動作をしている機能を特定できるに過ぎず、異常原因を特定することは困難である。

上述した課題を解決し、目的を達成するために、本発明の生成装置は、ネットワークにおける通信に関する複数の項目を持つ情報を基に、前記ネットワークの異常を検知する検知部と、前記検知部によって異常が検知された場合、前記情報のそれぞれに対応する異常原因を特定する特定部と、前記情報が持つ項目の値と、前記特定部によって特定された異常原因とを基に、前記情報の所定の集合ごとの異常原因のパターンを生成するパターン生成部と、を有することを特徴とする。

本発明によれば、異常原因の特定を効率的に行うことができる。

図１は、第１の実施形態に係る生成システムの構成の一例を示す図である。 図２は、第１の実施形態に係る生成装置の構成の一例を示す図である。 図３は、第１の実施形態に係るＲｏｗ情報の一例を示す図である。 図４は、第１の実施形態に係るインシデントパターンの生成について説明するための図である。 図５は、第１の実施形態に係るインシデントパターンの判定について説明するための図である。 図６は、第１の実施形態に係るインシデントパターンの要素の一例を示す図である。 図７は、第１の実施形態に係る生成装置の初期設定フェーズにおける処理の流れを示すフローチャートである。 図８は、第１の実施形態に係る生成装置の運用フェーズにおける処理の流れを示すフローチャートである。 図９は、第１の実施形態に係るインシデントパターンを生成する処理の流れを示すフローチャートである。 図１０は、生成プログラムを実行するコンピュータの一例を示す図である。

以下に、本願に係る生成装置、生成方法及び生成プログラムの実施形態を図面に基づいて詳細に説明する。なお、本発明は、以下に説明する実施形態により限定されるものではない。

［第１の実施形態の構成］
まず、図１を用いて、第１の実施形態に係る生成システムの構成について説明する。図１は、第１の実施形態に係る生成システムの構成の一例を示す図である。図１に示すように、生成システム１は、生成装置１０、ゲートウェイ装置２０及び機器３０を有する。また、生成装置１０及びゲートウェイ装置２０は、ネットワーク２を介して通信可能に接続されている。また、機器３０は、ゲートウェイ装置２０と通信可能に接続されている。

例えば、機器３０は、ＰＣ、スマートフォン等の端末装置である。ネットワーク２は、例えばインターネットである。また、ゲートウェイ装置２０は、機器３０と同一のＬＡＮ（Local Area Network）に接続され、機器３０によって行われた通信の通信ログ又は機器３０の動作ログをキャプチャする。また、生成装置１０は、ネットワーク２における通信に関する情報を取得し、異常の検知及び異常原因の特定を行う。以降の説明では、通信に関する情報を通信特徴量と表記する場合がある。

生成装置１０が取得する通信特徴量には、例えば、通信におけるデータの送信元又は宛先のアドレス及びポート番号が含まれる。また、通信特徴量には、通信の継続時間及びバイト数が含まれていてもよい。

図２を用いて、第１の実施形態に係る生成装置の構成について説明する。図２は、第１の実施形態に係る生成装置の構成の一例を示す図である。図２に示すように、生成装置１０は、通信部１１、入力部１２、出力部１３、記憶部１４及び制御部１５を有する。

通信部１１は、ネットワークを介して、他の装置との間でデータ通信を行う。例えば、通信部１１はＮＩＣ（Network Interface Card）である。入力部１２は、ユーザからのデータの入力を受け付ける。入力部１２は、例えば、マウスやキーボード等の入力装置である。出力部１３は、画面の表示等により、データを出力する。出力部１３は、例えば、ディスプレイ等の表示装置である。

また、入力部１２及び出力部１３は、それぞれ、入力インタフェース及び出力インタフェースであってもよい。例えば、入力部１２及び出力部１３は、生成装置１０に接続された他の装置及びメモリカードやＵＳＢ（Universal Serial Bus）メモリ等のメディアとの間でデータの入力及び出力を行う。また、入力部１２は、通信部１１が受信したデータを入力データとして受け付けてもよい。また、出力部１３は、通信部１１に対してデータを出力してもよい。

記憶部１４は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、光ディスク等の記憶装置である。なお、記憶部１４は、ＲＡＭ（Random Access Memory）、フラッシュメモリ、ＮＶＳＲＡＭ（Non Volatile Static Random Access Memory）等のデータを書き換え可能な半導体メモリであってもよい。記憶部１４は、生成装置１０で実行されるＯＳ（Operating System）や各種プログラムを記憶する。さらに、記憶部１４は、プログラムの実行で用いられる各種情報を記憶する。また、記憶部１４は、検知モデル１４１、特定モデル１４２及び異常原因ＤＢ１４３を記憶する。

検知モデル１４１は、ネットワーク２の異常を検知するためのモデルである。検知モデル１４１は、機器３０が異常状態であることを検知するためのモデルであってもよい。例えば、検知モデル１４１は、セキュリティ製品（ＩＰＳ（Intrusion Prevention System），ＩＤＳ（Intrusion Detection and Prevention），ＷＡＦ（Web Application Firewall）等）のシグネチャを利用して検知することや、通信特徴量からアノマリスコアを計算する関数及びパラメータを含む。

特定モデル１４２は、機器３０の異常原因を特定するためのモデルである。例えば、セキュリティ製品（ＩＰＳ，ＩＤＳ，ＷＡＦ等）のシグネチャや、異常原因及び異常原因を特定するための通信特徴量が記載された機械学習の学習済みのモデルである。

異常原因ＤＢ１４３は、異常原因を特定するための情報を記憶する。異常原因ＤＢ１４３は、特定モデル１４２による異常原因の特定に用いられるデータ及び後述するインシデントパターンを記憶する。

例えば、異常原因ＤＢ１４３は、図３に示すＲｏｗ情報を含む情報を記憶する。図３は、第１の実施形態に係るＲｏｗ情報の一例を示す図である。図３に示すように、Ｒｏｗ情報には、発アドレス、着アドレス、発ポート、着ポート、継続時間、プロトコル、登りバイト数、下りバイト数、通信タイプが含まれる。例えば、Ｒｏｗ情報は、通信特徴量に含まれるデータそのものである。なお、Ｒｏｗ情報は、ネットワーク２における通信に関する複数の項目を持つ情報の一例である。

また、異常原因ＤＢ１４３は、Ｒｏｗ情報のそれぞれに対応する異常原因であるＩＤＳシグネチャを記憶する。ＩＤＳシグネチャは、生成装置１０が、特定モデル１４２を用いてＲｏｗ情報を基に生成したものであってもよいし、他の装置等から取得したものであってもよい。例えば、ＩＤＳシグネチャは、ＩＰアドレスがインターナルネットワークのものであるか外部のものであるかを、構成管理情報を基に特定した情報である。また、例えば、ＩＤＳシグネチャは、脅威のあるＩＰアドレスを記したブラックリストＤＢから取得した情報である。

さらに、異常原因ＤＢ１４３は、環境の変化等で変化しない項目の値から生成されたメタ情報を記憶する。例えば、同じマルウェアが複数のサイトに感染する場合を考える。このとき、感染の拡大又はマルウェアの駆除等の影響で、感染端末があるローカルの情報は変化することが考えられる。一方で、同じマルウェアであれば、アクセスする先は頻繁には変化しないことが考えられる。例えば、図３の（２）、（３）及び（４）では、感染した端末11．11．11．1から11．11．11．2～4へのログインが試行されている。このような場合、感染した端末のＩＰアドレスや、ログインを試みる端末はマルウェアの入り込んだ環境に依存しており、同じでないことが多い。一方で、（７）及び（８）では、感染した端末は、端末99．99．99．3からマルウェアをダウンロードしている。このような場合、感染した端末は環境依存だが、マルウェアのダウンロード先のＵＲＬやＩＰアドレスは同じアドレスになることが多い。このように、アドレスの分類によって、ＩＰアドレス自体に意味があるかが変化することが知られている。

また、異常原因ＤＢ１４３は、フロー単位のインシデントパターンを記憶する。ここで、図３の（１）～（１０）をフロー単位のＲｏｗ情報であるとする。このとき、例えば、異常原因ＤＢ１４３は、（１）～（１０）のＲｏｗ情報に対応して一意に生成されるインシデントパターンを記憶する。なお、インシデントパターンは、後述するパターン生成部１５５によって生成される。

制御部１５は、生成装置１０全体を制御する。制御部１５は、例えば、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＴＰＵ（Tensor Processing Unit）、ＭＰＵ（Micro Processing Unit）等の電子回路や、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等の集積回路である。また、制御部１５は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、内部メモリを用いて各処理を実行する。また、制御部１５は、各種のプログラムが動作することにより各種の処理部として機能する。例えば、制御部１５は、検知モデル生成部１５１、検知部１５２、特定モデル生成部１５３、特定部１５４、パターン生成部１５５及び判定部１５６を有する。

検知モデル生成部１５１は、ネットワーク２の正常動作時の通信に関する情報を基に、ネットワーク２の異常を検知するための検知モデル１４１を生成する。例えば、検知モデル生成部１５１は、検知モデル１４１が、入力された検知対象のデータと正常データとが類似していないほど高いアノマリスコアを出力するように学習を行う。

検知部１５２は、ネットワーク２における通信に関する複数の項目を持つ情報を基に、ネットワーク２の異常を検知する。例えば、検知部１５２は、検知対象の情報を基に、検知モデル１４１を用いてネットワーク２の異常を検知する。ここで、検知対象の情報は、Ｒｏｗ情報であってもよい。

例えば、検知部１５２は、検知対象の情報を検知モデル１４１に入力し、検知モデル１４１によって出力されたアノマリスコアが閾値以上である場合、ネットワーク２の異常を検知する。また、検知モデル１４１がシグネチャである場合は、検知部１５２は、シグネチャマッチングにより異常を検知することができる。また、図３に示すように、検知部１５２は、異常を検知した際のメタ情報を、ＩＤＳシグネチャとして異常原因ＤＢ１４３に格納する。例えば、前述のセキュリティ製品又は検知モデル１４１は、フローごとに、検知した異常を分類することができる。検知部１５２は、そのような分類をＩＤＳシグネチャとすることができる。

特定モデル生成部１５３は、ネットワーク２の通信に関する情報を基に、ネットワーク２の異常原因を特定するための特定モデル１４２を生成する。例えば、特定モデル生成部１５３は、異常原因ＤＢ１４３を基に、特定モデル１４２が、入力された通信特徴量と類似する通信特徴量に対応付けられた異常原因を出力するように学習を行う。

特定部１５４は、検知部１５２によって異常が検知された場合、情報のそれぞれに対応する異常原因を特定する。例えば、特定部１５４は、検知部１５２によって異常が検知された場合、特定モデル１４２を用いて、検知対象の情報のそれぞれに対応する異常原因を特定する。例えば、特定部１５４は、検知部１５２によって異常が検知された場合、検知対象の情報を特定モデル１４２に入力し、特定モデル１４２によって出力された異常原因を取得する。また、特定モデル１４２がシグネチャである場合は、特定部１５４は、シグネチャマッチングにより異常原因を特定することができる。

パターン生成部１５５は、通信特徴量が持つ項目の値と、特定部１５４によって特定された異常原因とを基に、通信特徴量の所定の集合ごとの異常原因のパターンを生成する。このとき、パターン生成部１５５は、情報が持つ項目の値から生成されたメタ情報を基にパターンを生成してもよい。また、パターン生成部１５５は、検知対象の情報のフロー単位の集合ごとの異常原因のパターンを生成することができる。以降の説明では、パターン生成部１５５によって生成されるパターンをインシデントパターンと表記する場合がある。

ここで、図４を用いて、インシデントパターンの生成について説明する。図４は、第１の実施形態に係るインシデントパターンの生成について説明するための図である。図４は、フローに含まれる通信の内容を模式的に表したものである。

図４の（１）は、機器３０が、Ｃ２サーバであるＣ２－１に対してｈｔｔｐによる通信を行ったことを示している。また、（２）～（４）は、機器３０のうちの１つが、他の機器３０に対してｔｅｌｎｅｔによるログインの試みを行ったことを示している。また、（５）及び（６）は、機器３０が、Ｃ２サーバであるＣ２－２との間でｔｅｌｎｅｔによる通信を行ったことを示している。また、（７）及び（８）は、機器３０が、マルウェア配信サイトを提供する配布サーバとの間でｈｔｔｐによる通信を行ったことを示している。また、（９）及び（１０）は、機器３０が、一般ＷｅｂサーバであるＴａｅｇｅｔとの間でｈｔｔｐによる通信を行ったことを示している。

ここで、検知部１５２が、図４に示すフローに含まれる通信が行われた際の通信特徴量を基に異常を検知したものとする。このとき、特定部１５４は、（１）～（１０）の通信に対応する通信特徴量のそれぞれについて、異常原因を特定する。

そして、図３に示すように、パターン生成部１５５は、通信特徴量及び特定された異常原因を収集し、Ｒｏｗ情報及びＩＤＳシグネチャとして異常原因ＤＢ１４３に格納する。さらに、パターン生成部１５５は、所定の情報を基にメタ情報を生成する。

ここで、例えば、図３の（１）のＩＤＳシグネチャ、発アドレス分類及び着アドレス分類は、それぞれ「Ｃ２通信」、「網内アドレス」及び「Ｃ２サーバ」である。また、（２）及び（３）のＩＤＳシグネチャ、発アドレス分類及び着アドレス分類は、それぞれ「ログイン試行／成功」、「網内アドレス」及び「網内アドレス」である。また、（４）のＩＤＳシグネチャ、発アドレス分類及び着アドレス分類は、それぞれ「ログイン試行／失敗」、「網内アドレス」及び「網内アドレス」である。これにより、パターン生成部１５５は、（１）～（４）を、Ｃ２サーバの指示によるスキャン（Ｃ２－Ｓｃａｎ）によるものと判定する。

同様に、パターン生成部１５５は、（５）～（８）を、Ｃ２サーバの指示によるダウンロード（Ｃ２－Ｄｏｗｎｌｏａｄ）によるものと判定する。また、パターン生成部１５５は、（９）及び（１０）を、Ｃ２サーバの指示によるＤｏｓ攻撃（Ｃ２－Ｄｏｓ）によるものと判定する。

パターン生成部１５５は、情報が持つ項目の値から生成されたメタ情報を基に、情報に対応するフローごとの異常原因の組み合わせを表すパターンであって、各異常原因に対応するフローの数が複数であることを表現可能なパターンを生成する。例えば、パターン生成部１５５は、「Ｃ２－Ｓｃａｎ＊ Ｃ２－Ｄｏｗｎｌｏａｄ Ｃ２－Ｄｏｓ＊」というインシデントパターンを生成する。

ここで、「＊」は、複数のフローが存在することを示している。例えば、Ｃ２によるスキャンでは、スキャンするポート数やネットワークに存在する機器の台数によりフローが変化することがある。また、ＤｏＳ攻撃では、発生するＨＴＴＰフローの数は、機器の性能等により一定ではない。このため、インシデントパターンにおいてフローの数を限定してしまうと、同様のインシデントパターンが存在したとしても、フローの数の違いにより比較及び検索ができないことが考えられる。そこで、パターン生成部１５５は、インシデントパターンの比較及び検索を容易にするため、複数のフローを束ね抽象化したインシデントパターンを生成する。なお、「Ｃ２－Ｓｃａｎ＊ Ｃ２－Ｄｏｗｎｌｏａｄ Ｃ２－Ｄｏｓ＊」は、「複数の送信元からのスキャンが発生した後、Ｃ２サーバからのダウンロードが行われ、複数の送信元からのＤｏｓ攻撃が始まった」ということを意味している。なお、「＊」は、１を含む任意の数のフローが存在することを示すものであってもよい。

判定部１５６は、パターン生成部１５５によって生成されたパターンを記憶する記憶部１４を参照し、パターン生成部１５５が第１のパターンを生成した場合、第１のパターンと記憶部１４に記憶されたパターンとが一致するか否かを判定する。つまり、判定部１５６は、パターン生成部１５５によって新たに生成されたインシデントパターンが、過去に生成されたインシデントパターンと一致するか否かを判定することができる。

図５は、第１の実施形態に係るインシデントパターンの判定について説明するための図である。図５の（１１）は、機器３０が、Ｃ２サーバであるＣ２－３に対してｈｔｔｐによる通信を行ったことを示している。また、（１２）は、機器３０のうちの１つが、他の機器３０に対してｔｅｌｎｅｔによるログインの試みを行ったことを示している。また、（１３）は、機器３０が、Ｃ２サーバであるＣ２－４との間でｔｅｌｎｅｔによる通信を行ったことを示している。また、（１４）は、機器３０が、マルウェア配信サイトを提供するＷｅｂｓｅｒｖｅｒ２との間でｈｔｔｐによる通信を行ったことを示している。また、（１６）は、機器３０が、一般ＷｅｂサーバであるＴａｅｇｅｔ２との間でｈｔｔｐによる通信を行ったことを示している。

図４と図５を比較すると、ログインを試みられた機器３０の数、Ｃ２サーバやマルウェア配信サイトを提供するサーバが異なる。一方で、「任意の送信元からのスキャンが発生した」こと、「Ｃ２サーバからのダウンロードが行われた」こと等は共通している。このため、パターン生成部１５５は、図５の例からも、図４の例からと同様に、「Ｃ２－Ｓｃａｎ＊ Ｃ２－Ｄｏｗｎｌｏａｄ Ｃ２－Ｄｏｓ＊」というインシデントパターンを生成する。このため、判定部１５６は、図５の例から生成されたインシデントパターンが、過去に図４の例から生成されたインシデントパターンと一致するものであると判定することができる。

ここで、パターン生成部１５５は、図６に示すような情報を参照することで、「Ｃ２－Ｓｃａｎ」、「Ｃ２－Ｄｏｗｎｌｏａｄ」、「Ｃ２－Ｄｏｓ」といったインシデントパターンの要素を判定することができる。図６は、第１の実施形態に係るインシデントパターンの要素の一例を示す図である。例えば、図６の（ｂ）は、「Ｃ２－Ｓｃａｎ＊」というパターンが、Ｃ２との通信後に複数回のＳｃａｎが発生するものであることを示している。また、図６の（ｃ）は、「Ｃ２－Ｕｐｌｏａｄ」というパターンが、Ｃ２との通信後にＵｐｌｏａｄが発生するものであることを示している。

また、出力部１３は、検知対象の通信特徴量及び異常原因を出力する。このとき、出力部１３は、パターン生成部１５５によって生成されたインシデントパターンを異常原因に含めて出力する。ここで、出力部１３によって出力された情報に対しては、インシデントレスポンスが行われる。例えば、インシデントレスポンスは、システムの管理者が出力部１３によって出力された情報を参考に、異常原因を特定することである。そして、入力部１２は、インシデントレスポンスによって特定された異常原因の入力を受け付ける。インシデントレスポンスによって特定される異常原因は、インシデントパターンと同様のデータ形式で表されていてもよい。

ここで、生成装置１０が特定した異常原因と、インシデントレスポンスによって特定された異常原因とが同一である場合と同一でない場合とが考えられる。このとき、生成装置１０は、インシデントレスポンスによって特定された異常原因を優先して異常原因ＤＢ１４３に格納する。

そして、特定モデル生成部１５３は、さらに特定モデル１４２の生成を行う。これにより、生成装置１０は、インシデントレスポンスの結果を特定モデル１４２に反映させることができる。

［第１の実施形態の処理］
図７及び８を用いて、生成装置１０の処理の流れを説明する。生成装置１０の処理は、大きく初期設定フェーズと運用フェーズに分けられる。初期設定フェーズにおいて、生成装置１０は、主に収集又は初期学習を行う。また、運用フェーズにおいて、生成装置１０は、主に機器の異常検知及び異常原因の特定を行う。また、検知モデル１４１及び特定モデル１４２は、通信特徴量だけでなく、機器３０の動作ログを用いた異常の検知及び異常原因の特定を行うことができるものとする。また、動作ログは、通信特徴量と同様に異常原因ＤＢ１４３に記憶されるものとする。

図７は、第１の実施形態に係る生成装置の初期設定フェーズにおける処理の流れを示すフローチャートである。図８に示すように、まず、特定モデル生成部１５３は、異常原因ＤＢ１４３に異常原因の通信特徴量又は動作ログが存在するか否かを確認する（ステップＳ１０１）。

ここで、異常原因ＤＢ１４３に異常原因の通信特徴量又は動作ログが存在する場合（ステップＳ１０１、Ｙｅｓ）、特定モデル生成部１５３は、異常原因の収集又は初期学習を行い、特定モデル１４２を生成する（ステップＳ１０２）。一方、異常原因ＤＢ１４３に異常原因の通信特徴量又は動作ログが存在しない場合（ステップＳ１０１、Ｎｏ）、特定モデル生成部１５３は、異常原因の収集又は初期学習を行わない。このように、特定モデル生成部１５３は、異常原因ＤＢ１４３に異常原因と通信特徴量又は動作ログとが記憶されている場合にのみ特定モデル１４２を生成することとしてもよい。

次に、検知モデル生成部１５１は、機器の正常動作時の通信特徴量又は動作ログを基に、正常動作の収集又は初期学習を行い、検知モデル１４１を生成する（ステップＳ１０３）。なお、例えば、初期学習は、正常データ又は異常原因ＤＢ１４３に記憶された異常原因と通信特徴量又は動作ログとを基に、検知モデル１４１又は特定モデル１４２を新規生成する処理である。これに対して、例えば、再学習は、異常原因ＤＢ１４３に記憶された異常原因と通信特徴量又は動作ログとであって、初期学習の際に記憶されていなかった異常原因と通信特徴量又は動作ログとを基に、特定モデル１４２を更新する処理である。

図８は、第１の実施形態に係る生成装置の運用フェーズにおける処理の流れを示すフローチャートである。図８に示すように、まず、検知部１５２は、検知対象の機器３０の通信特徴量又は動作ログを取得する（ステップＳ２０１）。次に、検知部１５２は、取得した通信特徴量又は動作ログを検知モデル１４１に入力する（ステップＳ２０２）。ここで、検知部１５２によって異常が検知されなかった場合（ステップＳ２０２、Ｎｏ）、処理がステップＳ２０１に戻され、検知部１５２は、次の検知対象の機器３０の通信特徴量又は動作ログを取得する（ステップＳ２０１）。

一方、検知部１５２によって異常が検知された場合（ステップＳ２０２、Ｙｅｓ）、特定部１５４は、検知対象の機器３０の通信特徴量又は動作ログを特定モデル１４２に入力し、異常原因を特定する（ステップＳ２０３）。なお、異常原因の特定処理については、後に図９を用いて説明する。

そして、出力部１３は、検知対象の機器３０の通信特徴量又は動作ログと特定部１５４によって特定された異常原因を出力する（ステップＳ２０４）。そして、入力部１２は、インシデントレスポンス結果の入力を受け付ける（ステップＳ２０５）。

ここで、特定部１５４が特定した異常原因とインシデントレスポンス結果の異常原因が同一である場合（ステップＳ２０６、Ｙｅｓ）、処理がステップＳ２０１に戻され、検知部１５２は、次の検知対象の機器３０の通信特徴量及び動作ログを取得する（ステップＳ２０１）。

一方、特定部１５４が特定した異常原因とインシデントレスポンス結果の異常原因が同一でない場合（ステップＳ２０６、Ｎｏ）、特定モデル生成部１５３は、インシデントレスポンス結果の異常原因を検知対象の機器３０の通信特徴量又は動作ログとともに異常原因ＤＢ１４３に格納する（ステップＳ２０７）。

ここで、初期設定フェーズにおける異常原因の収集又は初期学習（図７のステップＳ１０２）が実行済みである場合（ステップＳ２０８、Ｙｅｓ）、特定モデル生成部１５３は、異常原因ＤＢ１４３から異常原因と通信特徴量又は動作ログとを取得し、異常原因の収集又は再学習を行う（ステップＳ２０９）。

一方、初期設定フェーズにおける異常原因の初期学習（図７のステップＳ１０２）が実行済みでない場合（ステップＳ２０８、Ｎｏ）、特定モデル生成部１５３は、異常原因ＤＢ１４３から異常原因と通信特徴量又は動作ログとを取得し、異常原因の収集又は初期学習を行う（ステップＳ２１０）。

異常原因の収集又は再学習（ステップＳ２０９）もしくは収集又は初期学習（ステップＳ２１０）が行われると、処理がステップＳ２０１に戻され、検知部１５２は、次の検知対象の機器３０の通信特徴量又は動作ログを取得する（ステップＳ２０１）。

図９を用いて、異常原因を特定する処理（図８のステップＳ２０３）について説明する。ここでは、生成装置１０は、異常原因として、各通信特徴量の個別の異常原因と、インシデントパターンとを特定するものとする。図９は、第１の実施形態に係るインシデントパターンを生成する処理の流れを示すフローチャートである。

図９に示すように、まず、特定部１５４は、特定モデル１４２を用いて、各通信特徴量の個別の異常原因を特定する（ステップＳ３０１）。例えば、特定部１５４は、図３に示すＩＤＳシグネチャを特定する。

次に、パターン生成部１５５は、検知対象の情報からＲｏｗ情報を収集し（ステップＳ３０２）、インシデントパターンを生成する（ステップＳ３０３）。さらに、判定部１５６は、パターン生成部１５５によって生成されたインシデントパターンが、過去に生成されたインシデントパターンのそれぞれと同一であるか否かを判定する（ステップＳ３０４）。そして、特定部１５４は、判定部１５６によって同一であると判定されたインシデントパターンを、異常原因として特定する（ステップＳ３０５）。

［第１の実施形態の効果］
生成装置１０の検知部１５２は、ネットワーク２における通信に関する複数の項目を持つ情報を基に、ネットワーク２の異常を検知する。また、特定部１５４は、検知部１５２によって異常が検知された場合、情報のそれぞれに対応する異常原因を特定する。また、パターン生成部１５５は、情報が持つ項目の値と、特定部１５４によって特定された異常原因とを基に、情報の所定の集合ごとの異常原因のパターンを生成する。このように、生成装置１０は、異常が検知された場合、所定の集合ごとのインシデントパターンを生成することができる。この結果、生成装置１０によれば、異常原因の特定を効率的に行うことが可能になる。

例えば、生成装置１０によって生成されたインシデントパターンは、システム管理者によるインシデントレスポンスの作成に役立つ。例えば、インシデントパターンが作成されず、通信特徴量ごとに特定された異常原因がシステム管理者に提供される場合を考える。このとき、システム管理者は、提供された異常原因を基に、過去に作成されたインシデントレスポンスの説明や対処法が記載されたレポートを検索する。ここで、提供された異常原因に、重複や検索に寄与しないものが含まれている場合、システム管理者はレポートの検索を効率的に行うことができない。

例えば、図３の（１）～（４）のＩＤＳシグネチャに基づいて、「Ｃ２通信」、「ログイン試行」、「ログイン試行」、「ログイン試行」という一連の異常原因がシステム管理者に提供されたとする。このとき、過去に「Ｃ２通信」、「ログイン試行」、「ログイン試行」、「ログイン試行」という一連の異常原因が存在せず、「Ｃ２通信」、「ログイン試行」、「ログイン試行」という一連の異常原因のみが存在していたとする。この場合、システム管理者は、提供された一連の異常原因に完全一致するものを検索することができない。一方、生成装置１０によれば、前述の一連の異常原因をいずれも同一のインシデントパターンとして提供することができる。このように、生成装置１０は、システム管理者によるインシデントレスポンスを支援することができる。

パターン生成部１５５は、情報が持つ項目の値から生成されたメタ情報を基に、情報に対応するフローごとの異常原因の組み合わせを表すパターンであって、各異常原因に対応するフローの数が複数であることを表現可能なパターンを生成する。これにより、生成装置１０は、フローの数が抽象化されたインシデントパターンを生成することができる。特に、異常原因の組み合わせが共通していて、フローの数が異なるインシデントパターン同士の比較及び検索が容易になる。

判定部１５６は、パターン生成部１５５によって生成されたパターンを記憶する記憶部を参照し、パターン生成部１５５が第１のパターンを生成した場合、第１のパターンと記憶部に記憶されたパターンとが一致するか否かを判定する。これにより、生成装置１０は、過去に生成した同一のインシデントパターンの存在をシステム管理者に通知することができるため、インシデントレスポンスを支援することができる。

検知モデル生成部１５１は、ネットワーク２の正常動作時の通信に関する情報を基に、ネットワーク２の異常を検知するための検知モデル１４１を生成する。また、特定モデル生成部１５３は、ネットワーク２の通信に関する情報を基に、ネットワーク２の異常原因を特定するための特定モデル１４２を生成する。また、検知部１５２は、検知対象の情報を基に、検知モデル１４１を用いてネットワーク２の異常を検知する。また、特定部１５４は、検知部１５２によって異常が検知された場合、特定モデル１４２を用いて、検知対象の情報のそれぞれに対応する異常原因を特定する。また、パターン生成部１５５は、検知対象の情報のフロー単位の集合ごとの異常原因のパターンを生成する。このように、生成装置１０は、異常が検知された場合、フロー単位でインシデントパターンを生成することができる。この結果、生成装置１０は、システム管理者が解釈しやすいインシデントパターンを提供することができる。また、生成装置１０は、インシデントパターンを生成しつつ、各モデルを強化していくことができる。

［その他の実施形態］
生成システム１の装置構成は、図１のものに限られない。例えば、生成システム１は、検知モデル生成部１５１及び検知部１５２に相当する機能を備えた検知装置と、特定モデル生成部１５３及び特定部１５４に相当する機能を備えた生成装置とを有するものであってもよい。また、生成装置１０は、ゲートウェイ装置２０を経由せずに、直接機器３０の通信特徴量又は動作ログを取得してもよい。

また、これまでの説明における「通信特徴量又は動作ログ」は、「通信特徴量」、「動作ログ」又は「通信特徴量及び動作ログ」に置き換えてもよい。例えば、検知モデル１４１は、通信特徴量及び動作ログの両方から生成されたものであってもよい。また、例えば、異常原因ＤＢ１４３には、異常原因と動作ログが記憶されていてもよい。

例えば、検知モデル生成部１５１は、機器３０の正常動作時の動作ログを学習し、機器３０が異常状態であることを検知するための検知モデル１４１を生成する。特定モデル生成部１５３は、機器３０の異常原因ごとの通信特徴量を収集又は学習し、機器３０の異常原因を特定するための特定モデル１４２を生成する。検知部１５２は、検知モデル１４１と機器３０から取得した動作ログとを基に、機器３０が異常状態であることを検知する。特定部１５４は、検知部１５２によって機器３０が異常状態であることが検知された場合、特定モデル１４２と機器３０から取得した通信特徴量とを基に、機器３０の異常原因を特定する。

［システム構成等］
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［プログラム］
一実施形態として、生成装置１０は、パッケージソフトウェアやオンラインソフトウェアとして上記の異常検知処理及び異常原因の特定処理を実行する生成プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記の生成プログラムを情報処理装置に実行させることにより、情報処理装置を生成装置１０として機能させることができる。ここで言う情報処理装置には、デスクトップ型又はノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはサーバ機器、スマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）等の移動体通信端末、さらには、ＰＤＡ（Personal Digital Assistant）等のスレート端末等がその範疇に含まれる。

また、生成装置１０は、ユーザが使用する端末装置をクライアントとし、当該クライアントに上記の異常検知処理及び異常原因の特定処理に関するサービスを提供する特定サーバ装置として実装することもできる。例えば、特定サーバ装置は、機器の通信特徴量及び動作ログを入力とし、異常状態であるか否か及び異常状態であった場合の異常原因を出力とする特定サービスを提供するサーバ装置として実装される。この場合、特定サーバ装置は、Ｗｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の異常検知処理及び異常原因の特定処理に関するサービスを提供するクラウドとして実装することとしてもかまわない。

図１０は、生成プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。

ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、生成装置１０の各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、生成装置１０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤにより代替されてもよい。

また、上述した実施形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０は、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した実施形態の処理を実行する。

なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１ 生成システム
２ ネットワーク
１０ 生成装置
１１ 通信部
１２ 入力部
１３ 出力部
１４ 記憶部
１５ 制御部
２０ ゲートウェイ装置
３０ 機器
１４１ 検知モデル
１４２ 特定モデル
１４３ 異常原因ＤＢ
１５１ 検知モデル生成部
１５２ 検知部
１５３ 特定モデル生成部
１５４ 特定部
１５５ パターン生成部
１５６ 判定部

Claims (6)

1. ネットワークにおける通信に関する複数の項目を持つ情報を基に、前記ネットワークの異常を検知する検知部と、
   前記検知部によって異常が検知された場合、前記情報のそれぞれに対応する異常原因としてＩＤＳシグネチャを特定する特定部と、
   前記情報が持つ項目の値と、発アドレス分類及び着アドレス分類と、前記特定部によって特定された異常原因とを基に、前記情報の所定の集合ごとの異常原因のパターンを生成するパターン生成部と、
   を有することを特徴とする生成装置。
2. 前記パターン生成部は、前記情報が持つ項目の値から生成されたメタ情報を基に、前記情報に対応するフローごとの異常原因の組み合わせを表すパターンであって、各異常原因に対応するフローの数が複数であることを表現可能なパターンを生成することを特徴とする請求項１に記載の生成装置。
3. 前記パターン生成部によって生成されたパターンを記憶する記憶部を参照し、前記パターン生成部が第１のパターンを生成した場合、前記第１のパターンと前記記憶部に記憶されたパターンとが一致するか否かを判定する判定部をさらに有することを特徴とする請求項１に記載の生成装置。
4. ネットワークの正常動作時の通信に関する情報を基に、前記ネットワークの異常を検知するための検知モデルを生成する検知モデル生成部と、
   前記ネットワークの通信に関する情報を基に、前記ネットワークの異常原因を特定するための特定モデルを生成する特定モデル生成部と、
   をさらに有し、
   前記検知部は、検知対象の情報を基に、前記検知モデルを用いて前記ネットワークの異常を検知し、
   前記特定部は、前記検知部によって異常が検知された場合、前記特定モデルを用いて、前記検知対象の情報のそれぞれに対応する異常原因を特定し、
   前記パターン生成部は、前記検知対象の情報のフロー単位の集合ごとの異常原因のパターンを生成することを特徴とする請求項１に記載の生成装置。
5. コンピュータによって実行される生成方法であって、
   ネットワークにおける通信に関する複数の項目を持つ情報を基に、前記ネットワークの異常を検知する検知工程と、
   前記検知工程によって異常が検知された場合、前記情報のそれぞれに対応する異常原因としてＩＤＳシグネチャを特定する特定工程と、
   前記情報が持つ項目の値と、発アドレス分類及び着アドレス分類と、前記特定工程によって特定された異常原因とを基に、前記情報の所定の集合ごとの異常原因のパターンを生成するパターン生成工程と、
   を含むことを特徴とする生成方法。
6. コンピュータを、請求項１から４のいずれか１項に記載の生成装置として機能させるための生成プログラム。

Images