JP2018133004A - 異常検知システム及び異常検知方法 - Google Patents

Abstract

【課題】マルウェア感染端末の特定を支援する。【解決手段】複数の端末と接続される異常検知システムであって、前記複数の端末を１以上のクラスタに分類するクラスタリング部と、前記クラスタリング部により分類されたクラスタ毎に、異常な端末が前記クラスタに属することを検知するための検知モデルを作成する検知モデル作成部と、前記複数の端末のうち、前記クラスタに属する各端末のトラヒック情報に基づいて、該クラスタの特徴量を示すクラスタ特徴量を生成する第１の特徴量生成部と、前記検知モデル作成部により作成された前記検知モデルと、前記第１の特徴量生成部により生成された前記クラスタ特徴量とに基づいて、異常な端末が前記クラスタに属することを検知する異常検知部と、を有する。【選択図】図１

Description

本発明は、異常検知システム及び異常検知方法に関する。

近年、マルウェアに感染した多数のＩｏＴ（Internet of Things）端末（以下、単に「端末」とも表す。）をＤＤｏＳ（Distributed Denial of Service attack）攻撃の踏み台にする事件が発生しており、標的となったサービスが利用不能になる等の被害が生じている。

また、ＩｏＴ端末の台数は、２０２０年には５３０億台に上ると言われており、今後も増加が予想される（非特許文献１）。このため、上記のような攻撃の踏み台とされる事件が更に増えると考えられる。したがって、マルウェアに感染したＩｏＴ端末を特定（検知）し、上記のような攻撃を防止することが求められている。

しかしながら、ＩｏＴ端末の中には、例えば価格を抑えるためにＩｏＴ端末自体の性能（ＣＰＵ（Central Processing Unit）やメモリ等）が低いものが多数存在する。したがって、ＩｏＴ端末自体にセキュリティ機能を具備させるのが困難な場合がある。このため、ＩｏＴ端末が繋がるネットワーク側（例えば、ＩＳＰ（Internet Services Provider）や電気通信事業者等のネットワーク）で、マルウェアに感染したＩｏＴ端末を特定することができれば好ましい。

ここで、ネットワーク側でマルウェアに感染した端末を特定する技術として、アノマリ型検知が知られている（非特許文献２）。アノマリ型検知では、端末毎の正常な振る舞いを学習することで、異常検知（すなわち、マルウェア感染に感染した端末の検知）に用いるための検知モデルを作成する。このため、アノマリ型検知では、端末数に依存した計算時間を必要する。また、作成した検知モデルを保存するためのストレージ領域の容量も、端末数に応じて必要となる。

また、ＤＮＳ（Domain Name System）ログを解析することで、マルウェアに感染した端末及びＣ＆Ｃ（Command and Control）サーバを特定する技術が知られている（非特許文献３）。この技術では、ＤＮＳキャッシュサーバに送信された大量のＤＮＳクエリの挙動を監視し、マルウェアに感染した端末や悪性ドメイン特有の挙動を学習することで、異常検知を行う。マルウェアに感染した端末や悪性ドメイン特有の挙動をＤＮＳクエリから学習するためには、クエリ数に応じた計算時間を必要とする。また、ＤＮＳクエリが送信される度に異常検知を行う場合には、短時間で計算可能な検知手法が必要となる。

"平成27年版 情報通信白書", ［online］, インターネット＜ＵＲＬ：http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h27/html/nc254110.html＞ "Darktrace", ［online］, インターネット＜ＵＲＬ：http://www.darktrace.jp/＞ "DNS クエリログのクエリ数に着目した異常端末の検出", 渡辺拳竜, 池部実, and 吉田和幸. マルチメディア, 分散協調とモバイルシンポジウム 2014 論文集 2014 (2014): 205-210.

ここで、機械学習を用いたマルウェア感染端末の特定では、検知対象となる端末数に応じて、検知モデル作成のための計算時間と、ストレージ領域の容量とが必要になる。例えば、端末の台数をＮ、学習データの数をＳとして、異常検知アルゴリズムにＳＶＭ（Support Vector Machine）を用いた場合、検知モデル作成のための計算時間はＯ（ＮＳｌｏｇＳ）、ストレージ領域の容量はＯ（ＮＳ）で表される。

しかしながら、上述したように、ＩｏＴ端末の台数は今後も増加が予想される。また、通常、機械学習アルゴリズムで検知精度を向上させるためには、大量の学習データが必要なる。

このため、ＩＳＰや電気通信事業者等のネットワークのように、多数のＩｏＴ端末が接続されたネットワークにおけるマルウェア感染端末の特定では、検知モデル作成のための計算時間やストレージ領域の容量が膨大になり、機械学習のアルゴリズムを用いたマルウェア感染端末の特定が困難な場合があった。

本発明は、上記の点に鑑みてなされたものであって、マルウェア感染端末の特定を支援することを目的とする。

そこで、上記課題を解決するため、複数の端末と接続される異常検知システムであって、前記複数の端末を１以上のクラスタに分類するクラスタリング部と、前記クラスタリング部により分類されたクラスタ毎に、異常な端末が前記クラスタに属することを検知するための検知モデルを作成する検知モデル作成部と、前記複数の端末のうち、前記クラスタに属する各端末のトラヒック情報に基づいて、該クラスタの特徴量を示すクラスタ特徴量を生成する第１の特徴量生成部と、前記検知モデル作成部により作成された前記検知モデルと、前記第１の特徴量生成部により生成された前記クラスタ特徴量とに基づいて、異常な端末が前記クラスタに属することを検知する異常検知部と、を有する。

マルウェア感染端末の特定を支援することができる。

