(57)【要約】【課題】未知の異常の検知と異常原因の特定を効率的に行う。【解決手段】第１の生成部１５１は、機器の正常動作時の通信特徴量又は動作ログを学習し、機器が異常状態であることを検知するための検知モデル１４１を生成する。第２の生成部１５３は、機器の異常原因ごとの通信特徴量又は動作ログを学習し、機器の異常原因を特定するための特定モデル１４２を生成する。検知部１５２は、検知モデル１４１と機器から取得した通信特徴量又は動作ログとを基に、機器が異常状態であることを検知する。特定部１５４は、検知部１５２によって機器が異常状態であることが検知された場合、特定モデル１４２と機器から取得した通信特徴量又は動作ログとを基に、機器の異常原因を特定する。【選択図】図２
2019103069.tif 000002
【特許請求の範囲】
【請求項１】
機器の正常動作時の通信特徴量又は動作ログを収集又は学習し、機器が異常状態であることを検知するための検知モデルを生成する第１の生成部と、
機器の異常原因ごとの通信特徴量又は動作ログを収集又は学習し、機器の異常原因を特定するための特定モデルを生成する第２の生成部と、
前記検知モデルと第１の機器から取得した通信特徴量又は動作ログとを基に、前記第１の機器が異常状態であることを検知する検知部と、
前記検知部によって前記第１の機器が異常状態であることが検知された場合、前記特定モデルと前記第１の機器から取得した通信特徴量又は動作ログとを基に、前記第１の機器の異常原因を特定する特定部と、
を有することを特徴とする特定システム。
【請求項２】
前記第１の機器から取得した通信特徴量又は動作ログと前記特定部によって特定された前記第１の機器の第１の異常原因とを出力する出力部と、
前記出力部によって出力された前記通信特徴量又は前記動作ログと前記第１の異常原因とに基づいて行われたインシデントレスポンスによって特定された第２の異常原因の入力を受け付ける入力部と、
前記第１の異常原因と前記第２の異常原因とが同一でない場合、前記第２の異常原因と前記通信特徴量又は前記動作ログとを対応付けて記憶部に格納する格納部と、
をさらに有し、
前記第２の生成部は、前記記憶部から取得した異常原因と通信特徴量又は動作ログとを学習することを特徴とする請求項１に記載の特定システム。
【請求項３】
前記第２の生成部は、前記記憶部に異常原因と通信特徴量又は動作ログとが記憶されている場合にのみ前記特定モデルを生成することを特徴とする請求項２に記載の特定システム。
【請求項４】
特定システムで実行される特定方法であって、
機器の正常動作時の通信特徴量又は動作ログを学習し、機器が異常状態であることを検知するための検知モデルを生成する第１の収集工程又は学習工程と、
機器の異常原因ごとの通信特徴量又は動作ログを収集又は学習し、機器の異常原因を特定するための特定モデルを生成する第２の収集工程又は学習工程と、
前記検知モデルと第１の機器から取得した通信特徴量又は動作ログとを基に、前記第１の機器が異常状態であることを検知する検知工程と、
前記検知工程によって前記第１の機器が異常状態であることが検知された場合、前記特定モデルと前記第１の機器から取得した通信特徴量又は動作ログとを基に、前記第１の機器の異常原因を特定する特定工程と、
を含んだことを特徴とする特定方法。
【請求項５】
コンピュータに、
機器の正常動作時の通信特徴量又は動作ログを学習し、機器が異常状態であることを検知するための検知モデルを生成する第１の生成ステップと、
機器の異常原因ごとの通信特徴量又は動作ログを収集又は学習し、機器の異常原因を特定するための特定モデルを生成する第２の生成ステップと、
前記検知モデルと第１の機器から取得した通信特徴量又は動作ログとを基に、前記第１の機器が異常状態であることを検知する検知ステップと、
前記検知ステップによって前記第１の機器が異常状態であることが検知された場合、前記特定モデルと前記第１の機器から取得した通信特徴量とを基に、前記第１の機器の異常原因を特定する特定ステップと、
を実行させることを特徴とする特定プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特定システム、特定方法及び特定プログラムに関する。
【背景技術】
【０００２】
ＰＣ（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）や各種プログラムを記憶する。さらに、記憶部１４は、プログラムの実行で用いられる各種情報を記憶する。また、記憶部１４は、検知モデル１４１、特定モデル１４２及び異常原因ＤＢ１４３を記憶する。
【００１８】
検知モデル１４１は、機器３０が異常状態であることを検知するためのモデルである。
例えば、検知モデル１４１は、通信特徴量又は動作ログからアノマリスコアを計算する関数及びパラメータを含む。
【００１９】
特定モデル１４２は、機器３０の異常原因を特定するためのモデルである。例えば、異常原因及び異常原因を特定するための通信特徴量又は動作ログが記載されたシグネチャファイルである。
【００２０】
異常原因ＤＢ１４３は、異常原因ごとの通信特徴量である。図３は、第１の実施形態に係る異常原因ＤＢのデータ構成の一例を示す図である。図３に示すように、例えば、異常原因ＤＢ１４３において、「マルウェアＡ」という異常原因には、通信特徴量として、送信元ＩＰアドレス「１９２．０．２．１０」、送信元ＭＡＣアドレス「００−００−５Ｅ−００−５３−１０」、送信先ＩＰアドレス「１９２．０．２．１５」、送信先ＭＡＣアドレス「００−００−５Ｅ−００−５３−１５」等が対応付けられている。また、異常原因ＤＢ１４３の通信特徴量又は動作ログは、図３に示すものに限られない。例えば、異常原因ＤＢ１４３の通信特徴量又は動作ログは、ネットワークパケットのキャプチャデータやペイロードのフロー情報、ＣＰＵ等のリソースや他のサーバにログインする際に使用するｔｅｌｎｅｔコマンド等のログ、フロー情報の組み合わせ、ネットワークインタフェース間を行き来するＩＰ（Internet  Protocol）トラフィックに関するフローログ、フローログの組み合わせ等を含んでいてもよい。
【００２１】
また、「ＤｏＳ攻撃」という異常原因には、通信特徴量として、送信元ＩＰアドレス「１９２．０．２．２０」、送信元ＭＡＣアドレス「００−００−５Ｅ−００−５３−２０」、送信先ＩＰアドレス「１０．１０．０．１５」、送信先ＭＡＣアドレス「００−００−５Ｅ−００−５３−２５」等が、動作ログとして、同一送信先ＩＰアドレスへの通信が増えていること等が対応付けられている。また、「ＤｏＳ攻撃」という異常原因には、通信特徴量として、送信元ＩＰアドレス「１９２．０．２．２１」、送信元ＭＡＣアドレス「００−００−５Ｅ−００−５３−２１」、送信先ＩＰアドレス「１０．２０．０．２５」、送信先ＭＡＣアドレス「００−００−５Ｅ−００−５３−２６」等が、動作ログとして、同一送信先ＩＰアドレスへの通信が増えていること等が対応付けられている。このように、異常原因ＤＢ１４３では、１つの異常原因に複数の異なる通信特徴量又は動作ログが対応付けられていてもよい。
【００２２】
制御部１５は、特定装置１０全体を制御する。制御部１５は、例えば、ＣＰＵ（Central  Processing  Unit）、ＧＰＵ（Graphics  Processing  Unit）、ＴＰＵ（Tensor  Processing  Unit）、ＭＰＵ（Micro  Processing  Unit）等の電子回路や、ＡＳＩＣ（Application  Specific  Integrated  Circuit）、ＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路である。また、制御部１５は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、内部メモリを用いて各処理を実行する。また、制御部１５は、各種のプログラムが動作することにより各種の処理部として機能する。例えば、制御部１５は、第１の生成部１５１、検知部１５２、第２の生成部１５３、特定部１５４及び格納部１５５を有する。
【００２３】
第１の生成部１５１は、機器３０の正常動作時の通信特徴量又は動作ログ（以降、正常データ）を学習し、機器３０が異常状態であることを検知するための検知モデル１４１を生成する。例えば、第１の生成部１５１は、検知モデル１４１が、入力された通信特徴量又は動作ログと正常データとが類似していないほど高いアノマリスコアを出力するように学習を行う、又は検知モデル１４１が、入力された通信特徴量又は動作ログと正常データの同一性判定結果を出力するように収集を行う。
【００２４】
第２の生成部１５３は、機器３０の異常原因ごとの通信特徴量を学習し、機器３０の異常原因を特定するための特定モデル１４２を生成する。例えば、第２の生成部１５３は、異常原因ＤＢ１４３を基に、特定モデル１４２が、入力された通信特徴量又は動作ログと類似する通信特徴量又は動作ログに対応付けられた異常原因を出力するように学習を行う、又は特定モデル１４２が、入力された通信特徴量又は動作ログと同一である通信特徴量又は動作ログに対応付けられた異常原因を出力するように収集を行う。
【００２５】
また、第２の生成部１５３は、異常原因ごとの通信特徴量の傾向を学習することができる。つまり、第２の生成部１５３は、特定モデル１４２に異常原因ＤＢ１４３に存在しない通信特徴量の組み合わせが入力された場合であっても、通信特徴量の傾向が類似する異常原因を出力できるようにすることができる。
【００２６】
検知部１５２は、検知モデル１４１と機器３０から取得した通信特徴量又は動作ログとを基に、機器３０が異常状態であることを検知する。例えば、検知部１５２は、検知対象の機器３０の通信特徴量又は動作ログを検知モデル１４１に入力し、検知モデル１４１によって出力されたアノマリスコアが閾値以上である場合、機器３０が異常状態であることを検知する。
【００２７】
特定部１５４は、検知部１５２によって機器３０が異常状態であることが検知された場合、特定モデル１４２と機器３０から取得した通信特徴量又は動作ログとを基に、機器３０の異常原因を特定する。例えば、特定部１５４は、検知部１５２によって異常状態であることが検知された機器３０の通信特徴量又は動作ログを特定モデル１４２に入力し、特定モデル１４２によって出力された異常原因を取得する。
【００２８】
また、出力部１３は、機器３０から取得した通信特徴量又は動作ログと特定部１５４によって特定された機器３０の第１の異常原因とを出力する。ここで、出力部１３によって出力された通信特徴量又は動作ログと第１の異常原因とに対しては、インシデントレスポンスが行われる。例えば、インシデントレスポンスは、システムの管理者が通信特徴量又は動作ログに基づいて異常原因を特定することである。そして、入力部１２は、出力部１３によって出力された通信特徴量又は動作ログと第１の異常原因とに基づいて行われたインシデントレスポンスによって特定された第２の異常原因の入力を受け付ける。
【００２９】
ここで、特定部１５４が特定した第１の異常原因と、インシデントレスポンスによって特定された第２の異常原因とが同一である場合と同一でない場合とが考えられる。格納部１５５は、第１の異常原因と第２の異常原因とが同一でない場合、第２の異常原因と通信特徴量とを対応付けて記憶部１４に格納する。
【００３０】
一方、格納部１５５は、第１の異常原因と第２の異常原因とが同一である場合、第１の異常原因と通信特徴量とを対応付けて記憶部１４に格納する。なお、この場合、格納部１５５は、第２の異常原因と通信特徴量とを対応付けて記憶部１４に格納してもよい。
【００３１】
そして、第２の生成部１５３は、記憶部１４から取得した異常原因と通信特徴量又は動作ログとを学習する、又は記憶部１４から取得した異常原因と通信特徴量又は動作ログとを収集する。これにより、特定装置１０は、インシデントレスポンスの結果を特定モデル１４２に反映させることができる。
【００３２】
例えば、検知対象の機器３０の通信特徴量として、送信元ＩＰアドレス「１９２．０．２．２２」、送信元ＭＡＣアドレス「００−００−５Ｅ−００−５３−２２」、送信先ＩＰアドレス「１９２．０．２．２７」、送信先ＭＡＣアドレス「００−００−５Ｅ−００−５３−２７」、通信プロトコル「ＵＤＰプロトコル」が特定装置１０に入力されたとする。また、この場合、当該機器３０が異常状態であることが検知部１５２によって検知されたこととする。
【００３３】
このとき、特定部１５４は、通信特徴量として、送信元ＩＰアドレス「１９２．０．２．２２」、送信元ＭＡＣアドレス「００−００−５Ｅ−００−５３−２２」、送信先ＩＰアドレス「１９２．０．２．２７」、送信先ＭＡＣアドレス「００−００−５Ｅ−００−５３−２７」、通信プロトコル「ＵＤＰプロトコル」を、特定モデル１４２に入力する。そして、特定モデル１４２は、入力された通信特徴量に対応する異常原因として、「ＤｏＳ攻撃」を出力したこととする。
【００３４】
ここで、出力部１３は、異常原因として「ＤｏＳ攻撃」を出力し、通信特徴量として、送信元ＩＰアドレス「１９２．０．２．２２」、送信元ＭＡＣアドレス「００−００−５Ｅ−００−５３−２２」、送信先ＩＰアドレス「１９２．０．２．２７」、送信先ＭＡＣアドレス「００−００−５Ｅ−００−５３−２７」、通信プロトコル「ＵＤＰプロトコル」を出力する。
【００３５】
その後、システム管理者は、出力部１３によって出力された通信特徴量と異常原因に基づいてインシデントレスポンスを行い、異常原因が「マルウェアＣ」であることを特定したとする。システム管理者は、インシデントレスポンスによって特定した異常原因「マルウェアＣ」を、入力部１２に入力する。
【００３６】
ここで、「ＤｏＳ攻撃」は、第１の異常原因である。また、「マルウェアＣ」は、第１の異常原因である。このように、第１の異常原因と第２の異常原因が同一でないため、格納部１５５は、第２の異常原因「マルウェアＣ」と通信特徴量とを対応付けて記憶部１４の異常原因ＤＢ１４３に格納する。
【００３７】
前記も含め、異常検知の方法として以下の例がある。「ＤｏＳ攻撃」の場合は同一の送信先ＩＰアドレスへの通信が増えていることや前記フロー情報に含まれるデータ量が少ないことから検知可能であり、「ブルートフォース攻撃」の場合は他のサーバにログインする際に使用するｔｅｌｎｅｔ通信やＳＳＨ通信を複数回行い、動作ログにおいて複数回ログイン失敗していることから検知可能であり、「ポートスキャン」の場合は正常時に通信していないポートにアクセスがあること、複数の送信先ＩＰアドレスの同一ポートにアクセスが繰り返されていること、同一の送信先ＩＰアドレスのあらゆるポートを順次アクセスしていることから検知可能である。また、「マルウェア」の場合は、マルウェアＭＩＲＡＩを例に挙げると、前記ｔｅｌｎｅｔ通信によりログイン成功した送信先ＩＰアドレスとログイン情報を外部のＣ＆Ｃ（Command  and  Control）サーバへ送信していること、前記Ｃ＆Ｃサーバから前記ｔｅｌｎｅｔ通信によりログインし悪意のあるプログラムを機器にダウンロードさせていること、前記Ｃ＆Ｃサーバから前記機器に命令し「ＤｏＳ攻撃」を行わせていることから検知可能である。
【００３８】
［第１の実施形態の処理］
図４及び５を用いて、特定装置１０の処理の流れを説明する。特定装置１０の処理は、大きく初期設定フェーズと運用フェーズに分けられる。初期設定フェーズにおいて、特定装置１０は、主に収集又は初期学習を行う。また、運用フェーズにおいて、特定装置１０は、主に機器の異常検知及び異常原因の特定を行う。
【００３９】
図４は、第１の実施形態に係る特定装置の初期設定フェーズにおける処理の流れを示すフローチャートである。図４に示すように、まず、第２の生成部１５３は、異常原因ＤＢ１４３に異常原因の通信特徴量又は動作ログが存在するか否かを確認する（ステップＳ１０１）。
【００４０】
ここで、異常原因ＤＢ１４３に異常原因の通信特徴量又は動作ログが存在する場合（ステップＳ１０１、Ｙｅｓ）第２の生成部１５３は、異常原因の収集又は初期学習を行い、特定モデル１４２を生成する（ステップＳ１０２）。一方、異常原因ＤＢ１４３に異常原因の通信特徴量又は動作ログが存在しない場合（ステップＳ１０１、Ｎｏ）第２の生成部１５３は、異常原因の収集又は初期学習を行わない。このように、第２の生成部１５３は、異常原因ＤＢ１４３に異常原因と通信特徴量又は動作ログとが記憶されている場合にのみ特定モデル１４２を生成することとしてもよい。
【００４１】
次に、第１の生成部１５１は、機器の正常動作時の通信特徴量又は動作ログを基に、正常動作の収集又は初期学習を行い、検知モデル１４１を生成する（ステップＳ１０３）。なお、例えば、初期学習は、正常データ又は異常原因ＤＢ１４３に記憶された異常原因と通信特徴量又は動作ログとを基に、検知モデル１４１又は特定モデル１４２を新規生成する処理である。これに対して、例えば、再学習は、異常原因ＤＢ１４３に記憶された異常原因と通信特徴量又は動作ログとであって、初期学習の際に記憶されていなかった異常原因と通信特徴量又は動作ログとを基に、特定モデル１４２を更新する処理である。
【００４２】
図５は、第１の実施形態に係る特定装置の運用フェーズにおける処理の流れを示すフローチャートである。図５に示すように、まず、検知部１５２は、検知対象の機器３０の通信特徴量又は動作ログを取得する（ステップＳ２０１）。次に、検知部１５２は、取得した通信特徴量又は動作ログを検知モデル１４１に入力する（ステップＳ２０２）。ここで、検知部１５２によって異常が検知されなかった場合（ステップＳ２０２、Ｎｏ）、処理がステップＳ２０１に戻され、検知部１５２は、次の検知対象の機器３０の通信特徴量又は動作ログを取得する（ステップＳ２０１）。
【００４３】
一方、検知部１５２によって異常が検知された場合（ステップＳ２０２、Ｙｅｓ）、特定部１５４は、検知対象の機器３０の通信特徴量又は動作ログを特定モデル１４２に入力し、異常原因を特定する（ステップＳ２０３）。そして、出力部１３は、検知対象の機器３０の通信特徴量又は動作ログと特定部１５４によって特定された異常原因を出力する（ステップＳ２０４）。そして、入力部１２は、インシデントレスポンス結果の入力を受け付ける（ステップＳ２０５）。
【００４４】
ここで、特定部１５４が特定した異常原因とインシデントレスポンス結果の異常原因が同一である場合（ステップＳ２０６、Ｙｅｓ）、処理がステップＳ２０１に戻され、検知部１５２は、次の検知対象の機器３０の通信特徴量及び動作ログを取得する（ステップＳ２０１）。
【００４５】
一方、特定部１５４が特定した異常原因とインシデントレスポンス結果の異常原因が同一でない場合（ステップＳ２０６、Ｎｏ）、格納部１５５は、インシデントレスポンス結果の異常原因を検知対象の機器３０の通信特徴量又は動作ログとともに異常原因ＤＢ１４３に格納する（ステップＳ２０７）。
【００４６】
ここで、初期設定フェーズにおける異常原因の収集又は初期学習（図４のステップＳ１０２）が実行済みである場合（ステップＳ２０８、Ｙｅｓ）、第２の生成部１５３は、異常原因ＤＢ１４３から異常原因と通信特徴量又は動作ログとを取得し、異常原因の収集又は再学習を行う（ステップＳ２０９）。
【００４７】
一方、初期設定フェーズにおける異常原因の初期学習（図４のステップＳ１０２）が実行済みでない場合（ステップＳ２０８、Ｎｏ）、第２の生成部１５３は、異常原因ＤＢ１４３から異常原因と通信特徴量又は動作ログとを取得し、異常原因の収集又は初期学習を行う（ステップＳ２１０）。
【００４８】
異常原因の収集又は再学習（ステップＳ２０９）もしくは収集又は初期学習（ステップＳ２１０）が行われると、処理がステップＳ２０１に戻され、検知部１５２は、次の検知対象の機器３０の通信特徴量又は動作ログを取得する（ステップＳ２０１）。
【００４９】
［第１の実施形態の効果］
第１の生成部１５１は、機器３０の正常動作時の通信特徴量又は動作ログを学習し、機器３０が異常状態であることを検知するための検知モデル１４１を生成する。第２の生成部１５３は、機器３０の異常原因ごとの通信特徴量又は動作ログを収集又は学習し、機器３０の異常原因を特定するための特定モデル１４２を生成する。検知部１５２は、検知モデル１４１と機器３０から取得した通信特徴量又は動作ログとを基に、機器３０が異常状態であることを検知する。特定部１５４は、検知部１５２によって機器３０が異常状態であることが検知された場合、特定モデル１４２と機器３０から取得した通信特徴量又は動作ログとを基に、機器３０の異常原因を特定する。
【００５０】
このように、特定システム１は、異常の検知及び異常原因の特定を両立可能なアーキテクチャを有する。例えば、特定システム１は、ホワイトリスト方式を利用した異常検知及びブラックリスト方式を利用した異常原因の特定の両方を行うことができる。また、特定装置１０は、異常が検知された場合にのみ異常原因の特定を行うことができるため、異常原因の特定に要する処理負荷を低減させることができる。このため、本実施形態によれば、未知の異常の検知と異常原因の特定を効率的に行うことができる。
【００５１】
出力部１３は、機器３０から取得した通信特徴量又は動作ログと特定部１５４によって特定された機器３０の第１の異常原因とを出力する。入力部１２は、出力部１３によって出力された通信特徴量又は動作ログと第１の異常原因とに基づいて行われたインシデントレスポンスによって特定された第２の異常原因の入力を受け付ける。格納部１５５は、第１の異常原因と第２の異常原因とが同一でない場合、第２の異常原因と通信特徴量又は動作ログとを対応付けて記憶部１４に格納する。第２の生成部１５３は、記憶部１４から取得した異常原因と通信特徴量又は動作ログとを収集又は学習する。
【００５２】
インシデントレスポンスにおいては、システム管理者等の知見及び既存の異常原因特定手法を用いた精度の高い異常原因の特定が行われることが考えられる。このため、本実施形態では、インシデントレスポンスの結果を異常原因の特定のためのモデルに反映させることで、特定システム１による異常原因の特定精度を向上させることができる。
【００５３】
第２の生成部１５３は、異常原因ＤＢ１４３に異常原因と通信特徴量又は動作ログとが記憶されている場合にのみ特定モデル１４２を生成することとしてもよい。これにより、特定システム１は、異常原因ＤＢ１４３に異常原因と通信特徴量又は動作ログとが記憶されていない場合であっても処理を開始することができる。
【００５４】
なお、この場合は、インシデントレスポンスによって特定された異常原因が異常原因ＤＢ１４３に格納され、当該異常原因に基づく学習が行われることで、特定システム１による異常原因の特定が可能となる。
【００５５】
［その他の実施形態］
特定システム１の装置構成は、図１のものに限られない。例えば、特定システム１は、第１の生成部１５１及び検知部１５２に相当する機能を備えた検知装置と、第２の生成部１５３及び特定部１５４に相当する機能を備えた特定装置とを有するものであってもよい。また、特定装置１０は、ゲートウェイ装置２０を経由せずに、直接機器３０の通信特徴量又は動作ログを取得してもよい。
【００５６】
また、これまでの説明における「通信特徴量又は動作ログ」は、「通信特徴量」、「動作ログ」又は「通信特徴量及び動作ログ」に置き換えてもよい。例えば、検知モデル１４１は、通信特徴量及び動作ログの両方から生成されたものであってもよい。また、例えば、異常原因ＤＢ１４３には、異常原因と動作ログが記憶されていてもよい。
【００５７】
例えば、第１の生成部１５１は、機器３０の正常動作時の動作ログを学習し、機器３０が異常状態であることを検知するための検知モデル１４１を生成する。第２の生成部１５３は、機器３０の異常原因ごとの通信特徴量を収集又は学習し、機器３０の異常原因を特定するための特定モデル１４２を生成する。検知部１５２は、検知モデル１４１と機器３０から取得した動作ログとを基に、機器３０が異常状態であることを検知する。特定部１５４は、検知部１５２によって機器３０が異常状態であることが検知された場合、特定モデル１４２と機器３０から取得した通信特徴量とを基に、機器３０の異常原因を特定する。
【００５８】
［システム構成等］
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【００５９】
また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【００６０】
［プログラム］
一実施形態として、特定装置１０は、パッケージソフトウェアやオンラインソフトウェアとして上記の異常検知処理及び異常原因の特定処理を実行する特定プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記の特定プログラムを情報処理装置に実行させることにより、情報処理装置を特定装置１０として機能させることができる。ここで言う情報処理装置には、デスクトップ型又はノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはサーバ機器、スマートフォン、携帯電話機やＰＨＳ（Personal  Handyphone  System）等の移動体通信端末、さらには、ＰＤＡ（Personal  Digital  Assistant）等のスレート端末等がその範疇に含まれる。
【００６１】
また、特定装置１０は、ユーザが使用する端末装置をクライアントとし、当該クライアントに上記の異常検知処理及び異常原因の特定処理に関するサービスを提供する特定サーバ装置として実装することもできる。例えば、特定サーバ装置は、機器の通信特徴量及び動作ログを入力とし、異常状態であるか否か及び異常状態であった場合の異常原因を出力とする特定サービスを提供するサーバ装置として実装される。この場合、特定サーバ装置は、Ｗｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の異常検知処理及び異常原因の特定処理に関するサービスを提供するクラウドとして実装することとしてもかまわない。
【００６２】
図６は、特定プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
【００６３】
メモリ１０１０は、ＲＯＭ（Read  Only  Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic  Input  Output  System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
【００６４】
ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、特定装置１０の各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、特定装置１０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤにより代替されてもよい。
【００６５】
また、上述した実施形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０は、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した実施形態の処理を実行する。
【００６６】
なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ、ＷＡＮ（Wide  Area  Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【符号の説明】
【００６７】
１  特定システム
２  ネットワーク
１０  特定装置
１１  通信部
１２  入力部
１３  出力部
１４  記憶部
１５  制御部
２０  ゲートウェイ装置
３０  機器
１４１  検知モデル
１４２  特定モデル
１４３  異常原因ＤＢ
１５１  第１の生成部
１５２  検知部
１５３  第２の生成部
１５４  特定部
１５５  格納部
【図１】
2019103069.tif 000003
【図２】
2019103069.tif 000004
【図３】
2019103069.tif 000005
【図４】
2019103069.tif 000006
【図５】
2019103069.tif 000007
【図６】
2019103069.tif 000008