本発明の実施の形態におけるシステムの全体構成の一例を示す図である。 コンピュータのハードウェア構成の一例を示す図である。 本発明の実施の形態における学習装置の機能構成の一例を示す図である。 本発明の実施の形態における異常検知装置の機能構成の一例を示す図である。 本発明の実施の形態における異常検知用ストレージ装置の機能構成の一例を示す図である。 アドレス情報テーブルの一例を示す図である。 クラスタ情報テーブルの一例を示す図である。 学習情報テーブルの一例を示す図である。 検知モデル情報テーブルの一例を示す図である。 設定情報テーブルの一例を示す図である。 本発明の実施の形態におけるクラスタリング処理の一例を示すシーケンス図である。 本発明の実施の形態における検知モデルの作成処理の一例を示すシーケンス図である。 本発明の実施の形態における異常検知処理の一例を示すシーケンス図である。

以下、本発明の実施の形態について、図面を参照しながら説明する。

＜全体構成＞
まず、本発明の実施の形態におけるシステムの全体構成例について、図１を参照しながら説明する。図１は、本発明の実施の形態におけるシステムの全体構成の一例を示す図である。

図１に示すように、本発明の実施の形態におけるシステムは、例えばＩＳＰや電気通信事業者等のコアネットワークであるシステム環境Ｅと、複数のＩｏＴ端末７０とを有する。

ＩｏＴ端末７０は、例えば各種センサや監視カメラ、各種家電製品、スマートメータ等の種々の電子機器又は装置である。各ＩｏＴ端末７０は、システム環境Ｅに接続されており、それぞれが異なる通信特性（例えば、通信発生の頻度、宛先（送信先ＩＰアドレス（Internet Protocol））の種類数、パケットサイズ等）を有している。

システム環境Ｅは、転送装置１０と、トラヒック情報収集装置２０と、異常検知システム３０と、ＤＮＳサーバ４０と、ＤＨＣＰ（Dynamic Host Configuration Protocol）５０と、セキュリティ装置６０とを有する。

転送装置１０は、例えばエッジルータ等であり、インターネットと各ＩｏＴ端末７０との間のパケットを中継する機能を有する。転送装置１０は、ＩｏＴ端末７０のパケットを中継する際に、当該ＩｏＴ端末７０のＩＰアドレス等のトラヒック情報を取得する。転送装置１０により取得されたトラヒック情報は、トラヒック情報収集装置２０に蓄積される。トラヒック情報には、例えば、パケットのヘッダ情報、フロー情報、ＤＮＳサーバ４０のログ情報、ＤＨＣＰサーバ５０が保持するＩＰアドレスのリスト情報等が挙げられる。

トラヒック情報収集装置２０は、転送装置１０やＤＮＳサーバ４０、ＤＨＣＰサーバ５０等からトラヒック情報を収集して、収集したトラヒック情報を蓄積（保存）する１以上のコンピュータである。

ＤＮＳサーバ４０は、ＤＮＳ機能を有する１以上のコンピュータである。ＤＨＣＰサーバ５０は、ＤＨＣＰ機能を有する１以上のコンピュータである。

異常検知システム３０は、マルウェアに感染したＩｏＴ端末７０を特定するための１以上のコンピュータにより構成されるシステムである。異常検知システム３０は、学習装置３１と、異常検知装置３２と、異常検知用ストレージ装置３３とを有する。

学習装置３１は、各ＩｏＴ端末７０のトラヒック情報から得られる所定の特徴量に基づいて、これらＩｏＴ端末７０を複数のクラスタに分類する（すなわち、ＩｏＴ端末７０をクラスタリングする。）。そして、学習装置３１は、クラスタ単位で異常を検知するための検知モデルを作成する。クラスタ単位で異常を検知するとは、当該クラスタに属するＩｏＴ端末７０の中に、マルウェアに感染しているＩｏＴ端末７０が存在することを検知することである。なお、所定の特徴量とは、ＩｏＴ端末７０のトラヒック情報から得られる情報であり、例えば、上述した通信特性を示す情報等が挙げられる。

異常検知装置３２は、クラスタに属する各ＩｏＴ端末７０のトラヒック情報から得られるクラスタ単位の所定の特徴量と、学習装置３１により作成された検知モデルとに基づいて、クラスタ単位で異常を検知する。すなわち、異常検知装置３２は、マルウェアに感染しているＩｏＴ端末７０が含まれるクラスタを検知する。

異常検知用ストレージ装置３３は、各種の情報を管理する。例えば、異常検知用ストレージ装置３３は、学習装置３１により作成された検知モデルを保存する。また、異常検知用ストレージ装置３３は、異常検知装置３２による異常検知に用いられる各種情報を記憶している。

セキュリティ装置６０は、異常検知装置３２により異常と検知されたクラスタに属する各ＩｏＴ端末７０の中から、マルウェアに感染しているＩｏＴ端末７０を特定する。セキュリティ装置６０は、例えば、ＩＰＳ（Intrusion Prevention System）やサンドボックス、ＤＰＩ（Deep Packet Inspection）等により、当該クラスタに属する各ＩｏＴ端末７０の中から、マルウェアに感染しているＩｏＴ端末７０を特定する。

なお、図１に示すシステム構成は、一例であって、他の構成であっても良い。例えば、システム環境Ｅは、複数台の転送装置１０、複数台のトラヒック情報収集装置２０、複数の異常検知システム３０、複数台のセキュリティ装置６０を有していても良い。また、異常検知システム３０において、学習装置３１と、異常検知装置３２と、異常検知用ストレージ装置３３とが１台の装置（コンピュータ）で構成されていても良い。

＜ハードウェア構成＞
次に、トラヒック情報収集装置２０、学習装置３１、異常検知装置３２、及び異常検知用ストレージ装置３３等を実現するコンピュータ１００のハードウェア構成について、図２を参照しながら説明する。図２は、コンピュータ１００のハードウェア構成の一例を示す図である。

図２に示すように、コンピュータ１００は、外部Ｉ／Ｆ１０１と、ＲＡＭ（Random Access Memory）１０２と、ＲＯＭ（Read Only Memory）１０３と、ＣＰＵ１０４と、通信Ｉ／Ｆ１０５と、補助記憶装置１０６とを有する。これら各ハードウェアは、それぞれがバスＢを介して通信可能に接続されている。

外部Ｉ／Ｆ１０１は、外部装置とのインタフェースである。外部装置には、記録媒体１０１ａ等がある。コンピュータ１００は、外部Ｉ／Ｆ１０１を介して記録媒体１０１ａ等の読み取りや書き込みを行うことができる。

記録媒体１０１ａには、例えば、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等がある。

ＲＡＭ１０２は、プログラムやデータを一時保持する揮発性の半導体メモリである。ＲＯＭ１０３は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリである。ＲＯＭ１０３には、例えば、ＯＳ（Operating System）設定やネットワーク設定等が格納されている。

ＣＰＵ１０４は、ＲＯＭ１０３や補助記憶装置１０６等からプログラムやデータをＲＡＭ１０２上に読み出して処理を実行する演算装置である。通信Ｉ／Ｆ１０５は、コンピュータ１００をネットワークに接続するためのインタフェースである。

補助記憶装置１０６は、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等であり、プログラムやデータを格納している不揮発性の記憶装置である。補助記憶装置１０６に格納されているプログラムやデータには、例えば、ＯＳ、当該ＯＳ上において各種機能を実現するアプリケーションソフトウェア、本実施形態における各種処理を実現するプログラム等がある。

なお、コンピュータ１００は、上記の各ハードウェアに加えて、例えば、ディスプレイ等の表示装置と、キーボードやマウス等の入力装置とを有していても良い。

本実施形態に係るコンピュータ１００は、図２に示すハードウェア構成を有することにより、後述する各種処理を実現することができる。

＜機能構成＞
次に、異常検知システム３０に含まれる学習装置３１、異常検知装置３２、及び異常検知用ストレージ装置３３の機能構成について説明する。

≪学習装置３１≫
まず、学習装置３１の機能構成について、図３を参照しながら説明する。図３は、本発明の実施の形態における学習装置３１の機能構成の一例を示す図である。

図３に示すように、学習装置３１は、通信部３１１と、特徴量生成部３１２と、クラスタリング部３１３と、検知モデル作成部３１４とを有する。これら各機能部は、学習装置３１にインストールされた１以上のプログラムが、ＣＰＵに実行させる処理により実現される。

通信部３１１は、トラヒック情報収集装置２０や異常検知用ストレージ装置３３等との間で情報の送受信を行う。例えば、通信部３１１は、トラヒック情報収集装置２０から各ＩｏＴ端末７０のトラヒック情報を受信する。

特徴量生成部３１２は、通信部３１１により受信されたトラヒック情報に所定の処理を施す（例えば、所定のＩＰアドレスが含まれる回数をカウントする等）ことで、機械学習や時系列分析を行う上で必要な所定の特徴量を生成する。

ここで、ＩｏＴ端末７０をクラスタリングする段階では、通信部３１１は、全てのＩｏＴ端末７０（又は、ある転送装置１０によりパケットが転送される全てのＩｏＴ端末７０）のトラヒック情報を受信する。したがって、この場合、特徴量生成部３１２は、これら全てのＩｏＴ端末７０のトラヒック情報から特徴量を生成する。

一方で、検知モデルを作成する段階では、通信部３１１は、クラスタ単位のトラヒック情報（すなわち、当該クラスタに属するＩｏＴ端末７０のトラヒック情報）を受信する。したがって、この場合、特徴量生成部３１２は、クラスタ毎に、当該クラスタの特徴量を生成する。以降では、クラスタの特徴量（すなわち、クラスタ単位の特徴量）を「クラスタ特徴量」とも表す。

クラスタリング部３１３は、特徴量生成部３１２により生成された特徴量に基づいて、各ＩｏＴ端末７０をクラスタリングする。クラスタリング部３１３は、クラスタリングの結果を示すクラスタ情報を異常検知用ストレージ装置３３に送信する。

検知モデル作成部３１４は、特徴量生成部３１２により生成されたクラスタ特徴量に基づいて、クラスタ毎の検知モデルを作成するための学習情報を作成して、異常検知用ストレージ装置３３に送信する。そして、検知モデル作成部３１４は、例えば所定の時間の間に作成された学習情報に基づいて、検知モデルを作成する。

ここで、検知モデルとは、異常検知アルゴリズムと、当該異常検知アルゴリズムに用いられるパラメータのパラメータ値とで表される。したがって、異常検知アルゴリズムが予め決められている場合、検知モデルの作成とは、当該異常検知アルゴリズムに用いられるパラメータのパラメータ値を決定することを意味する。

≪異常検知装置３２≫
次に、異常検知装置３２の機能構成について、図４を参照しながら説明する。図４は、本発明の実施の形態における異常検知装置３２の機能構成の一例を示す図である。

図４に示すように、異常検知装置３２は、通信部３２１と、特徴量生成部３２２と、異常検知部３２３とを有する。これら各機能部は、異常検知装置３２にインストールされた１以上のプログラムが、ＣＰＵに実行させる処理により実現される。

通信部３２１は、トラヒック情報収集装置２０や異常検知用ストレージ装置３３等との間で情報の送受信を行う。例えば、通信部３２１は、トラヒック情報収集装置２０からクラスタ単位のトラヒック情報（すなわち、当該クラスタに属する各ＩｏＴ端末７０のトラヒック情報）を受信する。

特徴量生成部３２２は、通信部３２１により受信したトラヒック情報からクラスタ特徴量を生成する。

異常検知部３２３は、特徴量生成部３２２により生成されたクラスタ特徴量と、異常検知用ストレージ装置３３から受信した検知モデルとに基づいて、該当のクラスタが異常であるか否かを判定する。すなわち、異常検知部３２３は、マルウェアに感染しているＩｏＴ端末７０が含まれるクラスタを検知する。以降では、マルウェアに感染しているＩｏＴ端末７０を「異常端末７０」、異常端末７０が含まれるクラスタを「異常クラスタ」とも表す。

異常検知部３２３は、異常クラスタが検知された場合、当該異常クラスタを識別するクラスタＩＤをセキュリティ装置６０に送信する。

≪異常検知用ストレージ装置３３≫
次に、異常検知用ストレージ装置３３の機能構成について、図５を参照しながら説明する。図５は、本発明の実施の形態における異常検知用ストレージ装置３３の機能構成の一例を示す図である。

図５に示すように、異常検知用ストレージ装置３３は、通信部３３１と、情報管理部３３２とを有する。これら各機能部は、異常検知用ストレージ装置３３にインストールされた１以上のプログラムが、ＣＰＵに実行させる処理により実現される。

また、異常検知用ストレージ装置３３は、アドレス情報テーブル記憶部３３３と、クラスタ情報テーブル記憶部３３４と、学習情報テーブル記憶部３３５と、検知モデル情報テーブル記憶部３３６と、設定情報テーブル記憶部３３７とを有する。これら各記憶部は、例えば補助記憶装置を用いて実現可能である。

通信部３３１は、トラヒック情報収集装置２０や学習装置３１、異常検知装置３２、セキュリティ装置６０等との間で情報の送受信を行う。例えば、通信部３３１は、学習装置３１から学習情報や検知モデル情報を受信する。また、例えば、通信部３３１は、異常検知装置３２から、異常クラスタのクラスタＩＤを受信する。

情報管理部３３２は、各種記憶部に記憶されているテーブルから情報を読み出すと共に、各種記憶部に記憶されているテーブルに情報を格納する。

アドレス情報テーブル記憶部３３３は、アドレス情報テーブル３３３Ｔを記憶する。ここで、アドレス情報テーブル３３３Ｔについて、図６を参照しながら説明する。図６は、アドレス情報テーブル３３３Ｔの一例を示す図である。

図６に示すように、アドレス情報テーブル３３３Ｔには、アドレス情報が格納されている。アドレス情報は、転送装置１０を識別する転送装置ＩＤと、当該転送装置１０によりパケットが中継される各ＩｏＴ端末７０のＩＰアドレスとが関連付けられている。言い換えれば、アドレス情報は、転送装置ＩＤ毎に、当該転送装置ＩＤの転送装置１０によりパケットが中継されるＩｏＴ端末７０のＩＰアドレスのリストが関連付けられている。このようなＩＰアドレスは、ＤＨＣＰサーバ５０により、各ＩｏＴ端末７０に対して割り当てられる。

クラスタ情報テーブル記憶部３３４は、クラスタ情報テーブル３３４Ｔを記憶する。ここで、クラスタ情報テーブル３３４Ｔについて、図７を参照しながら説明する。図７は、クラスタ情報テーブル３３４Ｔの一例を示す図である。

図７に示すように、クラスタ情報テーブル３３４Ｔには、クラスタ情報が格納されている。クラスタ情報は、クラスタを識別するクラスタＩＤと、当該クラスタに属するＩｏＴ端末７０のＩＰアドレスとが関連付けられている。

学習情報テーブル記憶部３３５は、学習情報テーブル３３５Ｔを記憶する。ここで、学習情報テーブル３３５Ｔについて、図８を参照しながら説明する。図８は、学習情報テーブル３３５Ｔの一例を示す図である。

図８に示すように、学習情報テーブル３３５Ｔには、学習情報が格納されている。学習情報は、クラスタＩＤと、学習データとが関連付けられている。学習データは、特徴量生成部３１２により生成されたクラスタ特徴量（特徴１，特徴２，・・・，特徴ｍ）に対して、教師データ（「正常」又は「異常」）を付与したデータ（言い換えれば、「正常」又は「異常」がラベル付けされたデータ）である。

ただし、異常検知アルゴリズムとして、教師あり学習以外のアルゴリズムを用いる場合には、教師データは不要である。この場合の学習データは、クラスタ特徴量とすれば良い。

検知モデル情報テーブル記憶部３３６は、検知モデル情報テーブル３３６Ｔを記憶する。ここで、検知モデル情報テーブル３３６Ｔについて、図９を参照しながら説明する。図９は、検知モデル情報テーブル３３６Ｔの一例を示す図である。

図９に示すように、検知モデル情報テーブル３３６Ｔには、検知モデル情報が格納されている。検知モデル情報は、クラスタＩＤと、検知モデルのパラメータ値とが関連付けられている。なお、検知モデルのパラメータ値は、後述する設定情報により設定された異常検知アルゴリズムに用いられるパラメータのパラメータ値である。上述したように、検知モデルは、異常検知アルゴリズムと、当該異常検知アルゴリズムに用いられるパラメータのパラメータ値とで表される。

設定情報テーブル記憶部３３７は、設定情報テーブル３３７Ｔを記憶する。ここで、設定情報テーブル３３７Ｔについて、図１０を参照しながら説明する。図１０は、設定情報テーブル３３７Ｔの一例を示す図である。

図１０に示すように、設定情報テーブル３３７Ｔには、設定情報が格納されている。設定情報は、データ取得の間隔と、検知モデルの更新頻度と、異常検知アルゴリズムの種類とが含まれる。データ取得の間隔には、トラヒック情報収集装置２０が転送装置１０からトラヒック情報を取得する時間間隔が設定される。検知モデルの更新頻度は、上述した検知モデルのパラメータ値を更新する時間間隔が設定される。これらの情報が設定される設定情報は、例えば、システム環境Ｅのシステム管理者等により予め作成される。

なお、異常検知アルゴリズムの種類は、機械学習や時系列分析に用いられる種々のアルゴリズムを設定することができる。これらアルゴリズムには、例えば、ｋ−近傍法、ＳＶＭ（Support Vector Machine）、ニューラルネットワーク等が挙げられる。

＜処理の詳細＞
次に、本発明の実施の形態におけるシステムの処理の詳細について説明する。

≪クラスタリング処理≫
まず、各ＩｏＴ端末７０を複数のクラスタに分類（クラスタリング）する処理について、図１１を参照しながら説明する。図１１は、本発明の実施の形態におけるクラスタリング処理の一例を示すシーケンス図である。図１１に示すクラスタリング処理は、例えば、システム環境Ｅのシステム管理者等の操作に応じて実行されても良いし、予め決められた所定の時間に実行されても良い。また、図１１に示すクラスタリング処理が実行されて各ＩｏＴ端末７０がクラスタリングされた場合であっても、例えば、ＩｏＴ端末７０の増減等に応じて再度実行されても良い。

まず、トラヒック情報収集装置２０は、転送装置１０に対して、トラヒック情報のリクエストを送信する（ステップＳ１０１）。転送装置１０は、当該リクエストに応じて、自身がパケットを転送する各ＩｏＴ端末７０のトラヒック情報をトラヒック情報収集装置２０に送信する（ステップＳ１０２）。

トラヒック情報収集装置２０は、転送装置１０からトラヒック情報を受信すると、当該トラヒック情報を学習装置３１に送信する（ステップＳ１０３）。なお、トラヒック情報収集装置２０は、ＤＮＳサーバ４０やＤＨＣＰサーバ５０からトラヒック情報を収集して、学習装置３１に送信しても良い。

トラヒック情報収集装置２０は、例えば、所定の時間の間、設定情報の「データ取得の間隔」で設定された時間毎に転送装置１０からトラヒック情報を収集した上で、収集したトラヒック情報を学習装置３１に送信しても良い。

学習装置３１の特徴量生成部３１２は、通信部３１１によりトラヒック情報を受信すると、各ＩｏＴ端末７０の特徴量を生成する（ステップＳ１０４）。特徴量生成部３１２は、例えば、各ＩｏＴ端末７０のトラヒック情報に基づいて、「通信発生の頻度」や「宛先の種類数」を特徴量として生成すれば良い。

「通信発生の頻度」や「宛先の種類数」は、ＤＮＳサーバ４０のログ情報に基づき生成することができる。具体的には、ＤＮＳサーバ４０のログ情報のうち、転送装置１０に接続されたＩｏＴ端末７０のＩＰアドレスが含まれるログ情報を抽出した上で、抽出したログ情報における当該ＩＰアドレスの出現回数をカウントすることで、「通信発生の頻度」を得ることができる。同様に、抽出したログ情報における送信先ＩＰアドレスの種類数をカウントすることで、「宛先の種類数」を得ることができる。

「通信発生の頻度」や「宛先の種類数」を特徴量として用いることで、例えば、通信頻度の増加と、宛先数の増加とによる異常（例えば、Ｃ＆Ｃサーバへの通信等）を検知することが可能となる。

なお、特徴量は、上記の「通信発生の頻度」や「宛先の種類数」に限られない。ＩｏＴ端末７０（のＩＰアドレス）をクラスタに分類可能な特徴量であれば、任意の特徴量を用いることができる。

次に、学習装置３１のクラスタリング部３１３は、特徴量生成部３１２により生成された各ＩｏＴ端末７０の特徴量に基づいて、これら各ＩｏＴ端末７０をクラスタリングする（ステップＳ１０５）。クラスタリング部３１３は、例えば、Ｋ−Ｍｅａｎｓ法等を用いて、各ＩｏＴ端末７０をクラスタリングすれば良い。ただし、クラスタリングに用いられるアルゴリズムやパラメータ（例えば、距離の定義等）は、特定のアルゴリズムや特定のパラメータに限定されるものではなく、任意のアルゴリズムや任意のパラメータを用いることができる。

クラスタリング部３１３によりクラスタリングが行われると、クラスタを識別するクラスタＩＤと、当該クラスタに属するＩｏＴ端末７０のＩＰアドレスとが関連付けられたクラスタ情報が作成される。

次に、学習装置３１の通信部３１１は、クラスタリング部３１３により作成されたクラスタ情報を異常検知用ストレージ装置３３に送信する（ステップＳ１０６）。

異常検知用ストレージ装置３３の情報管理部３３２は、通信部３３１によりクラスタ情報を受信すると、当該クラスタ情報をクラスタ情報テーブル３３４Ｔに格納する（ステップＳ１０７）。

以上により、各ＩｏＴ端末７０の特徴量に基づいて、これら各ＩｏＴ端末７０がクラスタリングされる。このとき、例えば、特徴量として各ＩｏＴ端末７０の通信特性を用いることで、同一の通信特性を有するＩｏＴ端末７０（具体的には、同一メーカのＩｏＴ端末７０や同一メーカの部品を有するＩｏＴ端末７０等）が同一のクラスタに分類される。

≪検知モデルの作成処理≫
次に、クラスタ毎に検知モデルを作成する処理について、図１２を参照しながら説明する。図１２は、本発明の実施の形態における検知モデルの作成処理の一例を示すシーケンス図である。図１２に示す検知モデルの作成処理は、設定情報に含まれる「検知モデルの更新間隔」に設定された時間毎に実行される。

まず、異常検知用ストレージ装置３３の通信部３３１は、トラヒック情報収集装置２０に対して、クラスタ単位のトラヒック情報のリクエストを送信する（ステップＳ２０１）。異常検知用ストレージ装置３３は、クラスタ情報テーブル３３４Ｔを参照することで、クラスタ単位のトラヒック情報のリクエストを送信することができる。

例えば、異常検知用ストレージ装置３３は、クラスタ情報テーブル３３４Ｔを参照して、クラスタＩＤ「クラスタＡ」に関連付けられたＩＰアドレスを含むリクエストを送信することで、クラスタＡ単位のトラヒック情報のリクエストを行うことができる。同様に、例えば、異常検知用ストレージ装置３３は、クラスタ情報テーブル３３４Ｔを参照して、クラスタＩＤ「Ｂ」に関連付けられたＩＰアドレスを含むリクエストを送信することで、クラスタＢ単位のトラヒック情報のリクエストを行うことができる。

異常検知用ストレージ装置３３の通信部３３１は、クラスタ毎に、クラスタ単位のトラヒック情報のリクエストをトラヒック情報収集装置２０に送信する。

以降では、一例として、クラスタＡのトラヒック情報のリクエストを送信したものとして説明する。

ここで、以降のステップＳ２０２におけるトラヒック情報のリクエストは、設定情報の「データ取得の間隔」で設定された時間毎に実行される。したがって、以降のステップＳ２０２〜ステップＳ２０８の処理は、例えば所定の時間の間、当該時間毎に繰り返し実行される。ただし、これに限られず、ステップＳ２０２〜ステップＳ２０８の処理は、例えば、後述するステップＳ２０８の処理において、学習情報テーブル３３５Ｔに所定の件数の学習情報が格納されるまで実行されるようにしても良い。

トラヒック情報収集装置２０は、異常検知用ストレージ装置３３からクラスタＡのトラヒック情報のリクエストを受信すると、クラスタＡに属するＩｏＴ端末７０のトラヒック情報のリクエストを転送装置１０に送信する（ステップＳ２０２）。なお、当該リクエストには、クラスタＡに属するＩｏＴ端末７０のＩＰアドレスが含まれる。

転送装置１０は、当該リクエストに応じて、自身がパケットを転送する各ＩｏＴ端末７０のうち、クラスタＡに属するＩｏＴ端末７０のトラヒック情報をトラヒック情報収集装置２０に送信する（ステップＳ２０３）。

トラヒック情報収集装置２０は、転送装置１０からクラスタＡに属するＩｏＴ端末７０のトラヒック情報を受信すると、当該トラヒック情報を学習装置３１に送信する（ステップＳ２０４）。なお、トラヒック情報収集装置２０は、ＤＮＳサーバ４０やＤＨＣＰサーバ５０からクラスタＡに属するＩｏＴ端末７０のトラヒック情報を収集して、学習装置３１に送信しても良い。

学習装置３１の特徴量生成部３１２は、通信部３１１によりクラスタＡに属するＩｏＴ端末７０のトラヒック情報を受信すると、クラスタＡのクラスタ特徴量を生成する（ステップＳ２０５）。特徴量生成部３１２は、クラスタＡに属する各ＩｏＴ端末７０の特徴量を生成した上で、これら特徴量の平均値又は中央値を算出して、当該平均値又は中央値をクラスタ特徴量とすれば良い。

特徴量生成部３１２は、上記のステップＳ１０４と同様の特徴量を用いてクラスタ特徴量を生成しても良いし、異なる特徴量を用いてクラスタ特徴量を生成しても良い。なお、上記のステップＳ１０４と同様の特徴量を生成する場合、異常時（すなわち、クラスタに異常端末７０が含まれる時）に大きく変動する特徴量をクラスタ特徴量とすることが好ましい。

次に、学習装置３１の特徴量生成部３１２は、クラスタ特徴量に対して教師データを付与することで、学習データを生成する（ステップＳ２０６）。なお、教師データが「正常」又は「異常」のいずれであるかは、例えば、システム環境Ｅのシステム管理者等により設定されても良いし、予め決められたアルゴリズムにより設定されても良い。

ただし、異常検知アルゴリズムとして、教師あり学習以外のアルゴリズムを用いる場合（例えば、ｋ−近傍法を用いる場合等）には、教師データは不要であり、特徴量生成部３１２は、クラスタ特徴量を学習データとすれば良い。

学習データが生成されると、特徴量生成部３１２により、当該学習データと、クラスタＡのクラスタＩＤとが関連付けられた学習情報が生成される。

次に、学習装置３１の通信部３１１は、学習情報を異常検知用ストレージ装置３３に送信する（ステップＳ２０７）。

異常検知用ストレージ装置３３の情報管理部３３２は、通信部３３１により学習情報を受信すると、当該学習情報を学習情報テーブル３３５Ｔに格納する（ステップＳ２０８）。

異常検知用ストレージ装置３３の通信部３３１は、上記のステップＳ２０２〜ステップＳ２０８の処理が所定の時間の間繰り返し実行された後、クラスタ単位の学習情報を学習装置３１に送信する（ステップＳ２０９）。すなわち、通信部３３１は、情報管理部３３２により学習情報テーブル３３５Ｔから取得されたクラスタＡの学習情報を学習装置３１に送信する。

学習装置３１の検知モデル作成部３１４は、異常検知用ストレージ装置３３から受信した学習情報に基づいて、検知モデルのパラメータ値を生成する（ステップＳ２１０）。このとき、検知モデル作成部３１４は、設定情報の「異常検知アルゴリズムの種類」で設定された異常検知アルゴリズムに用いられるパラメータのパラメータ値を生成する。

検知モデルのパラメータ値が生成されると、検知モデル作成部３１４により、当該検知モデルのパラメータ値と、クラスタＡのクラスタＩＤとが関連付けられた検知モデル情報が作成される。

学習装置３１の通信部３１１は、検知モデル情報を異常検知用ストレージ装置３３に送信する（ステップＳ２１１）。

異常検知用ストレージ装置３３の情報管理部３３２は、通信部３３１により検知モデル情報を受信すると、当該検知モデル情報を検知モデル情報テーブル３３６Ｔに格納する（ステップＳ２１２）。なお、情報管理部３３２は、同一のクラスタＩＤの検知モデル情報が検知モデル情報テーブル３３６Ｔに既に格納されている場合、当該検知モデル情報を、通信部３３１により受信された検知モデル情報で上書き更新すれば良い。

以上により、複数のＩｏＴ端末７０が属するクラスタ毎に、当該クラスタ単位で異常を検知するための検知モデルが作成及び更新される。このように、クラスタ単位で検知モデルを作成することで、ＩｏＴ端末７０毎に個別で検知モデルを作成する場合と比較して、検知モデル作成のための計算時間やストレージ領域の容量を削減することができる。

≪異常検知処理≫
次に、検知モデルに基づいて異常クラスタを特定（検知）した後に、当該異常クラスタに属する異常端末７０を特定する処理について、図１３を参照しながら説明する。図１３は、本発明の実施の形態における異常検知処理の一例を示すシーケンス図である。

まず、異常検知用ストレージ装置３３の通信部３３１は、トラヒック情報収集装置２０に対して、クラスタ単位のトラヒック情報のリクエストを送信する（ステップＳ３０１）。異常検知用ストレージ装置３３は、クラスタ情報テーブル３３４Ｔを参照することで、クラスタ単位のトラヒック情報のリクエストを送信することができる。

以降では、一例として、クラスタＡのトラヒック情報のリクエストを送信したものとして説明する。

ここで、以降のステップＳ３０２におけるトラヒック情報のリクエストは、設定情報の「データ取得の間隔」で設定された時間毎に実行される。したがって、以降のステップＳ３０２〜ステップＳ３１３の処理は、当該時間毎に繰り返し実行される。

トラヒック情報収集装置２０は、異常検知用ストレージ装置３３からクラスタＡのトラヒック情報のリクエストを受信すると、クラスタＡに属するＩｏＴ端末７０のトラヒック情報のリクエストを転送装置１０に送信する（ステップＳ３０２）。なお、当該リクエストには、クラスタＡに属するＩｏＴ端末７０のＩＰアドレスが含まれる。

転送装置１０は、当該リクエストに応じて、自身がパケットを転送する各ＩｏＴ端末７０のうち、クラスタＡに属するＩｏＴ端末７０のトラヒック情報をトラヒック情報収集装置２０に送信する（ステップＳ３０３）。

トラヒック情報収集装置２０は、転送装置１０からクラスタＡに属するＩｏＴ端末７０のトラヒック情報を受信すると、当該トラヒック情報を異常検知装置３２に送信する（ステップＳ３０４）。なお、トラヒック情報収集装置２０は、ＤＮＳサーバ４０やＤＨＣＰサーバ５０からクラスタＡに属するＩｏＴ端末７０のトラヒック情報を収集して、異常検知装置３２に送信しても良い。

異常検知装置３２の特徴量生成部３２２は、通信部３２１によりクラスタＡに属するＩｏＴ端末７０のトラヒック情報を受信すると、クラスタＡのクラスタ特徴量を生成する（ステップＳ３０５）。特徴量生成部３２２は、クラスタＡに属するＩｏＴ端末７０の特徴量を生成した上で、これら特徴量の平均値又は中央値を算出することで、当該平均値又は中央値をクラスタ特徴量とすれば良い。なお、特徴量生成部３２２は、学習装置３１の特徴量生成部３１２と同様のクラスタ特徴量を生成する。

次に、異常検知装置３２の通信部３２１は、クラスタＡの検知モデルのパラメータ値のリクエストを異常検知用ストレージ装置３３に送信する（ステップＳ３０６）。

異常検知用ストレージ装置３３の通信部３３１は、当該リクエストを受信すると、情報管理部３３２によりクラスタＡの検知モデルのパラメータ値を検知モデル情報テーブル３３６Ｔから取得して、異常検知装置３２に送信する（ステップＳ３０７）。

異常検知装置３２の異常検知部３２３は、上記のステップＳ３０５で生成されたクラスタ特徴量と、異常検知用ストレージ装置３３から受信した検知モデルのパラメータ値とに基づいて、クラスタＡの異常判定を行う（ステップＳ３０８）。すなわち、異常検知部３２３は、クラスタ特徴量と、検知モデルのパラメータとを用いて、異常検知アルゴリズムによりクラスタＡが異常クラスタであるか否かを判定する。これにより、異常クラスタが特定（検知）される。

上記のステップＳ３０８において、クラスタＡが異常クラスタであると判定されなかった場合（すなわち、クラスタＡに異常端末７０が含まれない場合）、以降のステップＳ３０９〜ステップＳ３１３の処理は実行されない。一方で、上記のステップＳ３０８において、クラスタＡが異常クラスタであると判定された場合（すなわち、クラスタＡに異常端末７０が含まれる場合）、以降のステップＳ３０９〜ステップＳ３１３の処理が実行される。

異常検知装置３２の通信部３２１は、異常クラスタのクラスタＩＤ（本実施形態では、一例として、クラスタＡ）を異常検知用ストレージ装置３３に送信する（ステップＳ３０９）。

異常検知用ストレージ装置３３の通信部３３１は、情報管理部３３２によりクラスタ情報テーブル３３４Ｔを参照して、クラスタＩＤ「クラスタＡ」に関連付けられているＩＰアドレスをセキュリティ装置６０に送信する（ステップＳ３１０）。すなわち、通信部３３１は、異常クラスタと判定されたクラスタＡに属するＩｏＴ端末７０のＩＰアドレスをセキュリティ装置６０に送信する。

セキュリティ装置６０は、異常クラスタであるクラスタＡに属するＩｏＴ端末７０のトラヒック情報のリクエストを転送装置１０に送信する（ステップＳ３１１）。なお、当該リクエストには、異常クラスタと判定されたクラスタＡに属するＩｏＴ端末７０のＩＰアドレスが含まれる。

転送装置１０は、当該リクエストに応じて、自身がパケットを転送する各ＩｏＴ端末７０のうち、異常クラスタと判定されたクラスタＡに属するＩｏＴ端末７０のトラヒック情報をセキュリティ装置６０に送信する（ステップＳ３１２）。

セキュリティ装置６０は、クラスタＡに属するＩｏＴ端末７０のトラヒック情報を受信すると、当該トラヒック情報に基づいて詳細な異常判定を行って、これら各ＩｏＴ端末７０のうち、マルウェアに感染しているＩｏＴ端末７０を特定する（ステップＳ３１３）。なお、セキュリティ装置６０は、上述したように、例えば、ＩＰＳやサンドボックス、ＤＰＩ等により、異常クラスタに属する各ＩｏＴ端末７０の中から、マルウェアに感染しているＩｏＴ端末７０を特定する。

以上により、あるクラスタに属するＩｏＴ端末７０がマルウェアに感染した場合、異常検知装置３２は、各クラスタの中から異常クラスタを特定することができる。このように、クラスタ単位で異常検知を行うことで、例えば、ある同一のメーカの商業用センサ（ＩｏＴ端末７０の一例）に脆弱性が存在し、集団感染が行った場合、これら商業用センサが属するクラスタを異常クラスタとして検知することができる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

１０ 転送装置
２０ トラヒック情報収集装置
３０ 異常検知システム
３１ 学習装置
３２ 異常検知装置
３３ 異常検知用ストレージ装置
４０ ＤＮＳサーバ
５０ ＤＨＣＰサーバ
６０ セキュリティ装置
７０ ＩｏＴ端末
３１１ 通信部
３１２ 特徴量生成部
３１３ クラスタリング部
３１４ 検知モデル作成部
３２１ 通信部
３２２ 特徴量生成部
３２３ 異常検知部
３３１ 通信部
３３２ 情報管理部
３３３ アドレス情報テーブル記憶部
３３４ クラスタ情報テーブル記憶部
３３５ 学習情報テーブル記憶部
３３６ 検知モデル情報テーブル記憶部
３３７ 設定情報テーブル記憶部

Claims (4)

1. 複数の端末と接続される異常検知システムであって、
   前記複数の端末を１以上のクラスタに分類するクラスタリング部と、
   前記クラスタリング部により分類されたクラスタ毎に、異常な端末が前記クラスタに属することを検知するための検知モデルを作成する検知モデル作成部と、
   前記複数の端末のうち、前記クラスタに属する各端末のトラヒック情報に基づいて、該クラスタの特徴量を示すクラスタ特徴量を生成する第１の特徴量生成部と、
   前記検知モデル作成部により作成された前記検知モデルと、前記第１の特徴量生成部により生成された前記クラスタ特徴量とに基づいて、異常な端末が前記クラスタに属することを検知する異常検知部と、
   を有する異常検知システム。
2. 前記第１の特徴量生成部は、
   前記クラスタに属する各端末のトラヒック情報に含まれる所定の通信特性の平均値又は中央値を前記クラスタ特徴量として生成する、請求項１に記載の異常検知システム。
3. 前記複数の端末それぞれの所定の通信特性を示す端末特徴量を生成する第２の特徴量生成部を有し、
   前記クラスタリング部は、
   前記複数の端末それぞれの前記端末特徴量に基づいて、前記複数の端末を１以上のクラスタに分類する、請求項１又は２に記載の異常検知システム。
4. 複数の端末と接続される異常検知システムに用いられる異常検知方法であって、
   前記複数の端末を１以上のクラスタに分類するクラスタリング手順と、
   前記クラスタリング手順により分類されたクラスタ毎に、異常な端末が前記クラスタに属することを検知するための検知モデルを作成する検知モデル作成手順と、
   前記複数の端末のうち、前記クラスタに属する各端末のトラヒック情報に基づいて、該クラスタの特徴量を示すクラスタ特徴量を生成する特徴量生成手順と、
   前記検知モデル作成手順により作成された前記検知モデルと、前記特徴量生成手順により生成された前記クラスタ特徴量とに基づいて、異常な端末が前記クラスタに属することを検知する異常検知手順と、
   を有する異常検知方法。

Images